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
