> I am not saying that you should not use them. I am just trying to > explain why I am not using them myself.
Still you should pay attention because you are the guy doing seaside > >> I'm writing a trait to get magritte-aware xml output without having >> to >> always inherit >> from a top class or to copy and paste all the time the same code in >> my >> classes. > > I would use delegation for that. Both, Pier and Magritte use that > pattern too. I think that traits in the metaclass was an error because the kernel is not clean Now if you look at tests of the collection or nile (you can really reuse the same traits for two different implementation and this is really working). >>> As Paolo suggested the problem can be simply solved by introducing >>> an >>> Iterable superclass to Collection and Stream. >> >> I do not see how his solution will offer a faster implementation > > Evaluating > > ((aCollection > select: [ :e | ... ]) > collect: [ :e | ... ]) > > iterates twice over aCollection, sure I was talking compared with a one pass select:collect: > while > > ((aCollection readStream > select: [ :e | ... ]) > collect: [ :e | ... ]) > contents > > will iterate only once. Furthermore the second approach allows any > combination of any of the enumeration methods, not just a few > predefined ones. Also the implementation is less error prone, because > it just uses the standard methods on collection and stream. Yes that I know this was like that in CLOS streams. >> > What if you want to iterate forward and backward over a collection? > What if you have multiple things in your model object that you want to > iterate over? Then you need the iterator Pattern this is clear. > Would you add several iterable traits and prefix all selectors? > > aSystem do: ... > aSystem reverseDo: ... > aSystem itemsDo: ... > > Or rather use delegation? probably delegation. I think that there are place for more than one solution. > > aSystem iterator do: ... > aSystem reverseIterator do: ... > aSystem itemsIterator do: ... > > I find the second solution much nicer because it extracts the strategy > how to iterate over something to a separate object. In about any model > there are multiple collections involved and multiple ways of iterating > through these objects, embedding the iterators directly into the > container seems wrong to me. > >> I think that you should also have a look at what other people are >> doing. > > All I am saying is that collection iteration is one of the few things > that Smalltalk got wrong. I do not think so when I look at Java collection. I would say that the collections are a bit too static in their composition (missing uniqueOrdered) So if someone propose a good integration into pharo we will certainly integrate it. Now I'm curious to see if we can change the superclass of collection :) Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
