>> 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.
> 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.
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.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
