Re: OK, ::?CLASS not virtual
HaloO,
John M. Dlugosz wrote:
Larry Wall larry-at-wall.org |Perl 6| wrote:
I don't like using ::?CLASS for something that is not a compile-time
constant. ... we don't use ::?SELF anymore, but self, because that
can vary in
meaning dynamically
OK, for some meaning of constant. After all ::?LINE is different
every time you call it. I see it as the compiler automatically defining
it properly for each use, not so much what its return value had to be,
that made it special. But to try and put your meaning more precisely
(my specialty), I think it expands at compile time into a literal. That
is, you don't want it to expand into another symbol that itself changes
or is an accessor.
Ups, I thought that a ? variable is a variable of the running compiler.
In my concept of how virtual classes are implemented it is indeed the
case that the compiler is at work when a class name is needed. That is
the runtime system traps calls to generic functions and invokes the
compiler on the fly when a new instanciation of the template is
needed. This might be a simpler run that just creates a new entry point
to prelude that re-links the namespace.
Now you have the same problem with using ::?CLASS inside a role. Rather
than saying well, we'll defer that, this time don't use it in a role.
Also runtime role mixin by means of the does operator conceptually
invokes the compiler. The only difference to role composition at
pure compilation is that the does operator makes consecutive calls
to fresh compiler runs instead of an unordered global composition of
multiple roles in a single compiler run.
I propose the symbol CLASS as follows. It is inherited like BUILD and
other all-cap things from Object. It is defined as a type alias. It is
overridden in every class to refer to the current ::?CLASS at that
time. The implementation can treat it as just another virtual type name
that is inherited.
This very much sounds like HOW, except that it's not a pseudo method.
That is it needs no invocant. Isn't it so that the lexical class is
available as OUR, anyway?
I have problems to see how you inherit a type name. To me type names are
looked-up from the hierachical namespace. The idea in Simons' Theory of
Classification is to expand inherited methods again in the context of
the inheriting class.
class Base
{
method m (CLASS -- CLASS) { my CLASS $c; ...} # CLASS = Base
}
class Derived is Base
{
# m re-expanded here with CLASS = Derived
}
The namespace ends up to contain Base::m *and* Derived::m with the
signatures :(Base: Base -- Base) and :(Derived: Derived -- Derived)
which are of course not subtypes of each other because
Base.does(Derived) is false. But, as you point out, this is not a
problem if one stays generic.
sub foo (Base ::T $b)
{
my T $t = $b.m(T.new); # type correct
...# $b.m($b.new) works the same
}
Note that the body of Base::m could be shared, but Derived::m might
be a different entry point that binds virtual names differently.
An interesting question is if BEGIN, CHECK and INIT blocks of m should
run once in every scope.
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Simplicity does not precede complexity, but follows it. -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: OK, ::?CLASS not virtual
Jon Lang dataweaver-at-gmail.com |Perl 6| wrote: John M. Dlugosz wrote: And you can use CLASS in a role also, confidant that it will be looked up according to the normal rules when the class is composed using that role, just like any other symbol that is not found when the role is defined. Using ::?CLASS in a role is an error (unless you mean the class surrounding this role's definition, in which case it is a warning). Can a role inherit from a class? If so, to which class does CLASS refer: the inherited one, or the one into which the role is composed? If you have an is Base item in a role, that will apply the inheritance to the composited class when it is used. Whether the role itself inherits depends on how you think about it. In all cases, CLASS will refer to a virtual symbol that becomes the most-derived (complete) class at run time. In an object, CLASS refers to the final dynamic type. It is virtual. For my treatment of the subject, see my spec doc at http://www.dlugosz.com/Perl6/, section 12.5.1 Class names used in methods. I'd be happy to talk more about it in-depth. Also check the mailing list for the discussion Class names are virtual starting on the 20th: Larry, you've wanted to have class names used within a class be virtual. With various degrees of conviction across the synopses, you've wanted classes defined within a class to be overridable, or all classes referenced by a class to be overridable, speculating on whether this is do-able. ... You'll be happy to know that not only is it do-able (once you know what is and is not affected), but it will play a role in making the type system F-bounds quantified. --John
OK, ::?CLASS not virtual
Larry Wall larry-at-wall.org |Perl 6| wrote: I don't like using ::?CLASS for something that is not a compile-time constant. ... we don't use ::?SELF anymore, but self, because that can vary in meaning dynamically OK, for some meaning of constant. After all ::?LINE is different every time you call it. I see it as the compiler automatically defining it properly for each use, not so much what its return value had to be, that made it special. But to try and put your meaning more precisely (my specialty), I think it expands at compile time into a literal. That is, you don't want it to expand into another symbol that itself changes or is an accessor. Now you have the same problem with using ::?CLASS inside a role. Rather than saying well, we'll defer that, this time don't use it in a role. I propose the symbol CLASS as follows. It is inherited like BUILD and other all-cap things from Object. It is defined as a type alias. It is overridden in every class to refer to the current ::?CLASS at that time. The implementation can treat it as just another virtual type name that is inherited. It fits with other all-cap things -- stuff from Object that is sometimes customized for each class. It follows the general idea that non-global non-qualified type names are virtual. It is only reserved in context, so it won't get in the way of non-class code that dares to use an all-cap name. And you can use CLASS in a role also, confidant that it will be looked up according to the normal rules when the class is composed using that role, just like any other symbol that is not found when the role is defined. Using ::?CLASS in a role is an error (unless you mean the class surrounding this role's definition, in which case it is a warning). --John
Re: OK, ::?CLASS not virtual
John M. Dlugosz wrote: And you can use CLASS in a role also, confidant that it will be looked up according to the normal rules when the class is composed using that role, just like any other symbol that is not found when the role is defined. Using ::?CLASS in a role is an error (unless you mean the class surrounding this role's definition, in which case it is a warning). Can a role inherit from a class? If so, to which class does CLASS refer: the inherited one, or the one into which the role is composed? -- Jonathan Dataweaver Lang
