http://qs1969.pair.com?node_id=769584


in reply to Re: Language features affect style
in thread Language features affect style

Indeed, which is why we've gotten rid of most of Perl 5's (not so) beloved boilerplate in Perl 6. Here's the same code (more or less) in Perl 6:
class Foo { has $!salary; method !private_method ($factor = 2) { $!salary *= $factor } method salary { self!private_method(10); $!salary } } my Foo $foo .= new(:salary(100)); say "salary is ", $foo.salary;
This may or may not tweak the refactoring knob back toward methods; Perl 6 is still not Java, after all.

Replies are listed 'Best First'.
Re^3: Language features affect style
by John M. Dlugosz (Monsignor) on Jun 09, 2009 at 19:13 UTC
    method salary { self!private_method(10); $!salary }
    Doesn't $!salary have to be called with an object? self!salary. Or has this been changed to figure that out for itself (implies self or $_ ?) now? I found it:
    For a call on your own private method, you may also use the attribute-ish form:
    $!think($pinky) # short for $(self!think($pinky))
    I'm guessing you put this in after you got STD in fine enough shape and knew that could actually be made to work?

    With analogous meaning for the other sigils (that's not stated in S12)?

    —John

      Huh? $!salary is simply the name of the private storage area for the attribute. No calling involved, since the method already knows its own self, and whole point of $!salary is to tell the method it can access the storage directly rather than through a virtual method. The extra information is only necessary when calling something private in another object.
        I thought it's always a private accessor. The MOP knows how to really get at that slot, though this may be inlined and optimized down, it's logically an accessor submethod. $!salary will do something different in a P6opaque than in a P5hash or a dotNetImport etc.

        So how does the compiler communicate with the meta-object protocol to ask "how do I generate code to access this slot?" if it's not a function provided by the MOP?

        Given the normal public access semantics, "$.foo, @.foo, %.foo, &.foo are just shorthands of self.foo with different contexts" and "$.foo(1,2,3); # calls self.foo under $ context", the sigil of the attribute doesn't show up when accessing it, so you can't have attributes with the same base name but different sigils.

        Is the same thing true with $!foo, @!foo, etc? After all,
        "$!think($pinky) # short for $(self!think($pinky))"
        and I can't imagine the grammar doing things differently depending on whether the token after it was declared as a method or an attribute. I don't see the ! becoming twigil-like for attribute names, right?

        So, does $!foo appear to have a similar nature to $!bar (one of those is an attribute and the other is a submethod; which is which?) with respect to @!foo etc meaning the same slot in a different context? Or does it appear to be similar to a local variable, with the sigil and twigil being part of the name and @!foo being a different location?

        —John

Re^3: Language features affect style
by Anonymous Monk on Jun 08, 2009 at 15:30 UTC
    Perl 6 is still not Java, after all.

    Is it gasoline? No, perl is Camelia :)

      Camelia?


      holli

      When you're up to your ass in alligators, it's difficult to remember that your original purpose was to drain the swamp.