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.