All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

Eek, Perl's built-ins behave differently depending on whether or not you call them in scalar context? Yet another reason to be annoyed!;)

Seriously, it will take you about 3 seconds to get used to this behaviour of the with function and it's behaviour you want.

If you must write an alternative to the Moose API, I strongly recommend that you use Moose for a few months to get really comfortable with it and make sure you understand the design implications. Moose is great and well worth the learning curve.

Eek, roles behaviour differently depending on whether you do them separately or together?
It's that it's a gotcha that the API should never have allowed.

Actually there are very good reasons why there are two ways to compose roles.

The ideal way to compose roles is to do it all at once like Ovid showed. This takes better advantage of conflict checking because it first creates a composite role of all the roles passed to with and then applies that role to the class.

I wasn't aware that the extends needs to be in a BEGIN block unless you really do have code which needs to happen at BEGIN time. Am I wrong? (Could be).

You're not wrong. Extending the parent class needs to happen at compile time in Catalyst because as dagolden mentions elsewhere Catalyst choose once upon a time to support sub foo : Path(/) { } syntax. The nature of that syntax and how Perl goes about making it "work" requires your class hierarchy to be resolved at compile time... hence the BEGIN.

The idea that you don't NEED to know how something is implemented is always going to be better, as long as that lack of knowledge does not compromise the integrity of the systems or lead to perverted incentives.

What good is a car that requires an intimate understanding of the underlying engine and brakes and gearbox. It might be handy if you are an enthusiast of a racing car driver or pushing the limits in some other dimension.

It sounds like you're talking about encapsulation from the standpoint of users and APIs, which is different. Or, rather, it's the same but applied to Moose itself rather than what someone is designing using Moose.

Unlike users, the designers of a system must understand the dynamics of the design. That can't be safely abstracted away. Role composition is a design activity that involves satisfying certain constraints and avoiding certain conflicts in order to get the desired behaviors.

The composition order of roles is not an implementation detail of Moose; it’s a design concern of the creator of the class into which the roles get composed. To ask for it to be abstracted away is like calling maths is badly designed because 3 + 5 * 2 yields different results based on the order in which you evaluate the terms.