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
