From: Marcelo M. <mm...@ac...> - 2005-12-14 20:06:44
|
Josh Cherry wrote: > On Wed, 14 Dec 2005, Marcelo Matus wrote: > > > I was thinking more about the problem and I guess we can get into a > > middle point, like this: > > > > 1.- when perl try to resolve overloading, force to receive a native > > integer, ie, if you have > > > > int foo(int); int foo(char *); > > > > then > > > > foo("1") -> always dispatch foo(char*); > > > Note that if this is implemented in the obvious way then in the case > of > > int foo(int); int foo(SomeClass); > > foo("1") will always be an error (which doesn't bother me so much, > but I'm not a Perl person). This is related to the thread we had a > while back about ints and doubles (Perl was converting my ints to > doubles when I incremented them, leading to analogous failures when I > called overloaded functions). well, yes, and that is the way it is working in 1.3.27, ie, foo("1") is accepted when there is only one declaration, but it fails with overloading. Maybe the solution is always accept "1" as an integer, but move the priority of integers way high, so: foo(int): foo("1") is ok foo(int), foo(char *): foo("1") -> dispatch foo(char*), foo("hello") -> dispatch foo(char *) foo(int), foo(SomeClass): foo("1") -> dispatch foo(int), foo("hello") -> error which probably captures the perl-ish 'int' personality as close as possible. In python we have something similar with 'bool', we need to put highest precedence value for it. Or maybe we can just put the same precedence for {foo(int), foo(char *)}, and then a warning will be issued saying that foo(int) shadows foo(char*), forcing the user to do something about it, like splitting the overload manually with %rename, or just accept the previous behavior. Anyway, I think there is no perfect solution for this, so, we just need to try to get the less bad possible scenario. So, I vote for: 1.- swig accepts a string as an int when the string is a number, ie foo("1") is ok, foo("hello) is an error. 2.- put the same precedence for 'char *' and 'int', so the user is warned for dangerous overloadings. After all, if perl can't distinguish between and 'int' and a 'string', that is exactly what equal precedence numbers means in the swig side. the only "problem" with that is that all the integer numbers will have to use the same precedence, but I don't think that is a major issue, since if in perl we can distinguish automatically between a string and and integer, why we will need to bother trying to distinguish automatically between 'unsigned short' and 'int'. Marcelo Marcelo > > Josh > > -- Joshua L. Cherry, Ph.D. NCBI/NLM/NIH (Contractor) > jc...@nc... > > > > > ------------------------------------------------------- This SF.net > email is sponsored by: Splunk Inc. Do you grep through log files for > problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD > SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ Swig-user mailing > list Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-user |