I am wondering how hard it would be to implement automatic casts from objects to basic types. You probably know what I mean... small example:
void fun(int a) { ... }
object i = Int(32); // Class offering a cast method
fun(i); // cast to int automatically
I admit that it introduces new traps and some complexity. Any opinions?
arne
you are not looking for automatic casts, but for the possibility to create a class that is compatible with basic types:
class Int(int realint) { inherit int; }
this is not yet possible, but it has been on my wish list for along time. it should be possible to inherit basic types or at least create classes that can pretend to be basic types and may be used in any place where basic types can be used now.
greetings, martin.
Actually, no. I do not want to have objects that are subclasses of basic types. I just want them to be casted to basic types where appropriate and possible. What you suggest is to treat basic types as classes aswell. Just think of all the cmods one would have to rewrite to support int-objects.
I know that java has this feature (called autoboxing/unboxing), although I guess that doesn't convince anybody here ;)
arne
On Mon, 18 Aug 2008, Martin B�hr wrote:
you are not looking for automatic casts, but for the possibility to create a class that is compatible with basic types:
class Int(int realint) { inherit int; }
this is not yet possible, but it has been on my wish list for along time. it should be possible to inherit basic types or at least create classes that can pretend to be basic types and may be used in any place where basic types can be used now.
greetings, martin.
On Mon, Aug 18, 2008 at 10:41:23AM +0200, Arne Goedeke wrote:
Actually, no. I do not want to have objects that are subclasses of basic types. I just want them to be casted to basic types where appropriate and possible.
deciding where it is appropriate and possible is the hard issue. not all places where it is possible also make it appropriate, therefore this decision must be an explicit one in the code.
if you want a class that is casted automatically then this fact needs to be codified in the class. and inheriting a basic type would be one way to do that.
What you suggest is to treat basic types as classes aswell. Just think of all the cmods one would have to rewrite to support int-objects.
they already have to support bigint objects so this should be easy.
other types may be more interesting in that respect.
but where is the difference? for automatic casts to work you still have to make all interfaces accept your Int class or teach pike that Int and int are equivalent. either way there needs to be something in the class that makes pike understand that. inherit int; is just the way to get that something into the class.
this does not mean that every int should be an object, but it would be nice if they consistently looked like one on the pike level.
greetings, martin.
On Mon, Aug 18, 2008 at 10:41:23AM +0200, Arne Goedeke wrote:
Actually, no. I do not want to have objects that are subclasses of basic types. I just want them to be casted to basic types where appropriate and possible.
deciding where it is appropriate and possible is the hard issue. not all places where it is possible also make it appropriate, therefore this decision must be an explicit one in the code.
if you want a class that is casted automatically then this fact needs to be codified in the class. and inheriting a basic type would be one way to do that.
What you suggest is to treat basic types as classes aswell. Just think of all the cmods one would have to rewrite to support int-objects.
they already have to support bigint objects so this should be easy.
Not quite; only places where integers outside the range -0x80000000 .. 0x7fffffff are meaningful support bignums. Note that bignums are automatically converted to plain integers as soon as they enter the range covered by INT_TYPE.
Supporting objects at all places where integers are accepted is a much more complicated operation. Also note that Pike has no concept of automatic casts; any casting of function arguments is up to the function receiving the arguments.
other types may be more interesting in that respect.
but where is the difference? for automatic casts to work you still have to make all interfaces accept your Int class or teach pike that Int and int are equivalent. either way there needs to be something in the class that makes pike understand that. inherit int; is just the way to get that something into the class.
this does not mean that every int should be an object, but it would be nice if they consistently looked like one on the pike level.
That whould interfere with the semantics of several low-level functions (eg objectp(), intp() et al).
greetings, martin.
On Mon, Aug 18, 2008 at 10:41:23AM +0200, Arne Goedeke wrote:
Actually, no. I do not want to have objects that are subclasses of basic types. I just want them to be casted to basic types where appropriate and possible.
deciding where it is appropriate and possible is the hard issue. not all places where it is possible also make it appropriate, therefore this decision must be an explicit one in the code.
I am not sure about that. The discussion is about fun(Int()) vs. fun((int)Int()). Its necessary to check the type of arguments at runtime anyway. At least for cmods its done automatically when using PIKEFUN, etc. Would not be to hard to implement a cast at that point. For native pike code its of cause different, but I guess that would not be too hard either. Still there exists quite some c code that would require hand-made changes (builtin_functions.c, etc). Also the type checker should never complain about object arguments at compile time then..
if you want a class that is casted automatically then this fact needs to be codified in the class. and inheriting a basic type would be one way to do that.
One could argue that that is encoded in the cast method and can be checked at compile-time only.
I am not sure if having automatic casts would do more harm than good. As I said before, it certainly adds new traps and hides things from someone who is reading code, looking for bugs, etc.
arne
On Mon, Aug 18, 2008 at 07:22:45PM +0200, Arne Goedeke wrote:
decision must be an explicit one in the code.
I am not sure about that. The discussion is about fun(Int()) vs. fun((int)Int()).
but how does pike know i want it casted at that point? pike can't tell Int() from Something() unless a special marker to do the cast is inside Int().
pike can't asume that everything that has a cast method for int should always be casted.
greetings, martin.
-0, IMO.
I find the laziness benefit of unexplicit casts done for you in a few specific type cases (parameters that accept a single basic type only) a bit doubtful, especially next to the prospect of added compexity in the type system. While there possibly are cases it would be useful to someone, the maintenance / complexity costs of having this festure at least to me seem at a disconnect from the potential value.
(Not like in the order of adding reflection to a language lacking it, for instance, which would probably have merited that added burden.)
pike-devel@lists.lysator.liu.se
-
Arne Goedeke -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Johan Sundstr�m (Achtung Liebe!) ＠ Pike (-) developers forum
-
Martin Bähr -
Martin Bähr