roles

[wchristian]

@leonerd asked for people to provide pseudocode demonstrating how people expect roles to work, here's an example to start the conversation.

use v5.38;
use experimental 'class';

role IsGreen { method color { "green" } }
role IsRed { method color { "red" } }

role DoesLogging { method log_msg($msg) { say $self->color, $self->does("DoesTiming") ? $self->timer . " $msg" : $msg } }

role DoesTiming  { method timer() { time } }

role IsWorker { apply DoesLogging, HasWorkerType; method do_work($work) { $self->log_msg( $self->type . " " . $work) } }

role HasWorkerType { field $type :param :reader; }

##############

class GreenWorkerTimed { apply IsWorker, DoesTiming, IsGreen; }

eval " # this dies
    class GreenWorker { apply IsWorker, IsGreen, IsRed; }
";

class GreenWorker { apply IsWorker, IsGreen; apply IsRed; }  # green wins

class BlueWorker { apply IsWorker, IsGreen; method color { "blue" } }  # blue wins

GreenWorker->new( type => "meep" )->do_work( "marp" );

[wchristian]

Lacking the time to add it right this moment, but it is also important that a role must be able to define something that adds an argument to the consuming class' constructor.

[wchristian]

Added the bits for apply changing the constructor of the class in response to the role having a :param field.

[esabol]

Thank you for starting the conversation. I feel roles are the missing piece that will make class on par with other Perl OOP systems.

I like Object::Pad's syntax for roles well enough. It uses :does(role_name) on the class line, which I prefer for consistency.

[wchristian]

Discussing this irl yesterday with leonerd, the question came up why it has to be roles doing this thing. Wouldn't it also work to just be able to combine existing classes to form new classes? I had no objections at the time.

[ericherman]

would we be able to just have class, and say that you can inherit or apply it as to your choice, to get whichever behaviour you want?

I think it would be fine to have just 'class' as it would be rare that it would be ambiguous or confusing to a reader looking at the code.

P.S.: thanks for the pascal blast-from-the-past! <3

[book]

So, taking @HaraldJoerg's example, would we have something like the following?

# classes inheriting from each other
class Polygon {
    field @coords :param :reader;
}
class Quadrilateral :isa(Polygon)       { ... }
class Rectangle     :isa(Quadrilateral) { ... }
class Square        :isa(Rectangle)     { ... }

# role providing some additional behaviour across classes
class Colored {
    field $border_color :param :reader = '#000000';
    field $fill_color   :param :reader = '#ffffff';
}

# class inheriting from a specific class, and consuming a role
class ColoredSquare :isa(Square) :does(Colored) { ... }

More questions:

• How would be the fact that one can't instantiate a role be written down? (do we need to write something like class Colored :abstract?)
• Is role Foo just a synonym for class Foo :abstract?
• Do :isa and :does need to be separate attributes here?
• Must a class be abstract to be a valid argument to :does?
• What if a class :isa another abstract class? Does that make it a role?

[dakkar]

Do :isa and :does need to be separate attributes here?

definitely yes, because they have different semantics (applying a role will fail if not all required methods are implemented, it will fail if you apply two roles providing the same methods… none of these fail when inheriting classes)

Must a class be abstract to be a valid argument to :does?

not really…

What if a class :isa another abstract class? Does that make it a role?

ok, this feels like something that may require distinguishing between roles and classes!

AIUI, currently (Moo(se) & similar), something like

package Role2 { use Moo::Role; with 'Role1' }
package Class { use Moo; with 'Role2' }

is almost the same as

package Role2 { use Moo::Role; }
package Class { use Moo; with 'Role1','Role2' }

but, since inheriting and applying have different results:

class Role2 :does(Role1) {}
class Class :does(Role2) {}

and

class Role2 :isa(Role1) {}
class Class :does(Role2) {}

may produce something that's very confusing…

[Grinnz]

There's several reasons why I use roles over inheritance (primarily, multiple-composition, and required methods defining the interface at composition time) but just thought of a particular reason I would use inheritance over roles: method modifiers. I'm including the bog-standard SUPER:: invocations in this: with roles it's unclear how ordering works when modifying composed methods or composing a modifier, but with single-inheritance it's rather straightforward and well-defined. (But I still use method modifiers in roles because the current implementations let me)

[HaraldJoerg]

What I'm getting at, is do we need a distinct role Thing { } separate from class Thing { }, or is the distinction of inherit vs apply good enough?

The difference might not be relevant for the user of Thing, but for its implementation. @exodist mentions required methods: If Thing requires a method, then it can not be instantiated, it needs to be applied to something which provides the method. The role keyword says "can not be instantiated" in its declaration.
This is different from abstract classes which often are base classes which are self-contained but useless. In my opinion, preventing them from being instantiated with an extra keyword abstract is not worth the effort. Why would someone want to instantiate a useless class, in particular if the fine documentation calls it useless?
If Thing can be instantiated, I'd rather use an instance as an attribute of my class instead of "applying" it.

[manwar]

@leonerd @wchristian here is my proposal for roles in core OO.
https://theweeklychallenge.org/blog/roles-in-core-oo

[manwar]

Hi @book,

I must admit, I've never used Roles in any production code as a professional developer. Therefore, if you are looking for thoughts based on years of experience in production environments, I can't provide them. However, what I know is from books, websites, and other materials; it is mostly theoretical knowledge rather than practical expertise, which I'm sure is easy for you to see from my comments.

So, back to the matter at hand, it appears that initially, I assumed this thread was discussing how we want Roles to be implemented in core Object Oriented Programming (OOP), but now it seems that we are debating why we would want to have Roles in core OOP. If my assumption is correct, and we are still having a discussion around the basic purpose for Roles, then I don't have much else to offer. Please feel free to let me know if I'm wrong about the direction of this conversation.

I’m trying out my new English language skills today, so please forgive the clumsiness of my writings. I’ve been using Perl long enough that the way I think about programming has been shaped by that language. 

For most of my programming life, I have been surrounded by programmers who use different languages that have Object-Oriented (OO) capabilities built in; I often felt bitter that Perl lacked a native OO system. 

When Moose came out, I thought it was too much for how I like to program and therefore did not get into using Moose, but I fell in love with Moo. Although my production codebase was not ready, I started using Moo in my personal CPAN modules.

As I said, now, due to @leonerd and the rest of the core developers, there is now a native OO implementation in the core of Perl. I am very excited that my favourite language supports objects natively. My theoretical education keeps reminding me that something isn't quite right yet.

Whenever I run into @leonerd, I always ask him when the OO implementation will support Roles and the answer is always the same: he needs the support of the community for more input on how to design them.

I recently followed up on the upcoming release, as I was previously and most likely going to continue attempting to discuss Roles in terms of its implementation. This time I was challenged by @leonerd to write out precisely what I would like to see in an implementation of Roles. I did not know that this conversation thread had been created at that time; therefore, I created a blog post regarding my thoughts and feelings on the topic. I am grateful to @leonerd for allowing me to express my opinion freely without having to provide my reasoning behind doing so.

Later, I was encouraged to post a link to my blog here by @esabol, which then led me joining this discussion. I am grateful that I joined this conversation.

The bottom line is that the core developers are doing a great service for the Perl community, and we all need to support them. I started my programming career learning COBOL as part of my diploma course. After that, I picked up a book on Pascal and actually learned the language without writing a single line of code! Then someone introduced me to C, and I loved it. Finally, I was given the opportunity to work with Perl. I happily made the switch and have been using it ever since. My only regret is that I wish I had stayed in touch with C, if I had, I could understand Perl internals better today and offer more direct help to the core team.

[Leont]

Can you please stop posting this slop, and actually write your own posts? No one wants to listen to what your bot has to say.

[book]

No one wants to listen to what your bot has to say.

Mediation via a bot is OK for translation purposes. No-one should be excluded from the conversation because they are not a native English speaker.

Even then, speaking in one's voice (even in slightly broken English) is preferable to having a bot adding flourish and unrelated content. Regression toward the mean is not conversation.

[leonerd]

I'm not going to put a huge amount of effort into writing a long response since I strongly suspect the original was a low-effort LLM. It follows the usual "LLM-generated from existing examples" patterns such as with "SomeClassAsAPlainString", or similar for requires. These are learned patterns from existing tools like Moo and Moose, rather than genuine necessary properties of a properly natively designed and implemented system.

I'm not interested in hearing an LLM summarise the current state of the art by recreating trained word patterns from existing articles written about existing systems. I want to hear actual thoughts from actual human programmers, about the sort of new system they would like out of a newly designed thing we create in the future. This is not something that can be generated by statistical analysis of word patterns found in existing articles on the internet.

[exodist]

I have recently been using roles a lot in my own modules, primarily with Role::Tiny, I have even added integration code that allows Object::HashBase to play nicely with Role::Tiny.

For me the big 2 things I use a lot are required methods, and Default implementations. Required methods guaranteeing an interface is available is the biggest one, and the "this thing will work in this slot" is why I use it. By default implementations I meanm instead of making a blank required method, I implement a default version of the method that should work most of the time, and the classes that consume the role get it unless they override it. This avoids needing to write the same code in many places or add a new utility class.

The Object::HashBase integration I did was mainly because I also needed attributes, not just methods (yeah the distinction is thin in perl). Object::HashBase exports constants for all the attributes you define with it, allowing $self->{+ATTR}. I needed that to work for attributes defined by my roles. I am not saying a built in perl role implementation would need this functionality, whatever perl implements I can probably make Object::HashBase do the lifting there.

I have found that I am avoiding around, after, and before like plagues. The way they wrap methods instead of composing a clear this or that makes it extremely hard to tell where logic lives, it created spooky acgtion at a distance. It also has serious consequences for realtime reloading of code, which is a problem when developing a webapp that takes longer than 30 seconds to reload.

Also a relevant note on inheritance vs roles when using an LLM, the moment you bring attributes intot he picture on perl the LLMs seem to give up using roles entirely and write base classes instead. I suspect this may have more to do with me using Object::HashBase + Role::Tiny instead of Moo/Moose. But there could be something more fundamental there, or maybe it is an artifact of perl not supporting roles as well for so long. This also is not something the perl built-in role system should consider or address, it si just a note that some may find interesting.

[karenetheridge]

To follow on the thread of required functions -- right now the Moose-style interface is just to provide a simple string, indicating the name of the desired function. I would find it more useful if we could specify a subroutine signature, using the same syntax as existing sub signatures -- then if the implementing class creates a sub with a different signature, there is an error at composition time.

(Do we have the ability at the moment to forward-declare a sub with a signature? If not that would probably need to be implemented first.)

[exodist]

I would suggest the signature be optional. I have had cases where I have had 2 roles that both require the same method, the first several args were the same, but one role accepted additonal optional args. Classes implementing one role only needed the basic args, classes implementing the second could support additional ones. Objects of either role could easily slot into places that required the first role, but items only implementing the first role could not generally go into the second role.

Basically a second role was extending the capabilities of the first by allowing additional args in its implementation of the required methods. Some code could accept just the basic role, other code could onyl accept the extended role.

Not saying this is common, and it may even be a bad idea. But I would not like us to force a signature check in all cases.

[karenetheridge]

Couldn't that just be solved by adding an extra @ to the end of the signature argument list? I do that often when implementing a method in a base class where I'm not sure if extending classes might want to pass extra args and it saves me from having to put out another release if extending classes end up doing more things than I had anticipated.

[exodist]

I admit I have not actually used the new subroutine signatures enough to know that was an option. A lot of the stuff I work in has been stuck in pre-signature land for a while. I should probably read up on the signatures before weighing in further.

[leonerd]

Ahyes. An excellent question about signatures. It's taken me a little while to get around to properly articulating my thoughts on the subject, but I ended up writing an entirely new thread about it. See #91.