Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Class instantiation and creation

2 views
Skip to first unread message

Dan Sugalski

unread,
Jun 9, 2003, 4:41:57 PM6/9/03
to perl6-i...@perl.org
Well, we can make objects and we can call methods on objects (at
least the interface is specified, if not actually implemented) but
actually building classes to make objects out of is still
unspecified. So, time to remedy that, after which I hope we can build
at least a simple "ParrotObject" class.

The issue is metadata. How do you declare a class' inheritance
hierarchy, its interfaces, its attributes, and its type? (At the very
least, there's probably more) I can see the following .

1) A class subclasses a single parent.
2) A class subclasses a single parent and adds attributes
3) A class subclasses multiple parents
4) A class subclasses multiple parents with extra attributes
5) A class adds attributes at runtime
6) A class adds parents at runtime

I'm not too worried about adding interfaces at runtime, as that
doesn't do anything more, really, than adding methods at runtime.
Either way's fine, it's just a bit of extra provided metadata that's
only there when you query it.

We're going to need to be able to do all these at runtime as well as
load time, the question is how.

It's possible to just go ahead and do it *all* at runtime, and have
no compile time component at all--just a series of "newclass,
addparent, addattribute" ops, assuming those are the op names we go
with. Classes just get created at code initialization time or
something.

It's also possible that, except for case #1, all these things can
only be done at compile time. (Which rules out 5 and 6) Classes are
declared exclusively with some sort of bytecode metadata and to
instantiate a new class you need a chunk of bytecode around. It's
possible that at least some of this is only doable with metadata in
bytecode, but the bytecode metadata segments can be easily created on
the fly.

Case #1 will definitely want to be doable with a single op, at
runtime. It's a reasonably common operation, as these things go, as
folks make anonymous child classes for single objects. I know there
are good reasons to be able to do that both from a user program
standpoint as well as for internal reasons. (Mainly to allow
per-object method overriding without having to go through too many
hoops)

Part of me wants to go all-metadata for cases 2, 3, and 4, since I'm
wary of the issues of doing what should be an atomic action in
multiple ops. There's a loss of atomicity at the program level there,
and if the classes override some of the actions (if we even allow
that--does anyone allow overloading the subclassing operation?) it
could get messy.

#5 really has to be metadata based, as it'll be expensive as it is.
Refiguring the attribute array is a constant-time operation, more or
less, so doing it 6 times to add in 6 attributes seems... suboptimal.
If we don't do it with metadata we'll need ops that allow adding in
multiple elements in one go.

#6, well... I'm not sure we should even allow #6, at least as part of
the base parrot object system, but since we're going to do it anyway,
we might as well do it right. The big issue with #6 being the same as
#5--potentially needing to add in multiple attributes. That argues
for a metadata approach, though alterations using metadata are dodgy.

Anyone got any feelings or opinions on this, besides "Why yes, I want
an object system"? :) Class-based info I may be missing would also be
welcome.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

Mark A. Biggar

unread,
Jun 9, 2003, 5:07:33 PM6/9/03
to Dan Sugalski, perl6-i...@perl.org
Dan Sugalski wrote:
> Well, we can make objects and we can call methods on objects (at least
> the interface is specified, if not actually implemented) but actually
> building classes to make objects out of is still unspecified. So, time
> to remedy that, after which I hope we can build at least a simple
> "ParrotObject" class.
>
> The issue is metadata. How do you declare a class' inheritance
> hierarchy, its interfaces, its attributes, and its type? (At the very
> least, there's probably more) I can see the following .
>
> 1) A class subclasses a single parent.
> 2) A class subclasses a single parent and adds attributes
> 3) A class subclasses multiple parents
> 4) A class subclasses multiple parents with extra attributes
> 5) A class adds attributes at runtime
> 6) A class adds parents at runtime

Why not just have 1, 2 and 3 be degenerate cases 4?

> We're going to need to be able to do all these at runtime as well as
> load time, the question is how.
>
> It's possible to just go ahead and do it *all* at runtime, and have no
> compile time component at all--just a series of "newclass, addparent,
> addattribute" ops, assuming those are the op names we go with. Classes
> just get created at code initialization time or something.

Would "adparent" replacate the metadata of the parent into the metadata
of the child or will we need to walk the inheritence tree to get the
metadata about inherited attributes?

>
> Part of me wants to go all-metadata for cases 2, 3, and 4, since I'm
> wary of the issues of doing what should be an atomic action in multiple
> ops. There's a loss of atomicity at the program level there, and if the
> classes override some of the actions (if we even allow that--does anyone
> allow overloading the subclassing operation?) it could get messy.
>
> #5 really has to be metadata based, as it'll be expensive as it is.
> Refiguring the attribute array is a constant-time operation, more or
> less, so doing it 6 times to add in 6 attributes seems... suboptimal. If
> we don't do it with metadata we'll need ops that allow adding in
> multiple elements in one go.

Another possibility is to have an "addslots N" op to pre-extend the
class and only dynamically extend if necessary.

--
ma...@biggar.org
mark.a...@attbi.com

Matt Fowles

unread,
Jun 9, 2003, 9:15:01 PM6/9/03
to Dan Sugalski, perl6-i...@perl.org
Dan Sugalski wrote:

> The issue is metadata. How do you declare a class' inheritance
> hierarchy, its interfaces, its attributes, and its type? (At the very
> least, there's probably more) I can see the following .
>
> 1) A class subclasses a single parent.
> 2) A class subclasses a single parent and adds attributes
> 3) A class subclasses multiple parents
> 4) A class subclasses multiple parents with extra attributes
> 5) A class adds attributes at runtime
> 6) A class adds parents at runtime

How about removing parents or attributes at runtime?


Matt

Gopal V

unread,
Jun 10, 2003, 2:07:32 AM6/10/03
to perl6-i...@perl.org
If memory serves me right, Dan Sugalski wrote:
> It's possible to just go ahead and do it *all* at runtime, and have
> no compile time component at all--just a series of "newclass,
> addparent, addattribute" ops, assuming those are the op names we go
> with. Classes just get created at code initialization time or
> something.

That would be cool .. a lot easier to debug this kind of thing ,
especially when you could dump it as imcc and have it constant
evaluated as a bytecode segment (wishful thinking ;)

Question #1 : Are classes allowed to have fields ?
Question #2 : Visibility ?
Question #3 : Static methods ?
Question #4 : Static constructors ?
Question #5 : Destructor semantics ..

Questions #3 & #4 can be emulated and #2 is only optional but #1 & #5
are of concern ..

> instantiate a new class you need a chunk of bytecode around. It's
> possible that at least some of this is only doable with metadata in
> bytecode, but the bytecode metadata segments can be easily created on
> the fly.

Hmm... like compile some imcc on the fly ?

> Anyone got any feelings or opinions on this, besides "Why yes, I want
> an object system"? :) Class-based info I may be missing would also be
> welcome.

"Why who wouldn't ?"

How would the override of a method happen ? ... would it be purely by
name or would you provide some way to force a method to override
another of a different name ? .. Ie add a method forcibly over an
occupied slot ?.

Gopal
--
The difference between insanity and genius is measured by success

0 new messages