On the whole, I prefer syntax that is minimal and consistent to the problem domain it describes, rather than consistent to other neighboring syntax.
]]>Why not just use 'common' in that case?
If we have 'common $foo;' for class data that fits with 'common method foo' for class methods, in the same way that 'my $foo' and 'my sub foo' exist for lexical declarations currently.
My point that overloading 'slot' seems to me to be *less* clear than using 'my' would indeed be obviated by having a separate keyword that was actually clear.
Similarly, I wondered on IRC if we should have 'modify foo :before' rather than 'method foo :before' and got pushback from ovid because that would mean "we add five new keywords instead of four" which I found equally unconvincing.
(ovid did later mention 'modify method foo :before' which if anything expresses the author's intentions even better, but unless I misunderstood he didn't seem to feel that obviated the 5 vs. 4 argument, sadly)
>> ...since declarations of 'my' and 'state' variables within class blocks seem like they should do what the author means anyway,...
> But, once again, that’s the argument for just using package and sub for classes and methods: that they do what the author means anyway.
I think I was insufficiently clear there, *that* wasn't the argument I was trying to make - the argument I was trying to make was that 'my' should work no matter what we decide about class data (which, to my mind, strongly suggests -not- begin lifting fragments of the class block and instead having things work linearly - a bunch of IRC based pushback has been significantly over working around the fact that -bits- being begin lifted cause confusion by forcibly begin lifting -more- bits seems like going in the wrong direction)
No matter how we resolve this though, given that our experience does at least intersect at the first part of
> those usages have not been particularly frequent, but class data has been invaluable on the particular occasions I did need it
I still think that waiting a bit *might* be better than shoving it into version 1, though that's perhaps as much 'fear of backcompat traps' as anything else and it could certainly be argued I'm being overly paranoid.
Though as another possibility, given it's an infrequently used feature, one might even suggest that "making it possible to add a 'common' keyword" would be an excellent test of an extension system. Both Moo and Moose have extensions that provide a class_has keyword, and even if I prefer to avoid using them, I'm very much in favour of it being possible for them to exist.
Either way though, 'slot :common' seems like the worst possible option to me because of it making the 'slot' keyword doubly special, and I think 'common $foo' honestly sounds pretty good.
tl;dr - I think the only point where we meaningfully disagree about 'common $foo' (or an alternative named keyword) is whether it's *definitely* a good idea to have such a thing in core in the first version.
]]>our $var :inherit;
]]>
To be clear, that has never been the argument.
The argument has *always* been that 'my' variables could be used for many of the purposes of class data and that that means that the decision as to whether to add a specific class data feature in the first version would have less of a cost.
>> trying to avoid finding we've painted ourselves into a corner
Ovid bolded this comment of mine for a related reason, but the whole point is that the -relatively- low cost of not formalising class data -yet- may mean it's worth not doing so immediately until we see usage patterns in the wild, precisely to -avoid- the inevitable risk of corner pointing that's inherent to codifying any particular feature for the first version.
]]>Sorry, I completely forgot to comment on your explanation of perceived differences, largely because your position on that now makes complete sense so I didn't really have much to add.
It does strike me that if we're talking about 'common $var' (even if under another name) being visible through the MOP for testing and debugging and general escape hatch purposes, then yes, that makes the case for it being its own thing much stronger.
I was under the possibly mistaken impression that there wasn't consensus for making private-ish things visible through the MOP at all so hadn't factored that possibility in.
]]>mst: the more I think about it, the more 'modify method foo :before' and 'common $foo' do go with 'common method foo' actually seem pretty ok to me
mst: just let's un-begin-lift everything for consistency while we're there so only 'slot' needs a weird initialisation order
LeoNerd: I'm still finding I like the braces in Object::Pad's has $slot { init-expr here };
mst: yeah, so do I, but I also feel like people are going to -want- to type '=' and it may be worth letting them ergonomics-wise
mst: maybe that's the wrong choice
mst: going for a block so it looks like the separate thing that it actually is definitely has advantages
So something like:
class Foo :isa(Something) {
my $internal = 0;
common $state; # MOP-visible but otherwise private
slot $data :accessor { 0 }; # instance variable
common method foo (...) { ... } # class method
method bar (...) { ... } # instance method
# modifier applied to superclass method
modify method baz :before (...) { ... }
}
seems like it maximises intentionality.
(I continue to like Ovid's choice of 'common' to indicate class data/methods are accessible to instances as well as straight-up class calls)
Assuming we accept that there's no reason to beginlift 'method' in this style then - other than the fact that role composition will have to happen at the end of the block (which was always stevan's dream anyway) - the ordering of everything is extremely clear.
I especially like that this way '=' always means what you expect it to mean, happens exactly when the variable's initialisation statement is hit, and then the block for 'slot' gives a nice hint it *specifically* will get initialized differently.
Curious what people think.
]]>It also seems to me that the existance (and IMO elegance) of'my sub' is a good argument for 'common method' at the very least. "Scoping a thing" and "the thing" seem like they should be allowed to be considered separate syntax.
]]>I concede that my sub is at this point a well established prior art for prefix declaration modifiers (even though I still think it was a misstep for Perl, syntactically).
Therefore I also concede that common $foo and common method foo would be an acceptable (albeit non-KIM) compromise, and would give us everything we need in Corrina v1, even if we can’t yet agree on the issue of BEGIN-hoisting.
BTW, I’d be even happier with that decision if the slot keyword had been named field instead. Because “field” is another frequently used nomenclature for an instance data variable, and even has history in Perl usage in the form of the use fields pragma. But, far more irresistably, because the agricultural analogy between a “field” (i.e. an individual’s personal allotment of property, reserved for their own use) and a “common” (i.e. a village’s communal allotment of property, whose use is shared by all) is...utterly perfect. ;-)
As for the modifier method foo :before vs method foo :before syntaxes: there I’m far less convinced. But I suspect that, in part, that’s because I am far less convinced that Corinna v1 needs this construct at all. I’d argue that this feature, rather than class data, is actually the one that is “...worth not doing immediately until we see usage patterns in the wild”.
But, if the wider consensus is that we do need method wrappers in Corinna v1, then the keywords for that construct definitely need better names. I’d suggest either the KIM syntax:
method foo :wrap(before) () {...} method foo :wrap(after) () {...} method foo :wrap(around) () {...}...or, if we are indeed giving in to the insidious creep of the <modifier> <keyword> syntax, then:
wrap method foo :before () {...} wrap method foo :after () {...} wrap method foo :around () {...}
Note that I still think these particular features could be deferred but, if they have to go in now, then they ought at least go in eloquently.
before method foo …
etc style code, method
is no longer a keyword, but part of the identifier or ‘place’, analogous to setf
in lisps.
If you’re going to redo before/after/around, then I have a sneaking regard for lisp style named advice, so
before method foo () { … }
could become:
wrapper massage_args :around (…) {…}
wrap method foo :with(massage_args);
Also, if we’re borrowing from Lisp, then before/after/around could (should?) be joined by before-while
(if the advice returns false, don’t call the advised function), before-until
(only call the advised function if the advice returns false), override
(simply replace the advised function), filter-args
and filter-return
(massage the arguments or return value).
Yes, all of these extra modifier types can be implemented in terms of around, but I’d suggest that being able to more finely define up front what a piece of advice is going to do will help make things slightly easier to reason about.
]]>Maybe it was, but we want to achieve something that's both good -and- going to feel natural to existing developers. This does not at all mean I'm not overall in the wrong by using it as a precedent, mind.
(raku's making the sub keyword fully lexical is still something I look upon with envy, and I hope if I call you spoiled in that regard it will be taken in that spirit ;)
> even if we can’t yet agree on the issue of BEGIN-hoisting.
It occurs to me that I've failed to explicitly say something I consider important:
I don't actually entirely object to the idea of beginlifting, what bothers me is doing so for *parts* of the 'class' block so you have to remember which keywords are beginlifted and which aren't.
While I am not fully convinced that it's a good idea, beginlifting the *entire* 'class Foo { ... }' construct would avoid all of my inconsistency complaints and I suspect also achieve most (all? answers on a postcard) of the desired goals. I could happily live with named classes being beginlifted - I just don't think that 'some parts of a class block are beginlifted, please memorise which' is particularly a service to our users. Either do it for the whole thing or don't do it at all, please, is basically where I'm at here.
> BTW, I’d be even happier with that decision if the slot keyword had been named field instead
I have never at all liked 'slot' as a keyword and while I'm quite comfortable with our theft-from-raku of 'has' in most current code, I actually really rather like 'field' as an alternative since it feels much more in keeping with 'common' linguistically even before we get to the (admittedly glorious) analogy. To the point where, much though I love 'has', I'm not sure if 'field' plus 'common' isn't actually strictly better than 'has'.
> But, if the wider consensus is that we do need method wrappers in Corinna v1
I fear the discussion around this has become unfortunately confused.
The initial argument was people saying "method modifiers are useful and important to us" versus Ovid saying "a method composed in from a role should not be allowed to access the existing method of a superclass at all" ... and these two extreme positions set the terms for the debate. Initially people argued for having some way to achieve that goal, were told that there wouldn't be any way at all to achieve that goal because it was bad and wrong to ever want to, and the result was a design that provided no such way followed by sufficient pushback that the maximalist approach to achieving said goal got added to the design instead, perhaps unwisely.
I believe that the majority of people involved simply want *some* way for a method composed in from a role to decorate/advise the method of the same name from the superclass, and that while raku grade redispatching might be rather nice, simply permitting '$self->next::method' to work in role provided methods would likely be quite sufficient.
In fact, it strikes me that assuming that *is* permitted, both before and around methods become trivial and the one annoying case that is the after modifier - i.e. running code after the call to the 'real' method while maintaining context for its return value - is already solved by LeoNerd's defer implementation and so can be handled by the perl RFC process without needing to directly impact the design of Corinna itself.
So, personally, provided roles aren't explicitly forbidden from providing modifier-like functionality, I would be entire comfortable with descoping modifier-like *sugar* from v1.
]]>That was unclear. 'existing/inherited method of the same name' would have been more clear.
Ovid and I have both suffered from the whole "having more passion than social skills" failure mode over the course of this process and clarity about the technical points is important; as such, I apologise to anybody who read that sentence the way I didn't mean and didn't realise was readable thereinto until after I'd already hit Submit.
]]>Why you all think ignoring 10+years of prior art and existing examples on CPAN and in the wild is a brilliant idea?
https://github.com/Ovid/Cor/blob/master/rfc/overview.md#24-rationale
]]>