>> Having an iterator class also avoids having to implement all these >> iteration methods over and over again, e.g. in visitors. > > lukas do you have an example because I do not see why > Also with traits you just have to implement do: and you get all the > other one for free.
The class and metaclass system of Smalltalk is already at the limit of complexity that I can handle. Traits make this existing model even more complicated. Even with support from a trait aware browser I find traits extermely hard to use. To me the most important thing is that at all points in time I know exactly what changes when I compile a method. This is absolutely not clear when using traits. So far I haven't seen a single example where traits would really help. As Paolo suggested the problem can be simply solved by introducing an Iterable superclass to Collection and Stream. Now you might say that this only works if I am not inheriting from some other important class. True, an Iterable-trait would avoid that problem. However, adding such a trait to an existing hierarchy looks extremely scary to me. It potentially pollutes an existing protocol with existing code that is most likely unrelated (or maybe it already contains some iterator code for something else). 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. >> 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? Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
