use Perl

• Why...? (Score:1)

  by lbr (5199) on 2009.06.03 10:54 (#68922)

  ...did you call it 'some_method'. has is not sub. It's a nice red herring though, throwing me off completely till I saw rjbs's answer. If it'd been called "some_field", it'd been obvious.

  rjbs has explained what went wrong, but I'm curious why you'd expect it to behave differently. The behaviour is exactly as documented in Moose's section on is => 'rw'|'ro'.

  Reply to This

  • Re: (Score:2)

    by Ovid (2709)

    Sorry about that. I just hastily threw together an example. But what's the value of allowing me to declare an attribute without an accessor or mutator? I'm sure there's a reason. I just don't see it.
    • Re: (Score:1)

      by phaylon (6115)

      The slot is still accessible via the MOP, which means other accessor-like methods can access it. For example, with MooseX-AttributeHelpers you could have an ArrayRef container providing push and pop methods without providing an API to directly set the array reference value.

      --
      Ordinary morality is for ordinary people. -- Aleister Crowley
      • Re: (Score:1)

        by Aristotle (5147)

        It would be nice to have to explicitly request that, though? Instead of it being the silent default. Or else there might be has_ro and has_rw keywords that one could use for the bulk of one’s declarations, in which case it’d be immediately obvious when something uncommon is going on.
        • Re: (Score:1)

          by jjn1056 (1241)

          You could do this with an attribute trait, but putting "is=>'ro'" is not particularly onerous and it reinforces the idea that an attribute is not just a fancy getter/setter sugar code, but is fundementally more powerful. At this point I doubt this is going to change in Moose, although MooseX::Declare might be open to new ideas (not sure what the authors of that have in mind over the long term.).

          --
          Waiting on the Road to Eventually, I lost my Place On Line
          • Re: (Score:1)

            by Stevan (6065)

            At this point I doubt this is going to change in Moose, although MooseX::Declare might be open to new ideas.

            MooseX::Declare is part of the overall Moose project, it will almost certainly not deviate too far from what Moose does on key issues like this. However which might be nice is to add support for the Perl-6 style of doing this, like so:

            class Foo is rw {
               has bar;
               has baz;
            }

            Here all of Foos attributes will be (is => rw) automagically. I think the key issue here is that Moose will not and should not do anything you don't ask it to do. DWIMery is very VERY slippery slope, too much o
            • Re: (Score:2)

              by Ovid (2709)

              My only suggestion is that the default be (is => 'ro') for reasons that I think are probably obvious to you. That being said, I accept an 'rw' default as most OO programmers are going to expect that an not agree that 'ro' is so important.
              • Re: (Score:1)

                by perigrin (3495)

                class Foo is ro {
                      has bar;
                      has baz;
                }

                # or in Plain Moose

                {
                package Foo;
                use Moose -traits => ['ReadOnly'];
                use namespace::autoclean;

                has bar;
                has baz;

                __PACKAGE__->meta->make_immutable;
                }
    • Re: (Score:1)

      by Yanick (3196)

      There are a few reasons I can imagine, and several I'm fairly sure I'm too afraid to consider. :-)

      One reason would be because one wants to explicitly set the 'reader' and the 'writer'.

      has babelfish => (
          writer => 'schrieb_fish',
          reader => 'lit_fish',
      );

      But that doesn't explain why there is no warning if there is no reader/writer assigned at all. But that could happen because one want to create those sometime during runtime. Wacky, but I can imagine a few motivations to
      • Re: (Score:1)

        by perigrin (3495)

        role Pet::Sounds {
            method make_noise { say $self->noise }
        }
        
        class MyHouse {
            has pet => (
                does => 'Pet::Sounds',
                required => 1,
                handles =>  'Pet::Sounds',
            );
        }
        MyHouse->new(pet => Beetle->new())->make_noise; # I want pet provided on creation but never accessed directly after that.
      • Re: (Score:1)

        by Stevan (6065)

        The answer to "why" is simply "because you didn't ask for it". DWIMery is good up until it gets in your way, then it's annoying and difficult to work around. Here is another example (along with perigrin's excellent one) on why you might not want an accessor.

        has foo => ( trigger => sub { my ($self, $value) = @_; $self->bar( $value + 2 ) } );
        has bar => ( is => 'rw', ... );

        Here the side-effectual trigger is used to set the value of bar. Sure, seems kind of esoteric, but it is a valid use