Hi.
I just found that there is no WeakIdentityValueDictionary. But we have WeakValueDictionary, WeakKeyDictionary, WeakIdentityKeyDictionary. And to implement missing class I need to copy overrides from IdentityDictionary. And weak key dictionaries are implemented same way by duplicating code. And generally identity collections are not much different from equal collections but they still duplicate a lot of code with little difference: #hash or #identityHash, #= or #==. So I am wondering do we have alternative implementation with proper design? There are wishes to replace streams by XSteams. What about collections? Best regards, Denis |
Let us start with streams :) On Fri, Jun 2, 2017 at 11:20 AM, Denis Kudriashov <[hidden email]> wrote:
|
In reply to this post by Denis Kudriashov
Hi Denis,
On Fri, Jun 2, 2017 at 2:20 AM, Denis Kudriashov <[hidden email]> wrote:
The StrongTalk team reimplemented their Collections hierarchy to have much better modularity because their VM did the necessary inlining to create the efficient versions on the fly. This is what Scorch/Sista supports. Perhaps we should wait until it arrives, perhaps not, but certainly what you propose is a good idea whose time has almost come.
_,,,^..^,,,_ best, Eliot |
In reply to this post by Denis Kudriashov
I think design deficiencies of Pharo collections can be addressed with traits. Now Pharo has classes that mix: - public interface of some type of collection - implementation of numerous operations on collections (e.g. #collect:) - implementation of collection's interface (e.g. #do:) Also different interfaces (iteration, mutation) are mixed together as well. For example, Collection could be replaced by TIterable (iteration and other methods from Collection that don't require mutation) and TCollection (TIterable + adding and removing). TIterable then can also be used for things like iterators/views/slices. Similarly, SequenceableCollection -> TSequenceable (uses TIterable) and TSequenceableCollection (uses TCollection + TSequenceable). Dictionary -> TMap (uses TIterable) and TDictionary (uses TCollection + TMap). Perhaps also separate traits for immutable collections, that use iteration traits and know how to make modified versions of themselves and how to construct instance from stream. For hashed collections, separate traits could be made for equality- and identity-based collections. Perhaps they can even be made right now, without reorganizing whole collections hierarchy - just by moving corresponding methods into them. |
2017-06-04 19:32 GMT+02:00 webwarrior <[hidden email]>:
There was some work around it: https://hal.inria.fr/inria-00511902/file/main.pdf. (funny that it it was named Bloc ) |
Why has it been abandoned? |
In reply to this post by Denis Kudriashov
;) this is nice to write papers just to remember and document our experiments. On Sun, Jun 4, 2017 at 10:13 PM, Denis Kudriashov <[hidden email]> wrote:
|
In reply to this post by webwarrior
Lack of manpower :) We should have put a good engineer on it for 3-4 months.
More important stuff to do. Now I have the code. And we are about to release a better trait implementation with state. So if people want to play and redesign a collection library I'm really supporting the idea. Stef On Sun, Jun 4, 2017 at 10:10 PM, webwarrior <[hidden email]> wrote: Denis Kudriashov wrote |
Free forum by Nabble | Edit this page |