On Mar 26, 2007, at 8:11 PM, Theodore H. Smith wrote:
>>> if dict.HasKey("bla") then
>>> value = dict.value("bla")
>>> else
>>> value = NewBla
>>> dict.value("bla") = Value
>>> end if
>>
>> Actually, in Rb I'd do this:
>>
>> if not dict.HasKey("bla") then
>> dict.Value("bla") = NewBla
>> end if
>> value = dict.Value("bla")
>
> Your version has a worst case two accesses to .Value, where as mine
> as 1 access worst case. So mine is clearly faster.
Lacking your divine insight, I wrote some timing tests, and found no
difference. But I didn't claim that my code was faster. It does
achieve the same result in fewer lines.
>
>> But this misses my point, which is that the Rb Dictionary allows you
>> to store Nil as a value, and so distinguishes between the cases
>> d has a key-value pair ("bla", nil) and d has no key-value pair with
>> key = "bla". Your class does not. Either is a reasonable design
>> choice, though I prefer the former.
>
> Such considerations are abstract until I see a real world example
> where we need nil stored.
>
> I've never seen any. And I use dictionaries a lot.
I have seen real world examples.
>
> For example, when I'm doing multiple replace all on strings, I use an
> ElfDataDictionary to do the heavy lifting. If a user wants to replace
> a character with "", there is an ElfData object with 0 length, and
> the ElfDataDictionary just stores that value.
>
> Actually, I can't even think of a case where the user wants to
> replace a string with "". My most common use these days is to do
> Unicode 5.0 compliant lower/uppercasing, using my ElfDataDictionary
> class. There, the user doesn't want to replace a character with "" or
> with nil (which makes no sense), but just another character.
>
> And finally, I did address your point.
>
> nil, as I said, is just another special value. Whether it's nil or
> MySpecialNilLikePlaceHolder doesn't matter. If the user really needs
> nil in his own code, he can replace MySpecialNilLikePlaceHolder with
> nil once he gets the value out. With ElfDataDictionary, I use the
> ElfData.Empty object for nil, which works just fine. It's one object
> shared throughout the entire plugin, and it has a length of 0, so
> it's "nil-like".
>
> You could object that it's one extra test to replace
> MySpecialNilLikePlaceHolder with nil. But it's also one extra call
> to .HasKey if you want to avoid that test. The differnence is that
> the test against MySpecialNilLikePlaceHolder is much quicker
> than .HasKey, as it's just comparing one object's address against
> another. And the amount of code the user must type is the same.
>
> So even in theory, my approach is just as easy to code. And mine is
> faster. And most importantly it's just theory. I've never seen a case
> where someone wants to store nil and some kind of place holder object
> won't do equally well.
Perhaps you've not seen everything, or even the same things I've seen.
Charles Yeomans
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
