2009/10/31 Martin McClure <[email protected]>: > 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 ]
]]
> Regards,
>
> -Martin
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
--
Best regards,
Igor Stasenko AKA sig.
CollectionFilter.st
Description: Binary data
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
