On Jul 16, 2009, at 2:09 PM, Paolo Bonzini wrote:
On 07/16/2009 12:04 PM, Lukas Renggli wrote:
I believe, that in this case*not* using traits forces you to do the right thing: delegate to another object that knows how to iterate over your object.
Agreed. Adding a #do: method to a class can often be the right thing, but I still have to see one case when a non-Collection, non-Stream class would have advantages from a public #inject:into: or #fold: or #detect: method. A sidenote -- things that do not count:
In the moose environemnt we have group and they cannot inherit from Iterable.
1) #select:/#reject:/#collect:, because those would be abstract in Iterable anyway.
2) using the above methods from within the class itself, because 99.99% of the cases you will have an underlying collection or stream and you can access that underlying object without violating information hiding.
yes so what? How this stream based iomplementation goes faster that the default collection one?
Is this going to be ANSI?
DNU? why ANSI has to be in the story?
Paolo is in the ANSI committee, I though. Maybe that will be added?
There is no ANSI committee, that required to pay money and was not considered viable.
There is a mailing list (run by Bruce Badger) and a protocol (hosted at the GNU Smalltalk site, see the "STEPs" link in the home page) to submit proposals for extensions to Smalltalk, hopefully so that they can be implemented cross vendor. But it has been dormient for too long. :-(
Paolo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project