2009/10/31 Igor Stasenko <siguctua@gmail.com>:
2009/10/31 Martin McClure <martin@hand2mouse.com>:
Lukas Renggli wrote:
It always annoyed me that #keys and #values create a new collection object. Form an object-oriented stand-point of view, what would rather make sense is to return a collection that delegates to the dictionary.
+1, I've had similar thoughts.
I'd think DictionaryKeys would need to be a read-only collection. Otherwise, what would be the effect of DictionaryKeys>>add: on the underlying Dictionary? And even worse effects of trying to add to a DictionaryValues...
Yeah, i talked about this earlier in this topic. I think that given approach can be generalized to serve for multiple purposes.
Imagine a proxy object, which takes a collection and block with two arguments:
| dictKeys | dictKeys := CollectionFilter new collection: (Object methodDict) filter: [:coll :aBlock | Â Â Â Â coll keysDo: [:each | aBlock value: each ] ]. dictKeys asSet
There are many ways how this proxy can be used. For instance, a #reject: and #select: , in parallel we could have #rejectedBy: and #selectedBy: which creating a filter proxy instead of creating new collection:
CollectionFilter class>>collection: aCollection rejectedBy: rejectBlock  ^ self new collection: aCollection filter: [:coll :aBlock |    coll do: [:each | (rejectBlock value: each) ifFalse: [ aBlock value: each ]  ]]
That also has been generalized to stream. See Nile or gnu smalltalk for example.
Regards,
-Martin
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project