Stefan Sperling wrote:
> On Tue, Jun 16, 2009 at 04:07:26PM +0200, Neels Janosch Hofmeyr wrote:
>> That said, I see how the bindings sort of *need* it to be a different name.
>>
>> [[[
>> %hash_argout_typemap(changed_paths_p, svn_fs_path_change_t *)
>> +%hash_argout_typemap(changed_paths2_p, svn_fs_path_change2_t *)
>> ]]]
>>
>> The bindings code shouldn't be like that. after all, variable names can be
>> similar and hash tables can contain anything.
>
> Somehow this doesn't make sense to me...
> I must be missing something.
>
> Why do bindings depend on the name of variables, instead of the type?
> E.g. it's legal in C to omit variable names from function prototypes
> altogether. What would the bindings do then?
>
> If the type of values in a hash table changes, can't the bindings
> deal with this by making changes internally to the function,
> just like we do in C?
>
> I admit that I don't know much about how SWIG works, but relying
> on the names of variables seems really wrong. And from the short
> time I played with SWIG a long time ago I can't recall it having
> such a requirement.
The bindings *can* rely on the type, when the type is distinct enough. But
it's really hard to write a function that converts an apr_hash_t * of
arbitrary C data type keys and arbitrary C data type values into a Python
dictionary of Python object keys and Python object values. You rather need
to know the specifics of the data types inside the hash/dictionary. There
are two ways to do this: make a new typedef in C for every possible flavor
of apr_hash_t so the bindings can distinguish between them, or use
variable-name-based hints to pull that off.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2362486
Received on 2009-06-16 16:38:46 CEST