Dan Sugalski wrote:
>
>...
>
> I split the question into pieces here:
>
> >Why not merely have a vtable function that returns the type object which
> >knows its own name,
>
> I didn't see a point to the indirection.
>
> name = pmc->vtable[GET_NAME]();
>
> instead of:
>
> name = pmc->vtable[TYPE_OBJ]()->name;
Well the type name is a property of the type, not the object. The object
might have its own "name". My name is not PYTHON_PROGRAMMER. :-)
If you pass around the type then you will want its name, so the type
name must be in the type. The only question is whether there should be
optimized access to it on the object itself or not. In the Python world,
asking an object for its typename is not a common enough operation to
warrant a special slot.
Perl looks up its type object through a module name today. But if you're
going to have a pointer to the type anyhow then I don't see why the
module name is so important that it needs to be optimized.
Also, let's look beyond the virtual method. Where is the actual type
string pointer stored? It seems to me that it must either be on every
object of a type (memory waste) or on the type object.
>...
> We're going to call type a lot. Type returns either an absolute type number
> or a sub-type. (where subtype is INT/BIGINT/OBJECT for integer type
> queries, NUM/BIGNUM/OBJECT for floats, or one of the variety of string types)
Given the opportunity to redo Perl, why are INT, NUM and STRING magical
types? Also, why is FLOAT called NUM?
I would have expected a hierarchy that looks more like
object
number
integer
float
string
Ruby has a nicely documented class hierarchy:
http://www.zenspider.com/Languages/Ruby/QuickRef.html
> >and
> >does isa and can.
>
> For that there's no real reason, since I don't think they're going to be
> called all that often, relatively speaking. OTOH since we're not
> abstracting the rest out, and it doesn't otherwise buy anything at the low
> level, I don't see a point. (Well, not yet at least)
Types should be objects like anything else. Types should be able to have
methods They should be able to have properties. It would be cool if you
could pickle them and send them across the wire (true for Python
classes, but of course not types written in C). It should be possible to
put types (not type names, but types) in dictionaries as either keys or
values.
dispatch = {IntegerType: HandleInteger,
FloatType: HandleFloat,
StringType: HandleString}
def doit(obj):
func = dispatch[type(obj)]
func(obj)
Emulating this at the language level is pretty tricky and inefficient.
Paul Prescod
