Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

Re^3: Language features affect style

by John M. Dlugosz (Monsignor)
on Jun 09, 2009 at 19:13 UTC ( #770063=note: print w/replies, xml ) Need Help??

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

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)?


Replies are listed 'Best First'.
Re^4: Language features affect style
by TimToady (Parson) on Jun 09, 2009 at 23:15 UTC
    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 are just shorthands of with different contexts" and "$.foo(1,2,3); # calls 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?


        We're kinda confusing levels here. There are really three viewpoints of an object:
        1. The external public view.
        2. The internal private view.
        3. The hidden MOP view
        I was speaking from the perspective of #2, not #3. From the #2 perspective, for any normal attribute without an explicit private accessor, $!foo and self!foo are largely interchangeable, give or take a sigil. The MOP may or may not make visible the call that implements $!foo, since $!foo is viewed under #2 as fundamentally a reference to the storage. The MOP is free to not implement method !foo at all if it can determine that it is unneeded, either by analysis or just by being lazy about autoloading one. From the #2 viewpoint, $!foo is just a variable, and method !foo is a (possibly autogenerated) accessor to the variable.

        From the #3 perspective, sure, the fundamental accessor for the slot could be identical to method !foo, but then you're kinda hosed if the user wants to actually define the !foo method as a wrapper around $!foo, which would be an infinite regress if you confuse the user's slot accessor with the MOP's slot accessor. So unlike the situation with $.foo, the $!foo notation is not just syntactic sugar for a private accessor, and a private method must be called as self!foo.

        So why would the user ever want to define their own private accessor? Primarily to mediate how much you want to dynamically "untrust" any other classes you've trusted by declaration.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://770063]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (3)
As of 2023-06-04 11:55 GMT
Find Nodes?
    Voting Booth?
    How often do you go to conferences?

    Results (21 votes). Check out past polls.