[squeak-dev] Re: Ideas about sets and dictionaries

Igor Stasenko siguctua at gmail.com
Thu Nov 12 03:14:17 UTC 2009


2009/11/12 Andreas Raab <andreas.raab at gmx.de>:
> Igor Stasenko wrote:
>>>
>>> Seriously, how *would* you address this problem if you weren't trying to
>>> make it fit exactly?
>>
>> err.. you don't mind, if i remind you that there a lot of ugly hacks
>> around , like compact classes,
>> implicit message sends (#class , #==) and nobody saying a word against
>> them, #ifTrue:ifFalse: inlining
>> instead of true message send and finally immediate objects -
>> smallintegers which you can't subclass?!?!
>>
>> Do you really think that way how to represent the presence of nil in
>> set worst than the listed above?
>
> No, but that's not my point.

Ok, then, sorry for above :)

> There are reasons why the hacks you refer to
> are there (performance, compactness) but we measure those tradeoffs against
> a "canonical" implementation, i.e., one that does not require these hacks.
> I'm trying to do the same - I am asking for how a Set with nil would look
> like if you'd start it from scratch so that we can compare and contrast
> between the proposals.
>
i think it will look similar unless you introduce a discrimination,
that set could contain
any object except some filler. Be it nil or some other unique object
not really matters, because
the main condition not met:
- pick any existing, or create a new Set

- pick any object in object memory, no matter where it comes from and
try to put it in that Set.
If set is able to handle all such objects without discrimination, it
is good set.. if not - bad.

Does that sounds reasonable?

> For example, the tradeoff in Randal's proposal (having a flag) is that we a)
> add a variable to all sets (the flag) b) change the implementation from
> comparing with nil to comparing with the flag and c) that Sets cannot
> contain the flag element itself. That sounds quite reasonable to me.
>
> Cheers,
>  - Andreas
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list