Consider the non-inheritance relationship, where one object delegates to another. You can't get the right answer about a type question by asking "Does the delegator inherit from the delegatee?", and you know that if you limit all of your questions about object behavior to "Does this object have a method of this name?" then you run into the false cognate problem (a tree has bark while a dog can bark; a student can bomb a test while a fighter jet can bomb a test target).
What you need is a way of asking "What named collection of behaviors does this entity provide?" without running into the false cognate problem and without dictating the nature of relationship between the entity in question and whatever you think provides that named collection of behaviors.
By consuming a role, you promise that the consumer provides the named behavior defined by that role. Consuming a role often flattens one or more methods into the consumer, but if the consumer already provides those methods, the flattening doesn't have to happen.
Roles give you a way of grouping collections of attributes and behavior under names as well as a default mechanism to provide that collection of behavior in whole or in part to a consumer. That's it.
]]>Breaking XS would be awful, but it's probably necessary for the kinds of internal changes that produce either dramatic speed gains or allow further experiments on the CPAN. Unfortunately, it breaks most of the CPAN.
Changing the method invocation operator from an arrow to a dot doesn't fall into that category.
]]>What is the real problem they want to solve? Does this suggestion address that problem?
]]>I'm not sure names are the problem.
]]>The argument that Perl's Osborned itself holds more water with me, but that only leads to the debate over whether Perl 6 will only take a few more years to get useful or always take a few more years to get useful.
]]>With that said, moving the reference count out of the SV header could give memory improvements in shared memory situations such as a preforking server.
]]>Also if you've failed to be as precise as humanly possible about describing every potential exception to your opinion (no matter how unlikely), I get to lord it over you for being sloppy and inexperienced.
Once you realize that's how so many technical discussions work on the Internet, you can win Nerdfight Bingo more often than not.
]]>Note that people such as Larry and Tim Bunce are very good at solving problems without making other people feel small.
]]>