Reserved field names

[Ovid]

Doing a lot of research into OOP right now and I've realized we might have a potential issue I hadn't thought of before.

class Wine {
    use Wine::Classifications;
    field $class { Wine::Classifications->new( class => 'Grand Cru' ) };
    field $self  { 'Someting else' };

    method some_method () {
        # $class and $self are both invalid here
    }
}

If we inject $class and $self variables into a method, what then? The simplest solutions:

• $class an $self become classname and self keywords (but this seems to defeat the spirit of lexicals)
• Disallowing and enum of field names (do we include something like $mop/$meta?)
• Reserve field names based on a pattern (such as all upper-case, but this concerns me because we don't know if people might want instance variables to be all upper-case to make them instantly recognizable)

Also, if you're on Facebook, consider joining The Perl community. Lots of great discussion there.

[wbraswell]

I don't have any immediate feedback on this issue, following for (hopefully) more discussion.

Also, if you're on Facebook, consider joining the largest Perl Programmers group. Even more great discussion there!

[happy-barney]

• that's valid for EN keyboard, maybe some more (though restriction to 9 fingers instead of 10 imho acceptable)
• as you mentioned editor, smart editor have abbreviations, eg with emacs + yasnippet you can just press "p" + "a" + C-c + space and it can expand into __PACKAGE__
• again, this is not intended to be primary interface, only fallback

[HaraldJoerg]

• __PACKAGE__ and the other __FOO__ thingies are compile-time tokens, it would be pretty messy to use the same syntax for lexicals
• ${ ^caret } variables are in package main and will tread on each other's toes

[seav]

I may be misunderstanding things, but how would __SUB__, which already exists, be fundamentally different to hypothetical __CLASS__ and __SELF__ tokens? __SUB__ already returns different values depending on whether it is referenced inside or outside a subroutine.

[HaraldJoerg]

$class and $self get their (possibly different) values at runtime on every invocation. __SUB__ and all the other double-underscored variables always refer to the place where they are written and never change during runtime.

[happy-barney]

@HaraldJoerg to be honest, thinking you just described looks to me like leak of implementation into public interface.

I'd rather think of it more as "immutable behaviour provided by language"

[rwp0]

@Ovid Sorry but why did you use has instead of the field keyword in the code example above?
Will the has keyword be retained as an alias to field?

Doing a lot of research into OOP right now and I've realized we might have a potential issue I hadn't thought of before.

class Wine {
    use Wine::Classifications;
    has $class { Wine::Classifications->new( class => 'Grand Cru' ) };
    has $self  { 'Someting else' };

    method some_method () {
        # $class and $self are both invalid here
    }
}

If we inject $class and $self variables into a method, what then? The simplest solutions:

• $class an $self become classname and self keywords (but this seems to defeat the spirit of lexicals)
• Disallowing and enum of field names (do we include something like $mop/$meta?)
• Reserve field names based on a pattern (such as all upper-case, but this concerns me because we don't know if people might want instance variables to be all upper-case to make them instantly recognizable)

Also, if you're on Facebook, consider joining The Perl community. Lots of great discussion there.

As for the issue I think simply disallowing $class and $self as a field name would be the best.

[Ovid]

Will the has keyword be retained as an alias to field?

No, sorry. I'm writing tons of Moo/se code and it's just muscle memory. I've fixed that in the example. Thanks for catching that!

[duncand]

Having reserved field names is a noxious design smell. One needs to be able to name a field using any character string or valid generic identifier without limit. No special casing of things like $class or $self. There needs to be way of referring to special variables like $self etc that is a distinct syntax from that for fields, so that when a field $self exists, then using $self will unambiguously mean the field, as if it were an inner block declaration hiding a same named thing in an outer block, and the alternate syntax lets one still refer to the current object regardless.

[Ovid]

@haarg and @lucrocha make good points.

@duncand's comments about having disallowed names being a code smell are correct, but we have many built-in Perl variables which probably should not be field names. I don't know the internals, so I can't comment, but a quick compile time check to disallow built-in variable names (plenty of candidates in perldoc perlvar, such as @ISA, %INC, and so on), would probably be necessary. Adding $class, $field, and whatever we go with for the $meta/$mop variable (if we even go that route).

@leonerd Thoughts?

[duncand]

I suggest to tone that down a bit. One does not need to be able to name a field using any character string, and it might be annoying but it is not noxious. $self and $class are around for some time now in Object::Pad, and no injuries or casualties have been reported. Sometimes it is simply good enough to stick to an established convention.

You may have missed the part where I said or valid generic identifier.

My point is that $self and $class are well formed Perl identifiers, that we use all the time.

I'm saying it would be bad to say, you can name your class fields any well-formed Perl identifier EXCEPT self and class etc. It is bad to have to make these exceptions.

And if you want to talk about established conventions, let me be clear that the established convention is already NO RESERVED NAMES. Established convention is a blessed hash ref where we can name fields anything we want, and referencing object fields has a distinct syntax from referencing the object or class as a whole, eg $obj vs $obj->{foo}.

Its also important to point out that not reserving these names means we have room to grow in the future, say some future version of Corinna or Perl wants to introduce another special variable, and if we're relying on reserving names, we then can run into problems if someone gave their field that name.

Regular Perl had the smart design enhancement to use builtin::foo and so we can future proof the ability to add things to the core without conflicting with user-defined things. Lets follow this precedent rather than regressing. Making $self etc reserved is regressing.

[duncand]

@duncand's comments about having disallowed names being a code smell are correct, but we have many built-in Perl variables which probably should not be field names. I don't know the internals, so I can't comment, but a quick compile time check to disallow built-in variable names (plenty of candidates in perldoc perlvar, such as @ISA, %INC, and so on), would probably be necessary. Adding $class, $field, and whatever we go with for the $meta/$mop variable (if we even go that route).

A key difference here is that the named examples @ISA and %INC etc are global variables. Where everything under discussion now is, I assume, lexical.

Also those @ISA etc are legacies that still have to be supported for compatibility, but are ostensibly bad ideas in retrospect, that we wouldn't want to introduce if we were designing today with hindsight.

While Perl evolution does follow some past precedents, it also avoids continuing to follow past precedents, again see the new builtin:: decision as a key example of changing course when doing so is possible.

As a general principle of good design, there are multiple namespaces for distinct kinds of things within reason. Like package-scoped or routine-scoped variables before them, as well as the blessed-hashref way of defining object fields, the new Corinna object fields should have their own namespace and not be limited by things not in their namespace.

[rabbiveesh]

I suggest to tone that down a bit. One does not need to be able to name a field using any character string, and it might be annoying but it is not noxious. $self and $class are around for some time now in Object::Pad, and no injuries or casualties have been reported. Sometimes it is simply good enough to stick to an established convention.

I strongly agree with this. If anything, since class and self are traditional names in many languages including perl, I think it's better to lock them up. Why shouldn't we respect tradition? Reading becomes much simpler!

[duncand]

I strongly agree with this. If anything, since class and self are traditional names in many languages including perl, I think it's better to lock them up. Why shouldn't we respect tradition? Reading becomes much simpler!

How does locking names up like this make things better? What about traditions that call it this instead? Perl never locked these up before, its not a tradition to lock things up.

[duncand]

I have an updated Corinna design proposal that I would hope would make everyone happy.

1. There are no newly introduced reserved/forbidden names, no reservation of self etc, the only things that are not allowed are those already not allowed in 5.36 Perl. Users can name fields or parameters or lexicals anything that they could under 5.36 but that in the case of fields now restricted to what is a well-formed Perl identifier in the same way any regular $foo are.

2. In the general case, users always explicitly declare the lexical $foo that they want to refer to the current object or class with, they explicitly declare to name it either $self or anything else they choose. This is exactly the same as how Perl 5.36 gives them the full freedom to name the innocent object whatever they want, because they have declared it either as the first parameter in a routine signature, or because they declared it with my $self on assigning from @_. So we don't take away their freedom to name this what they want. However, the exact syntax for declaration would change, and I propose doing so as either an enhancement to the signature syntax, or as a new "attribute" on the method, such as method quotient :self $dividend ($divisor) { ... }. I'm not picky on the exact syntax, don't get hung up with my example.

3. All method lexicals have a more-inner-scope than fields, so declaring a parameter or lexical or invocant $foo will hide a field $foo in that method. So users have to use different names if they want all to be visible at once, but the have the choice of what each is named, or they do without accessing the field as a private variable in that method, or they use the field's accessor method as a workaround if they want.

4. Explicitly declaring the name of the invocant can be optional per method, if we want the brevity, and if users don't do it, then a default innocent name of $self or $class is used. Likewise per point 3 this would hide a same-named field if there is one; they can avoid the hiding by picking a different name. I'm also fine with making it mandatory for users to declare the local name of the innocent, in fact I would prefer making it mandatory, so everything is explicit, and also it possibly simplifies the Perl parser as it doesn't have to deal with more $foo that appear implicitly, everything is explicitly declared.

I want to emphasize that the precedent here is what you can do with blessed hashes, full user control over what the invocant and the fields are named. Having reserved $self is NOT the precedent, it is just a popular convention that people often CHOOSE to use.

I also consider it good design in many cases to give the invocant a more descriptive name, as I illustrated with my code example above representing a numeric division method, and since the invocant is logically a parameter, users should be able to name it too based on context. Not allowing naming of the invocant is like forcing all the parameters to be named eg $param1, $param2 etc which is bad.

Thank you for your consideration.

[happy-barney]

just one though more ... when user declares field $self it is very likely (I'd say machine epsilon close to 100%) that given syntax will be necessary to use in every method, so maybe it will not be bad idea to put this attribute at class

class :self $different {
   has $self ...;
}

[duncand]

just one though more ... when user declares field $self it is very likely (I'd say machine epsilon close to 100%) that given syntax will be necessary to use in every method, so maybe it will not be bad idea to put this attribute at class

class :self $different {
   has $self ...;
}

@happy-barney I like your suggestion, a lot, and its something I hadn't thought of. And it also takes advantage of the "attribute" based syntax I suggested in that it can be declared on methods OR classes, versus the signature extending version which doesn't really translate to being declared at the class level. But this should be an extension, and one should be able to override on a per-method basis what they declare at the class level, when a more descriptive name is good specific in that context. Also, if they can declare it once for the whole class in this way, that's more weight on just making it mandatory to declare the name explicitly, so there is no implicit name injected. Thank you!

Also, something else I just came here to say is that, alternately, rather than the more-inner lexical scope hiding the more-outer field scope, THIS could be made an error if the same name is used, similar to those wanting to reserve self making a conflict an error, except users have the choice of names and can avert that error by renaming the field OR the invocant.

[happy-barney]

well, have to say, I don't think in terms of "scope" (which implies code workflow for me) but rather in terms of "context".
personally I prefer to introduce := operator I described in https://www.nntp.perl.org/group/perl.perl5.porters/2021/06/msg260416.html

that will make grammar much more structured

[abraxxa]

I like the suggestion too but please think about tool support too, for example text editors/IDEs.
Will the Perl languageserver be able to add support for it easily? Same for Perl::Critic rules.

[happy-barney]

every new feature needs additional support in tooling

[thoughtstream]

I just came across this discussion, and thought I would add my mite. Late as it may be.

Naming a field $self or $class is one of those "Doctor it hurts when I do that" behaviours.
Of course, Perl has always been very liberal in handing out rope to hang oneself, and we should probably
honour that tradition in Corinna as well. But Perl has also become very good at warning people
when they're doing something that might bite them in the ascertainable future...and we should
certainly foster that trend too.

So I'd suggest that when someone declares field $self or field $class, they should get
a compile-time warning:

field $self will not be directly accessible in object methods of this class
(do you need to declare it with a :reader or :writer attribute?)

field $class will not be directly accessible in common methods of this class
(do you need to declare it with a :reader or :writer attribute?)

Then, if they don't want those warnings, they can either rename to fields to something less bloody-minded,
or they can prefix the declaration with something like: no warnings 'bud_muh_freedum!';

As for future-proofing the addition of further automatic variables, I honestly don't see that
as a likely need. But then...that's exactly why we need to consider the possibility, isn't it? :-)

The chance of a future auto-variable conflicting with existing fields or variables would be greatly diminished
if all Corinna auto-variables (including the current $self and $class) were SHOUTY, rather than whispery.
Just like @ARGV, @F, %ENV, %INC, $ARGV, $AUTOLOAD, and virtually all the other existing
auto-variables already are...except for $a and $b (which were a mistake that causes endless trouble both for beginners,
and for the nominatively lazy...though in the latter case I admit that I consider that a handy form of Instant Cosmic Justice. ;-)

To be clear, I'm suggesting that $self and $class would be better as $SELF and $CLASS respectively.
And that any other OO-related autovariables Corinna might subsequently add should likewise be UPPERCASED.
That way, these magically delicious variables would stand out in existing code, and people would also be much less
likely to accidentally create other variable names that might eventually conflict with future auto-variables
(having already been trained in non-OO Perl to avoid naming their variables $LOUDLY).

[duncand]

I'm good with Damian's suggestion of using $SELF and $CLASS for the auto-injected variables, as being an improvement over the lowercased versions. However, while this would lower the chance of conflict, we must still have zero reserved names, and hence naming fields $SELF or $CLASS must be allowed, and if that happens, there is still the warnings about because you did that the fields can only be referenced via the reader/writer methods and not in $foo syntax.