dict type?

[Seth Nickell]

On Sat, 2003-10-11 at 15:22, Havoc Pennington wrote:
> Hi,
> 
> Questioning the dict type. A method signature like this:
> 
>  foo (array<string> keys, array<int> values)
> 
> gives you equivalent performance and data transfer as the dict type,
> except that the values have homogeneous type.
> 
> Perhaps we should have an "any"/variant type:

>From the python viewpoint, a variant type might be nice to have
anyway... but I imagine that could be a PITA for C/C++ developers?

>  foo (array<string> keys, array<variant> values)
> 
> Would that be more useful and involve less code than
> the dict?

Dicts should map quite nicely to hashtables, which I would assume is a
common element in most programming systems. Or am I misunderstanding
something?

> One way to think about this is that array<variant> is essentially
> equivalent to a struct, while dict is essentially equivalent to a struct
> with a name for each struct field.

Or alternatively dict is equivalent to a GHashTable of GValues...

> I don't believe either the variant array or the dict maps all that well
> to a reasonable GLib/Qt API. You end up with GValue/QVariant which will
> be a pain to use, or with some kind of "marshal array into a struct"
> which would require code generation from an IDL.

What if dict were typed ala arrays?

> However, dict may well map nicely to a reasonable API in something like
> python, since you could dynamically build a python dict out of it.

Yes! If the "feature" is made non-explicit we can't wrapper it decently
in Python: we can't know when the two arrays are supposed to be related
by a "dict"-like relationship. If the dict type is kept, at the very
worst, it would be pretty easy for a developer making bindings for a
language that doesn't have dicts or hashtables to just produce a key
array and a value array in place of a dict!

-Seth