At 02:57 PM 9/26/2001 -0700, Paul Prescod wrote: >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.
Since variables of a particular type share a vtable (they each have individual vtable pointers in their PMCs, but the pointers all point to the same vtable) the type name is ultimately stored in the type. Whether it's worth an entry's a separate issue. I thought it was a good idea at the time... :) It's out now. >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. It doesn't. D'oh! > >... > > 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? Well, they're semi-abstract types. INT is the platform-native integer, NUM is the platform-native float. STRING is our "string with encoding, charset, and language" structure. And I have no idea why FLOAT is 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 How things transmute is up to the type to decide. The basic perl scalar will go int->bigint or int->float->bigfloat (or string->int or string->float) as needed, but other types might not do that. And I'm still unsure of when floats should go to bigfloats. Arguably it's at the first loss of precision, in which case we might as well skip floats entirely. ;) > > >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. They will be. Each package has its own hash that everything hangs off of, so you'll be able to treat it like an object if you're so inclined. ;) >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). One of the things on the list 'o stuff is to be able to pack up an object, and everything it needs, and send it down the wire to another machine and run it there. Parrot's got provisions in it for safe compartments with resource limits and quotas and suchlike things to make it less dangerous. (You'll notice I didn't say safe--I know better...) >It should be possible to >put types (not type names, but types) in dictionaries as either keys or >values. Sure, you can do that now in perl and I don't see why that should change for Parrot. Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
