>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.
