The Trunk: Collections-ar.307.mcz

Andreas Raab uploaded a new version of Collections to project The Trunk:
http://source.squeak.org/trunk/Collections-ar.307.mcz

==================== Summary ====================

Name: Collections-ar.307
Author: ar
Time: 13 February 2010, 3:37:40.191 pm
UUID: 310c7f68-38f8-334c-b7bd-89b28955a4ff
Ancestors: Collections-nice.306

Merge class Generator from http://source.lukas-renggli.ch/continuations/Generator-ar.5.mcz

=============== Diff against Collections-nice.306 ===============

Item was added:
+ ----- Method: Generator>>contents (in category 'accessing') -----
+ contents
+ "Answer the contents of this generator. Do not call this method on infinite generators."
+
+ | stream |
+ stream := (Array new: 10) writeStream.
+ [ self atEnd ]
+ whileFalse: [ stream nextPut: self next ].
+ ^ stream contents!

Item was added:
+ ----- Method: Generator>>atEnd (in category 'testing') -----
+ atEnd
+ "Answer whether the receiver can access any more objects."
+
+ ^ continue isNil!

Item was added:
+ ----- Method: Generator>>fork (in category 'private') -----
+ fork
+ | result |
+ home := thisContext.
+ block reentrant value: self.
+ thisContext swapSender: continue.
+ result := next.
+ continue := next := home := nil.
+ ^ result!

Item was added:
+ ----- Method: Generator>>next (in category 'accessing') -----
+ next
+ "Generate and answer the next object in the receiver."
+
+ ^ self atEnd ifFalse: [
+ home swapSender: thisContext sender.
+ continue := thisContext swapSender: continue
+ ]!

Item was added:
+ ----- Method: Generator>>reset (in category 'public') -----
+ reset
+ "Reset the generator, i.e., start it over"
+ continue ifNotNil:[continue unwindTo: home].
+ next := nil.
+ continue := thisContext.
+ [ self fork ] value!

Item was added:
+ Stream subclass: #Generator
+ instanceVariableNames: 'block next continue home'
+ classVariableNames: ''
+ poolDictionaries: ''
+ category: 'Collections-Streams'!
+
+ !Generator commentStamp: 'ar 2/10/2010 20:51' prior: 0!
+ A Generator transforms callback interfaces into stream interfaces.
+
+ When a producer algorithm provide results as callbacks (blocks) and a consumer algorithm expects streamable input, a Generator transforms one into the other, for example:
+
+ | generator |
+ generator := Generator on: [:g| Integer primesUpTo: 100 do:[:prime| g yield: prime]].
+ [generator atEnd] whileFalse:[Transcript show: generator next].
+
+ Instance Variables
+ block: <BlockClosure> The block associated with the generator.
+ continue: <MethodContext> The continuation to return to.
+ home: <MethodContext> The home (root) context of the activated block
+ next: <Object> The next object to return from the Generator.
+ !

Item was added:
+ ----- Method: Generator>>peek (in category 'accessing') -----
+ peek
+ "Answer the upcoming object of the receiver."
+
+ ^ next!

Item was added:
+ ----- Method: Generator>>printOn: (in category 'printing') -----
+ printOn: aStream
+ aStream nextPutAll: self class name; nextPutAll: ' on: '; print: block!

Item was added:
+ ----- Method: Generator classSide>>on: (in category 'instance-creation') -----
+ on: aBlock
+ ^ self basicNew initializeOn: aBlock!

Item was added:
+ ----- Method: Generator>>close (in category 'accessing') -----
+ close
+ "Close the receiving generator and unwind its ensure-blocks."
+
+ continue ifNotNil:[continue unwindTo: home].
+ continue := block := next := nil!

Item was added:
+ ----- Method: Generator>>value: (in category 'public') -----
+ value: anObject
+ "Allows passing generators as arguments to methods expecting blocks.
+ A synonym for #yield: / #nextPut:."
+ ^ self nextPut: anObject!

Item was added:
+ ----- Method: Generator>>yield: (in category 'public') -----
+ yield: anObject
+ "Yield the next value to the consumer of the generator.
+ A synonym for #nextPut:"
+ ^ self nextPut: anObject!

Item was added:
+ ----- Method: Generator>>nextPut: (in category 'accessing') -----
+ nextPut: anObject
+ "Add anObject into the generator. A synonym to #yield: and value:."
+
+ | previous |
+ previous := next.
+ next := anObject.
+ continue := thisContext swapSender: continue.
+ ^ previous!

Item was added:
+ ----- Method: Generator>>initializeOn: (in category 'initialization') -----
+ initializeOn: aBlock
+ block := aBlock.
+ self reset!

Item was added:
+ ----- Method: Generator>>size (in category 'accessing') -----
+ size
+ "A generator does not know its size."
+
+ ^ self shouldNotImplement!

El sáb, 13-02-2010 a las 00:00 +0000, [hidden email]
escribió:
<rant>

What?

Why?

Where was that merging discussed?

How are subsequent improvements to the Generator code made in squeak
being contributed back to the original repository?

Why are this decisions being constantly made?

This attitude doesn't build to the Squeak supposed new way to do things.
Why must everything being part of a monolithic squeak image. Why isn't
just a package loaded by monticello and the reference to the original
repository maintained and *respected* in the monticello metadata?

This very one-man squeak isn't very encouraging of the long term promise
of wider collaboration between developers of squeak derived forks.

</rant>

--
Miguel Cobá
http://miguel.leugim.com.mx

Hi Miguel -

Having packages for individual classes with 13 methods total is
pointless. The granularity simply makes no sense. Plus, Generators are
core facilities in my understanding and consequently belong to the other
core stream and collection classes.

Cheers,
   - Andreas

Miguel Enrique Cobá Martinez wrote:

El dom, 14-02-2010 a las 19:44 -0800, Andreas Raab escribió:
> Hi Miguel -
>
> Having packages for individual classes with 13 methods total is
> pointless. The granularity simply makes no sense. Plus, Generators are
> core facilities in my understanding and consequently belong to the other
> core stream and collection classes.

My question stands, who decides what is big enough to be candidate to be
separately packaged? If they were 13 methods but 2 classes they will be
integrated packaged in squeak trunk? What about a class with 400
methods? This is subjective?
Who decides to simply merge it in another package that it is big enough,
but not loadable separately (yes, I know that maybe is impossible to
separate collections and maybe also pointless because of their core
nature)?

I also asked, what about future modifications/fixes/enhancements to
Generator class, how will they be integrated in both squeak and lukas
repo?

Finally your "are core facilities in my understanding" isn't very
encouraging for the community.

Just wanted to know the criteria to merge some external code in the base
image and this last sentence makes it very clear to me.

--
Miguel Cobá
http://miguel.leugim.com.mx

Miguel Enrique Cobá Martinez wrote:
Absolutely. It depends on the concrete situation.

> Who decides to simply merge it in another package that it is big enough,
> but not loadable separately (yes, I know that maybe is impossible to
> separate collections and maybe also pointless because of their core
> nature)?

We decide. In other words, the people participating in the discussion
and doing the work decide. This is a "soft" process that comes with some
judgment, yes. If you are asking for a different process, please propose
something.

> I also asked, what about future modifications/fixes/enhancements to
> Generator class, how will they be integrated in both squeak and lukas
> repo?

What about it? I don't understand your question. Pushing changes in a
single class back into some repository is utterly trivial. If you mean
something different, please elaborate.

> Finally your "are core facilities in my understanding" isn't very
> encouraging for the community.

Why? I think that adding new core features is *very* encouraging. It
shows that we're actively developing Squeak. According to your position,
adding Eliot's closure work would then be "just as bad", no? ;-)

> Just wanted to know the criteria to merge some external code in the base
> image and this last sentence makes it very clear to me.

I'm not certain which last sentence you're referring to but if it's that
a criteria for adding to the base image is that the addition should
provide a core function for the system, then yes, that's a good criteria
in my understanding. Not necessarily the only one, but definitely a good
starting point.

Cheers,
   - Andreas

On 15.02.2010, at 07:19, Andreas Raab wrote:
>
> Miguel Enrique Cobá Martinez wrote:
>
>> Who decides to simply merge it in another package that it is big enough,
>> but not loadable separately (yes, I know that maybe is impossible to
>> separate collections and maybe also pointless because of their core
>> nature)?
>
> We decide. In other words, the people participating in the discussion and doing the work decide. This is a "soft" process that comes with some judgment, yes.

To be more precise, "we" are the core developers. Every core developer has commit access to the trunk repo. We trust each other's judgement. So far this seems to be working well, certainly better than any other community process after the Squeak Central days.

Btw, you can see the list of core-devs by clicking "Groups" at
http://source.squeak.org/

- Bert -