dict type?

[David Zeuthen]

On Tue, 2003-10-14 at 00:54, Seth Nickell wrote:
> > Except that you rapidly end up having to use GValues for the values in
> > GLib and whatever the KDE equivalent is over in that camp because you
> > need to track the type of the keys. Unless you only allow dictionaries
> > with homogeneous values. I think that is what Havoc was trying to avoid
> > (the small, tiny, miniscule, itsty-bitsty annoyance of having to deal
> > with GValues). Personally, I don't see the GValue thing as a huge
> > problem providing people use it rationally (i.e. everything should not
> > be a dictionary; only use dictionaries when you need to, etc).
> 
> GValues are something of a PITA. I think homogenously typed dictionaries
> is probably the norm in real world usage anyway.
> 

Maybe, but there are always special cases. I, for one, would prefer to
be able to invoke this method

 dict<string, variant> getProperties()

on some object. I'm not sure how this would look if the dict type got
killed; Would it involve return two arrays in a struct or using the,
IMHO, in/out stuff on the parameters given? Either way seems kind of
borken to me..

For normal real world usage couldn't people get away with

 dict<string, int> getSomething()

and not having to worry about e.g. GValues for glib?

I also think the two array approach is somewhat broken since the careful
programmer would have to check that the arrays are of the same size and
somehow report an error if this is not so. Of course this can be handled
in bindings code but still some people use the raw C API without any
support libraries (for one reason or another).

While we're on the subject of types, will there be a reference type, so
apps distributed on many hosts can pass references to objects around?

Just my ¤0.01782.

Thanks,
David