use Perl

• semantics vs syntax (Score:1)

  by dagolden (6584) on 2010.08.03 10:34 (#72235) Journal

  First, as a minor nit, you can declare multiple attributes at once, which is a little less repetitive.

  has [qw( this that )] => ( is  => 'ro', isa =>'Str' );

  As for "with", do you understand in what cases you need to put "with" after you declare your attributes? Even if you do, does everyone on your team (now and in the future)?

  The thing I've come to appreciate about Moose is that it expects you to know what you're doing. E.g. you compose roles after attributes when roles require those attributes.

  Using sugar to put the roles "on top" (visually) with delayed composition makes it easier for people to not think about what they're doing. In many cases, laziness is great -- there are lots of things we'd rather not think about. But roles are not subclasses. They're not mix-ins. They have different semantics.

  It seems to me like the designers of Moose have aimed to make the declarative syntax match the semantics pretty closely. Moose isn't trying to be sugary -- it's trying to be transparent. As each declaration is processed, the class evolves as per the declaration. That's a pretty good approach for keeping people out of trouble from lazy thinking about how Moose actually works.

  To be clear, I do think the idea of a thin layer of sugar on top of Moose makes a lot of sense, particularly for things like autoclean and immutability, where you have more specific goals or constraints than Moose itself.

  [As I understand it, the reason that Catalyst needs "extends" in a BEGIN block is because of the way that Catalyst uses Perl attributes on subroutines (which, despite the name, have nothing to do with Moose attributes). That's a Catalyst design choice, not a Moose one. Once the project committed to using subroutine attributes, they got all the warts that go with that.]

  -- dagolden [dagolden.com]

  Reply to This

  • Re: (Score:2)

    by Alias (5735)

    The idea of encapsulation is the very reason that we have most APIs.

    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.

    What good is
    • Re: (Score:1)

      by dagolden (6584)

      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.

      My point was that the
    • Re: (Score:1)

      by Aristotle (5147)

      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.