Quick OO .isa question

1 view
Skip to first unread message

Ingo Blechschmidt

unread,
Jul 11, 2005, 9:16:40 AM7/11/05
to perl6-l...@perl.org
Hi,

class Foo {}
class Bar is Foo {}

Bar.new.isa(Object); # true
Bar.new.isa(Class); # false
Bar.new.isa(Foo); # true
Bar.new.isa(Bar); # true
# These are clear, I think.

Bar.isa(Object); # true
Bar.isa(Class); # true
Bar.isa(Foo); # ? (my guess: false)
Bar.isa(Bar); # ? (my guess: false)


--Ingo

--
Linux, the choice of a GNU | We are Pentium of Borg. Division is futile.
generation on a dual AMD | You will be approximated.
Athlon! |

Stevan Little

unread,
Jul 11, 2005, 9:46:30 AM7/11/05
to Ingo Blechschmidt, perl6-l...@perl.org
Ingo,

On Jul 11, 2005, at 9:16 AM, Ingo Blechschmidt wrote:
> Hi,
>
> class Foo {}
> class Bar is Foo {}
>
> Bar.new.isa(Object); # true
> Bar.new.isa(Class); # false
> Bar.new.isa(Foo); # true
> Bar.new.isa(Bar); # true
> # These are clear, I think.

Yes, these all make sense to me.

>
> Bar.isa(Object); # true
> Bar.isa(Class); # true
> Bar.isa(Foo); # ? (my guess: false)
> Bar.isa(Bar); # ? (my guess: false)

I am not sure about this. I think that .isa as a class method should
behave much as it does for an instance method. If we start supporting
things like Bar.isa(Class) then we start exposing the soft underbelly
of the meta-model to the outside world. Which IMO might not be a good
idea.

Stevan

Ingo Blechschmidt

unread,
Jul 11, 2005, 12:30:13 PM7/11/05
to perl6-l...@perl.org
Hi,

Stevan Little wrote:
> On Jul 11, 2005, at 9:16 AM, Ingo Blechschmidt wrote:
>> Bar.isa(Object); # true
>> Bar.isa(Class); # true
>> Bar.isa(Foo); # ? (my guess: false)
>> Bar.isa(Bar); # ? (my guess: false)
>
> I am not sure about this. I think that .isa as a class method should
> behave much as it does for an instance method. If we start supporting
> things like Bar.isa(Class) then we start exposing the soft underbelly
> of the meta-model to the outside world. Which IMO might not be a good
> idea.

ah, you mean there could be problems, when, for example, Bar is not
actually a Class, but a PersistentClass or something, and one tries to
check whether a given $obj is a class by using .isa? I.e.:
my $obj = get_a_class_or_something_else();
if $obj.isa(Class) {...} # XXX

IIRC, Larry once said that Class is actually a role, so then both the
builtin standard class object and PersistentClass .does(Class), so this
shouldn't be a problem, because one should use .does anyway (or ~~).

So, to fix the above snippet:
my $obj = get_a_class_or_something_else();
if $obj.does(Class) {...} # or
if $obj ~~ Class {...}


--Ingo

--
Linux, the choice of a GNU | There are no answers, only
generation on a dual AMD | cross-references.
Athlon! |

Ingo Blechschmidt

unread,
Jul 11, 2005, 3:14:17 PM7/11/05
to perl6-l...@perl.org
Hi,

Stevan Little wrote:
> Actually I was thinking that MyClass.isa(...) would work much as it
> did in Perl 5 (like an instance). But that access to the underlying
> MyClass class instance would not be as simple. Something like
> ::MyClass would provide access to the Class instance.
>
> class Foo {}
> Foo.isa(Object) # true
> Foo.isa(Foo) # true
> Foo.isa(Class) # false
>
> ::Foo.isa(Object) # true
> ::Foo.isa(Class) # true
> ::Foo.isa(Foo) # false
>
> However, this is not speced anywhere, so I am just really making stuff
> up out of my head :)

I've always thought Foo and ::Foo were synonyms (except maybe in
signatures, but that's another thread). I.e.:

Foo =:= ::Foo =:= ::("Foo"); # true

And all of these are (except if you do metamodel hackery) Class objects,
i.e. the following all work and are semantically identical:

my $foo = Foo .new;
my $foo = ::Foo .new;
my $foo = ::("Foo").new;


Am I wrong?


--Ingo

--
Linux, the choice of a GNU | Black holes result when God divides the
generation on a dual AMD | universe by zero.
Athlon! |

Ingo Blechschmidt

unread,
Jul 11, 2005, 3:25:05 PM7/11/05
to perl6-l...@perl.org
Hi,

Larry Wall wrote:
> On Mon, Jul 11, 2005 at 09:46:30AM -0400, Stevan Little wrote:
> : On Jul 11, 2005, at 9:16 AM, Ingo Blechschmidt wrote:
> : > Bar.isa(Object); # true


> : > Bar.isa(Class); # true
> : > Bar.isa(Foo); # ? (my guess: false)
> : > Bar.isa(Bar); # ? (my guess: false)
> :
> : I am not sure about this. I think that .isa as a class method should
> : behave much as it does for an instance method.
>

> Right, or you can't easily decide whether Bar isa Foo in the abstract.
> You need to able to reason about the relationships of user-defined
> classes in the absence of instances.

ah, of course, that makes sense.

> So anyway, that gives us something like:
>
> Bar.isa(Foo); # true
> Bar.isa(Bar); # true
> Bar.isa(Class) # false presuming Class is only a role
> Bar.does(Class) # true
> Bar.does(CLASS) # false
> Bar.meta.isa(Foo); # false
> Bar.meta.isa(Bar); # false
> Bar.meta.does(Class) # false
> Bar.meta.isa(CLASS) # false presuming CLASS is only a role
> Bar.meta.does(CLASS) # true

These make perfect sense, too. And there's a clear distinction between
Bar and Bar.meta, so I'm absolutely fine with that :)


--Ingo

--
Linux, the choice of a GNU | When cryptography is outlawed, bayl bhgynjf
generation on a dual AMD | jvyy unir cevinpl!
Athlon! |

Stevan Little

unread,
Jul 11, 2005, 3:01:55 PM7/11/05
to Ingo Blechschmidt, perl6-l...@perl.org
Ingo,

On Jul 11, 2005, at 12:30 PM, Ingo Blechschmidt wrote:
>> I am not sure about this. I think that .isa as a class method should
>> behave much as it does for an instance method. If we start supporting
>> things like Bar.isa(Class) then we start exposing the soft underbelly
>> of the meta-model to the outside world. Which IMO might not be a good
>> idea.
>
> ah, you mean there could be problems, when, for example, Bar is not
> actually a Class, but a PersistentClass or something, and one tries to
> check whether a given $obj is a class by using .isa? I.e.:
> my $obj = get_a_class_or_something_else();
> if $obj.isa(Class) {...} # XXX

Actually I was thinking that MyClass.isa(...) would work much as it did

in Perl 5 (like an instance). But that access to the underlying MyClass
class instance would not be as simple. Something like ::MyClass would
provide access to the Class instance.

class Foo {}
Foo.isa(Object) # true
Foo.isa(Foo) # true
Foo.isa(Class) # false

::Foo.isa(Object) # true
::Foo.isa(Class) # true
::Foo.isa(Foo) # false

However, this is not speced anywhere, so I am just really making stuff
up out of my head :)

> IIRC, Larry once said that Class is actually a role, so then both the


> builtin standard class object and PersistentClass .does(Class), so this
> shouldn't be a problem, because one should use .does anyway (or ~~).

Yes, most of the basic types (Array, Scalar, Class, Hash, etc.) I
always assumed would be Roles, while the concrete classes which
incorporate these roles will be in the Perl6::* namespace.

But again, I am just making stuff up here :)

Stevan

Larry Wall

unread,
Jul 11, 2005, 3:07:22 PM7/11/05
to perl6-l...@perl.org
On Mon, Jul 11, 2005 at 09:46:30AM -0400, Stevan Little wrote:
: Ingo,

:
: On Jul 11, 2005, at 9:16 AM, Ingo Blechschmidt wrote:
: >Hi,
: >
: > class Foo {}
: > class Bar is Foo {}
: >
: > Bar.new.isa(Object); # true
: > Bar.new.isa(Class); # false
: > Bar.new.isa(Foo); # true
: > Bar.new.isa(Bar); # true
: > # These are clear, I think.
:
: Yes, these all make sense to me.
:
: >
: > Bar.isa(Object); # true
: > Bar.isa(Class); # true
: > Bar.isa(Foo); # ? (my guess: false)
: > Bar.isa(Bar); # ? (my guess: false)
:
: I am not sure about this. I think that .isa as a class method should
: behave much as it does for an instance method.

Right, or you can't easily decide whether Bar isa Foo in the abstract.


You need to able to reason about the relationships of user-defined
classes in the absence of instances.

: If we start supporting

: things like Bar.isa(Class) then we start exposing the soft underbelly
: of the meta-model to the outside world. Which IMO might not be a good
: idea.

Bar.isa(Class) probably false in any event, since I think Class
is probably a role rather than a class. But "Class" is almost
certainly not the name of the metaclass either. Or at least,
it's not the name of *both* metaclasses (counting the Class role
as one of them). Basically every user-defined class has a Platonic
description (known as its "Class") and an Aristotelian description
(known as its "MetaClass"). If "Class" is a valid name for a class,
it's the Platonic one, not the Aristotelian one, and it would be
a class only because "Class" can refer either to the role or to an
anonymous class generated from the role, if we follow the idea that Int
is both a role and a class. So maybe Bar.isa(Class) in that sense.
Or maybe we should force .isa false even if there is an associated
anonymomus class, just to keep things straight.

So what is certainly true is that Bar.does(Class), where the Class role
describes the Platonic interface of items like Bar. That is to say,
Bar is the stand-in for all the members of its class when you don't
actually have a member. Its Platonic role is to know about Barness,
not about classness. We call call it the dispatcher class because
it knows how to dispatch things of type Bar whether you actually have
an instance of type Bar or not. That's why method calls on it can do
things like call constructors. But it doesn't know much about any of
the grubby Aristotelian workings of the metaclass. It just knows there
is one, and that it can delegate all the messy practicalities to it.
I suspect the metaclass of "Class" actually has the name "class" or
"CLASS", and the metaclass of a Role is actually "role" or "ROLE".
Perhaps the "class" and "role" keywords are just specific examples
of the grammar being smart enough to treat declared metaclasses as
BEGIN analogues. But maybe it's smarter to keep the "class" and "CLASS"
identifiers at arms length from each other. (If for no other reason,
to keep our sanity while discussing them.)

So anyway, that gives us something like:

Bar.isa(Foo); # true
Bar.isa(Bar); # true
Bar.isa(Class) # false presuming Class is only a role
Bar.does(Class) # true
Bar.does(CLASS) # false
Bar.meta.isa(Foo); # false
Bar.meta.isa(Bar); # false
Bar.meta.does(Class) # false
Bar.meta.isa(CLASS) # false presuming CLASS is only a role
Bar.meta.does(CLASS) # true

You know, this class/role distinction might just be what saves our
collective bacon on the usual infinite regress of metaclasses, if a
metaclass turns out to be an object of anonymous class but named
role. The bootstrap might reside entirely in the code that constructs
the metaclass instance of anonymous class but filling the CLASS role
in its abstract interface.

I mentioned the idea of autogenerating a class Int from a role Int,
but maybe some roles don't allow themselves to be autogenerated into
classes, and maybe CLASS is one of them. And it sounds to me like
the absence of that feature is caused simply by ROLE's autogenerate
interface being left with an implementation of {...} and not overridden
in the anonymous metaclass representing the CLASS role.

So I guess the deep answer to the infinite recursion problem is that,
yes, it's metaclasses all the way down, but if you actually try to
pursue it, you'll at some point run into "method not yet implemented"
because nobody has cared about it that deeply yet. So we basically
get the possibility of mapping to anyone's metamodel without actually
having to commit to the fanciest one. I think I like that, even if
I don't understand it. Or maybe *because* I don't understand it.

Larry

Chromatic

unread,
Jul 11, 2005, 4:26:11 PM7/11/05
to Ingo Blechschmidt, perl6-l...@perl.org
On Mon, 2005-07-11 at 15:16 +0200, Ingo Blechschmidt wrote:

> Bar.new.isa(Object); # true
> Bar.new.isa(Class); # false
> Bar.new.isa(Foo); # true
> Bar.new.isa(Bar); # true

I'd like to go on a tangent to suggest that anyone who uses .isa() in
actual real code ought to be doing something really really tricky, for
which there absolutely is no other solution.

Alternately, it's okay with me if .isa() is actually syntactic sugar
for .does(), thought I don't expect much agreement on that.

-- c

Larry Wall

unread,
Jul 11, 2005, 4:42:19 PM7/11/05
to perl6-l...@perl.org
Though, arguably, if one is a true Platonist, one should view roles
as Aristotelian, and base classes as Platonic and therefore more
"real"...but I'm more of an Aristotelian myself, so I tend to think
of the Platonic ideals as less real than reality.

Whatever. Both Plato and Aristotle would probably have hated our
modern conceptions of what they thought. But I suspect Plato would
have liked Smalltalk or ML, while Aristotle would doubtless be
programming in something like Self, or maybe C...

Larry

Stevan Little

unread,
Jul 11, 2005, 5:37:40 PM7/11/05
to Ingo Blechschmidt, perl6-l...@perl.org
Ingo,

Probably not, it is more likely that I am wrong :)

However, this does bring up the point of how one can access the
class(Foo), meaning the instance of "Class" which represents Foo.

I for one think whatever it is it should involve a colon :P

Stevan

Stevan Little

unread,
Jul 11, 2005, 5:41:41 PM7/11/05
to Larry Wall, perl6-l...@perl.org

On Jul 11, 2005, at 3:07 PM, Larry Wall wrote:
>
> Bar.meta.does(CLASS) # true

To me this is just code-reuse on the meta-level. Much like in smalltalk:

MetaClass isa
ClassDescription isa
Behavior isa
Object

and:

Class isa
ClassDescription isa
Behavior isa
Object

using a Role in the meta-level should be no different then using it on
the user-level, it is just another means of code-reuse.

Stevan

Stevan Little

unread,
Jul 11, 2005, 5:35:41 PM7/11/05
to Larry Wall, perl6-l...@perl.org

Larry ,

At the risk of essentially signing my own committal papers for the
local looney bin, I have to say that this make sense to me. But I have
a few questions and requests for clarification :)

On Jul 11, 2005, at 3:07 PM, Larry Wall wrote:

No, the metaclass is called MetaClass of course :)

But if I want to be picky, then I should point out that:

MetaClass.isa(Class); # false
MetaClass.isa(Object); # true

Because MetaClass is really just a plain old class which just happens
to also take part in it's own definition.

> Or at least,
> it's not the name of *both* metaclasses (counting the Class role
> as one of them). Basically every user-defined class has a Platonic
> description (known as its "Class") and an Aristotelian description
> (known as its "MetaClass").

So am I correct in my assumption that by "Platonic" you mean that the
"Class" of a user-defined class is not really meant to deal with the
"guts" of what makes up a class. That it is erring towards the pure and
clean more then towards the practical.

And by "Aristotelian" you mean much the opposite (sort of). That the
"MetaClass" of a user-defined class is where all the "guts" of the
class resides. It is a full description of the structure of the
user-defined class, and all it's ugly "practicallities".

So going away from philosophy 101 here, and back to CS, it could be
said that a "Class" has-a "MetaClass" (although not in the strict
user-level-OO sense of the word).

Am I correct in my assumptions? Because if so, then this paragraph...

> So what is certainly true is that Bar.does(Class), where the Class role
> describes the Platonic interface of items like Bar. That is to say,
> Bar is the stand-in for all the members of its class when you don't
> actually have a member. Its Platonic role is to know about Barness,
> not about classness. We call call it the dispatcher class because
> it knows how to dispatch things of type Bar whether you actually have
> an instance of type Bar or not. That's why method calls on it can do
> things like call constructors. But it doesn't know much about any of
> the grubby Aristotelian workings of the metaclass. It just knows there
> is one, and that it can delegate all the messy practicalities to it.

... makes sense to me.

> I suspect the metaclass of "Class" actually has the name "class" or
> "CLASS", and the metaclass of a Role is actually "role" or "ROLE".
> Perhaps the "class" and "role" keywords are just specific examples
> of the grammar being smart enough to treat declared metaclasses as
> BEGIN analogues. But maybe it's smarter to keep the "class" and
> "CLASS"
> identifiers at arms length from each other. (If for no other reason,
> to keep our sanity while discussing them.)

Sanity? bah! it's overratted, especially when discussing meta-models :)

>
> So anyway, that gives us something like:
>
> Bar.isa(Foo); # true
> Bar.isa(Bar); # true
> Bar.isa(Class) # false presuming Class is only a role
> Bar.does(Class) # true
> Bar.does(CLASS) # false
> Bar.meta.isa(Foo); # false
> Bar.meta.isa(Bar); # false
> Bar.meta.does(Class) # false
> Bar.meta.isa(CLASS) # false presuming CLASS is only a role
> Bar.meta.does(CLASS) # true
>
> You know, this class/role distinction might just be what saves our
> collective bacon on the usual infinite regress of metaclasses, if a
> metaclass turns out to be an object of anonymous class but named
> role.

What difference does it matter if
$obj.meta.meta.meta.meta.meta.meta.meta.meta.meta is possible or not?
All the stuff I have read so far seems to say that at some point in all
object models there is a cycle. That cycle is basically where you have
something which is an instance of itself (Object is an instance of
Class, Class is a subclass of Object, Class is an instance of Class). I
mean is infinite regress really a bad thing?

> The bootstrap might reside entirely in the code that constructs
> the metaclass instance of anonymous class but filling the CLASS role
> in its abstract interface.

I am ignoring the bootstrap idea for the time being in the prototype,
as it tended to muddle all my previous metamodel attempts, and I can
always refactor to it in the end. However, I found that the bootstrap
is either best placed at the point of the cycle (like in CLOS) or
spread throughout the basic classes (like Smalltalk (or at least
Squeak) seems to be).

Where that point in the Perl 6 model is, I have yet to find out, but I
am sure it will show itself soon enough.

> I mentioned the idea of autogenerating a class Int from a role Int,
> but maybe some roles don't allow themselves to be autogenerated into
> classes, and maybe CLASS is one of them. And it sounds to me like
> the absence of that feature is caused simply by ROLE's autogenerate
> interface being left with an implementation of {...} and not overridden
> in the anonymous metaclass representing the CLASS role.
>
> So I guess the deep answer to the infinite recursion problem is that,
> yes, it's metaclasses all the way down, but if you actually try to
> pursue it, you'll at some point run into "method not yet implemented"
> because nobody has cared about it that deeply yet.

I disagree with this. You hit the object-model cycle and it will never
stop.

> So we basically
> get the possibility of mapping to anyone's metamodel without actually
> having to commit to the fanciest one.

I am not 100% sure of this either, however, I do think the Perl 6
object model is robust enough to be able to map to or mimic any other
object model out there. In fact Perl 5 is robust enough to do this too
:)

Stevan

Stevan Little

unread,
Jul 11, 2005, 5:47:07 PM7/11/05
to chromatic, perl6-l...@perl.org, Ingo Blechschmidt
chromatic,

I actually agree with you on that. But I would like to clarify it to
say that:

Foo.isa(Bar) # Foo.meta.isa(Bar) || Foo.meta.does(Bar)

... meaning that the .isa() which is supposed to be aliased into the
class from .meta is actually this.

The same too could be said for the .meta aliased .does() as well.

I see a reason to differentiate between roles and classes on the
metalevel, but the argument is not as strong on the user-level.

Stevan

>
> -- c
>
>

Chromatic

unread,
Jul 11, 2005, 5:56:47 PM7/11/05
to Stevan Little, perl6-l...@perl.org
On Mon, 2005-07-11 at 17:47 -0400, Stevan Little wrote:

> I actually agree with you on that. But I would like to clarify it to
> say that:
>
> Foo.isa(Bar) # Foo.meta.isa(Bar) || Foo.meta.does(Bar)
>
> ... meaning that the .isa() which is supposed to be aliased into the
> class from .meta is actually this.

I've always thought that .does() should check .isa() as well. That's
how Class::Roles works in Perl 5.

If you *really* need to know that Bar inherits from Foo, there's .isa().
If all you really care about is that Bar is Liskov-a-rific with respect
to Foo, use .does(), which checks that Bar inherits from or does the
role of Foo, whether it mixes in any methods or not.

Have I mentioned before that I think you should be able to say:

class Foo
{
method foo { ... }
method more_foo { ... }
}

class Bar does Foo
{
method foo { ... }
}

... probably get a compile-time error that Bar doesn't support
more_foo()?

> I see a reason to differentiate between roles and classes on the
> metalevel, but the argument is not as strong on the user-level.

I go further to see little reason to distinguish between role, class,
and type names (and what reason there is is for introspective
capabilities, not standard user-level type checking).

-- c

Larry Wall

unread,
Jul 11, 2005, 8:02:51 PM7/11/05
to perl6-l...@perl.org
On Mon, Jul 11, 2005 at 05:35:41PM -0400, Stevan Little wrote:
: So going away from philosophy 101 here, and back to CS, it could be
: said that a "Class" has-a "MetaClass" (although not in the strict
: user-level-OO sense of the word).

Yes, though I think of it more as delegation. Of course, delegation
can be construed of as pretending a reference type is a value type,
so it comes out to "has a ref to" plus syntactic sugar for redispatch.

: Am I correct in my assumptions? Because if so, then this paragraph...


:
: >So what is certainly true is that Bar.does(Class), where the Class role
: >describes the Platonic interface of items like Bar. That is to say,
: >Bar is the stand-in for all the members of its class when you don't
: >actually have a member. Its Platonic role is to know about Barness,
: >not about classness. We call call it the dispatcher class because
: >it knows how to dispatch things of type Bar whether you actually have
: >an instance of type Bar or not. That's why method calls on it can do
: >things like call constructors. But it doesn't know much about any of
: >the grubby Aristotelian workings of the metaclass. It just knows there
: >is one, and that it can delegate all the messy practicalities to it.
:
: ... makes sense to me.

Yes, I think you've got it.

: >I suspect the metaclass of "Class" actually has the name "class" or


: >"CLASS", and the metaclass of a Role is actually "role" or "ROLE".
: >Perhaps the "class" and "role" keywords are just specific examples
: >of the grammar being smart enough to treat declared metaclasses as
: >BEGIN analogues. But maybe it's smarter to keep the "class" and
: >"CLASS"
: >identifiers at arms length from each other. (If for no other reason,
: >to keep our sanity while discussing them.)
:
: Sanity? bah! it's overratted, especially when discussing meta-models :)

Well, sane or not, we'll still have to figure out whether it's better
to call it "CLASS" or "MetaClass". :-)

: >So anyway, that gives us something like:


: >
: > Bar.isa(Foo); # true
: > Bar.isa(Bar); # true
: > Bar.isa(Class) # false presuming Class is only a role
: > Bar.does(Class) # true
: > Bar.does(CLASS) # false
: > Bar.meta.isa(Foo); # false
: > Bar.meta.isa(Bar); # false
: > Bar.meta.does(Class) # false
: > Bar.meta.isa(CLASS) # false presuming CLASS is only a
: > role
: > Bar.meta.does(CLASS) # true
: >
: >You know, this class/role distinction might just be what saves our
: >collective bacon on the usual infinite regress of metaclasses, if a
: >metaclass turns out to be an object of anonymous class but named
: >role.
:
: What difference does it matter if
: $obj.meta.meta.meta.meta.meta.meta.meta.meta.meta is possible or not?
: All the stuff I have read so far seems to say that at some point in all
: object models there is a cycle. That cycle is basically where you have
: something which is an instance of itself (Object is an instance of
: Class, Class is a subclass of Object, Class is an instance of Class). I
: mean is infinite regress really a bad thing?

I don't mind looping it as long as we don't actually get caught in
infinite loops because of it. Or if we do, as long as we can blame
it on someone else. :-)

: >The bootstrap might reside entirely in the code that constructs


: >the metaclass instance of anonymous class but filling the CLASS role
: >in its abstract interface.
:
: I am ignoring the bootstrap idea for the time being in the prototype,
: as it tended to muddle all my previous metamodel attempts, and I can
: always refactor to it in the end. However, I found that the bootstrap
: is either best placed at the point of the cycle (like in CLOS) or
: spread throughout the basic classes (like Smalltalk (or at least
: Squeak) seems to be).
:
: Where that point in the Perl 6 model is, I have yet to find out, but I
: am sure it will show itself soon enough.

I ain't a meta-model expert, so I'm just trying to look out for
the sanity of all the other meta-model-non-experts. Within those
constraints, I don't care how it comes out.

: >I mentioned the idea of autogenerating a class Int from a role Int,


: >but maybe some roles don't allow themselves to be autogenerated into
: >classes, and maybe CLASS is one of them. And it sounds to me like
: >the absence of that feature is caused simply by ROLE's autogenerate
: >interface being left with an implementation of {...} and not overridden
: >in the anonymous metaclass representing the CLASS role.
: >
: >So I guess the deep answer to the infinite recursion problem is that,
: >yes, it's metaclasses all the way down, but if you actually try to
: >pursue it, you'll at some point run into "method not yet implemented"
: >because nobody has cared about it that deeply yet.
:
: I disagree with this. You hit the object-model cycle and it will never
: stop.

Shrug. I don't plan to get close to there myself...

: > So we basically


: >get the possibility of mapping to anyone's metamodel without actually
: >having to commit to the fanciest one.
:
: I am not 100% sure of this either, however, I do think the Perl 6
: object model is robust enough to be able to map to or mimic any other
: object model out there. In fact Perl 5 is robust enough to do this too
: :)

I think the place where meta-model extensibility breaks down is
if you've nailed concepts to particular names that can't then be
bifurcated. So maybe we should tell people to avoid using names for
meta classes, and always try to name them by mentioning some class
they're the metaclass of. But maybe that's overkilling the topic.
On the other hand, I'm pretty sure I *don't* want to guarantee that

Foo.meta.class =:= Bar.meta.class

for all Foo and Bar, since I think that is probably false if Foo is a
class and Bar is a role. It might even be that

Foo.meta.class.meta =:= Bar.meta.class.meta

is usefully false.

But given our syntactic mutability, it's probably okay for now to nail the
"class" and "role" keywords to metaclasses whose names match m:i/class/
and m:i/role/ respectively, however they're actually spelled.

Larry

Chromatic

unread,
Jul 19, 2005, 2:39:51 PM7/19/05
to "TSa (Thomas, perl6-l...@perl.org
On Tue, 2005-07-19 at 18:47 +0200, "TSa (Thomas Sandlaß)" wrote:

> I strongly agree. They should share the same namespace. Since
> code objects constitute types they also share this namespace.
> This means that any two lines of
>
> class Foo {...}
> role Foo {...}
> sub Foo {...}
> method Foo {...}
> subtype Foo of Any where {...}
>
> in the same scope should be a simple redefinition/redeclaration error.

I don't understand this. What does a scope have to do with a namespace?
Why does a code object constitute a type?

I can understand there being separate types, perhaps, for Method,
Submethod, MultiSub, MultiMethod, and so on, but I don't understand the
purpose of sharing a namespace between types and function names, nor of
having funcitons declare/define/denote/de-whatever types.

-- c

Reply all
Reply to author
Forward
0 new messages