Re: Pre-PPC: class :abstract

As a first step abstract classes sound good as you describe them. :)

On 17/12/2025 15:38, Paul "LeoNerd" Evans wrote:
> It also
> avoids the overall problem of "roles" being far too ill-defined and I
> still have no idea what people want there. (*AHEM*)

After having had more time to think about these things and more newbies 
to teach them to, i think the purpose of roles is primarily this:

Avoid the "magic" of multiple inheritance.

The goal is to share code (methods, attributes) between different 
classes so it doesn't have to be copy-pasted.

With multiple inheritance you create a structure of things that you have 
little direct control over and are resolved whenever a method is called, 
and you have to hope the resolution works as you intended, or may even 
need to change the way the resolution is done, which means now you have 
to remember two resolution rule sets.

With roles, there's two way of composing things, which is to merge with 
conflict warnings (by way of calling with() with multiple roles), or to 
let one role override another role (by calling with() on the favored 
role first), and the control happens very organically and is easy to 
understand and even comes with error messages that trigger at class 
compilation time, rather than at method call time.

Roles also lend themselves very naturally to nice file and directory 
structures, even when code is shared between wildly different types of 
classes. In the following example structure every module with a verb 
name is a role, and every module with a noun name is a class.

MyProject/
   IsEntity.pm
   HasCreatedAt.pm
   DoesLogProcessTitle.pm
   Process.pm ( DoesLogProcessTitle )
   Entity/
     IsProduct.pm
     Customer.pm ( IsEntity, HasCreatedAt, DoesLogProcessTitle )
     Database.pm ( IsEntity, HasCreatedAt )
     Product/
       HasEmailConfig.pm
       Dakota.pm    ( IsEntity, HasCreatedAt, IsProduct, HasEmailConfig )
       SSL.pm       ( IsEntity, HasCreatedAt, IsProduct )
       ManagedWp.pm ( IsEntity, HasCreatedAt, IsProduct, HasEmailConfig )
   IoAsync/
     Watcher.pm ( DoesLogProcessTitle )

I may be overlooking something obvious here, but i feel trying to 
implement this kind of sharing with extends() would be quite painful.

So for me personally, this kind of composability is what i want.

One could say "you could just put things into a module and import those. 
However that would afaik not result in the class system being able to 
actually compose attributes and method modifiers, nor do meta 
introspection on the resulting class.

-- 
With regards,
Christian Walde