Class Data and Method Feedback

[Ovid]

This ticket is for feedback on Class Data and Methods.

[tm604]

As raised in IRC #cor:

The partial-shared nature of https://github.com/Ovid/Cor/wiki/Class-Data-and-Methods#roles is really not obvious: shared suddenly changes meaning from a singleton to a separate state per class. The same behaviour doesn't seem to apply to shared within class inheritance.

• is there precedent for this anywhere in existing Perl OO modules?
• how would you implement class-style shared semantics in a role? e.g. globally-unique ID role: role GlobalID { class_style_shared $unique_id = 0; method next_id { ++$unique_id } }
• given this difference in meaning... why not just keep this behaviour as part of shared, i.e. unique variable per class, and stick with my for the global nature of class-shared?

There's also the unfortunate class Example { shared $var : shared; ... } cognitive overload... it's becoming the Perl equivalent of C++'s static!

[duncand]

Shared does not actually change meaning in a singleton. A singleton is merely a class with zero instance slots/members, and all state information is class level. In such a case, a method and a shared method are functionally equivalent but that's just because its a trivial case.

[kapitaali]

Hi, thanks for the module. My background is in Java where these things are very explicit and done by the book, so I don't know if this is the right place to submit a comment but what I would appreciate is for a comparative beginner cheat sheet of basic syntax of declaring a class, its methods and attributes side by side in Java and in Perl.

Of course reading the docs are key and important, but if I just want to do a quick class implementation, like one of those cash register examples, or some geometry with classes like the coordinate system (or a plane) and a point (has x, y etc.), just by looking at the syntax to grasp it quickly what it does would make it a lot easier for me to jump right in.

[damil]

A class variable is shared between all instances, so indeed the word "common" could be quite appropriate -- despite the fact that the class variable also exists when there are no instances. But I find the word "common" totally inappropriate for class methods : when invoking a class method, it has no access to the instances and therefore there is nothing "in common". Moreover, regular instance methods could also be considered "common" because since we are not in a prototype-based language, all instances share the same implementation for an instance method.

My preferred solution would be class method, but I'm aware of the technical objections to that. So a simple workaround would be to introduce the new keyword class_method (with underscore).

If this is accepted, what to do with class variables ? Well, one possibility would be to stay with common, with the inconvenient that there is no linguistic similarity between class variables and class methods. Otherwise, we could apply the same trick and introduce the keyword class_has for class variables, i.e class_has $foo = 123. Here we gain similarity between class variables and class methods, and also similarity between class variables and instance variables.

[leonerd]

@damil Can roles then provide "common" methods/slots? If so, are they written class_has ... or role_has ...?

[damil]

Well, the doc says :

Note that common data and methods are attached to classes, not roles.

See the example role "DoesSomething". https://github.com/Ovid/Cor/wiki/Class-Data-and-Methods#roles

So this would work exactly the same if we write class_has or class_method instead of common. By contrast, role_has is out of the question because a role cannot be invoked on its own, only when attached to a class.

[duncand]

A class variable is shared between all instances, so indeed the word "common" could be quite appropriate -- despite the fact that the class variable also exists when there are no instances. But I find the word "common" totally inappropriate for class methods : when invoking a class method, it has no access to the instances and therefore there is nothing "in common". Moreover, regular instance methods could also be considered "common" because since we are not in a prototype-based language, all instances share the same implementation for an instance method.

I read this as you have a problem with the concept of using the term "common" with an empty set. I see "common" as being the same as "all", it completely makes sense even when there are no instances yet. The methods are in common to all instances, and that still works when there are none.

I see the proposed alternative of "class_foo" as worse than the "common" proposal.

[Ovid]

The Corinna MMVP (minimally minimal viable product) has been accepted by the PSC and work will begin after the v5.36 release. Thus, I'm closing this for now.