optimizing select:thenCollect:
Locked
12
12
Re: optimizing select:thenCollect:
 
|
> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: optimizing select:thenCollect:
|
|
In reply to this post by Lukas Renggli
>>> To me the most important thing is that
>>> at all points in time I know exactly what changes when I compile a >>> method. Simple if you are in a class, you change that class, your change take precedence over trait methods. If you are in trait you change the traits => the classes using that trait got that changes except if they redefined the methods. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: optimizing select:thenCollect:
|
|
In reply to this post by Lukas Renggli
> So far I haven't seen a single example where traits would really help.
I think you're a bit to strong on this. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: optimizing select:thenCollect:
|
|
In reply to this post by Lukas Renggli
On Thu, Jul 16, 2009 at 5:04 PM, Lukas Renggli<[hidden email]> wrote:
> ((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. This is what I did in Nile: NSCollectionStream>>select: aBlock "Returns a new stream which contains a selection of elements in the receiver. All elements of the receiver are passed to aBlock. This is really like Collection>>select:." ^ NSSelectStream selectBlock: aBlock inputStream: self NSSelectStream being a kind of stream whose #next method iterate on the input stream: NSSelectStream>>next self inputStream do: [:each | (selectBlock value: each) ifTrue: [^ each]]. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: optimizing select:thenCollect:
|
|
but nobody care about what you did :)
Stef BTW it would be good to see if your stream implements the same interface as the great GNU smalltalk ones. Sorry I could not resist :( I'm in a really bad mood On Jul 18, 2009, at 12:26 AM, Damien Cassou wrote: > On Thu, Jul 16, 2009 at 5:04 PM, Lukas Renggli<[hidden email]> > wrote: >> ((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. > > This is what I did in Nile: > > NSCollectionStream>>select: aBlock > "Returns a new stream which contains a selection of elements in the > receiver. All elements of the receiver are passed to aBlock. This is > really like Collection>>select:." > ^ NSSelectStream selectBlock: aBlock inputStream: self > > NSSelectStream being a kind of stream whose #next method iterate on > the input stream: > > NSSelectStream>>next > self inputStream do: [:each | (selectBlock value: each) ifTrue: > [^ each]]. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |