On Saturday 05 April 2008 17:10:57 Larry Wall wrote:
> On Fri, Apr 04, 2008 at 09:41:26PM -0500, John M. Dlugosz wrote:
> > I suppose any object would do, it doesn't have to be "but undefined", or
> > created using that Class{hash} syntax?
>
> Possibly. Haven't really thought through the ramific
On Fri, Apr 04, 2008 at 09:41:26PM -0500, John M. Dlugosz wrote:
> But see my q's to Audrey. Why does it need the qualified name if the same
> class as $obj's declared type,
We could conceivably relax that if $obj has a declared type. But on
the other hand requiring the class name is pretty goo
Many thanks.
Larry Wall larry-at-wall.org |Perl 6| wrote:
self!BaseName::attr should work, assuming BaseName trusts us.
Because it is an accessor function, not a syntax to reference a variable
in another scope. Got it.
But see my q's to Audrey. Why does it need the qualified name if the
Ryan Richter ryan-at-tau.solarneutrino.net |Perl 6| wrote:
You've declared method a twice here.
According to S12, "You may write your own accessors to override any or all of the
autogenerated ones."
has $!a;
method a { $!a }
The variable is always really the $! form.
I'm catching o
On Fri, Apr 04, 2008 at 07:01:32PM -0500, John M. Dlugosz wrote:
> That is, a derived class, assuming it was trusted, could use
> $self!BaseName::attr to prevent confusion with something named self!attr
> that ordinarily hides it.
Which is never a problem anyway, since private attributes are nev
You have completely lost me, John. What the heck are you asking?
$obj.foo: calls public method "foo" on the object referenced by $obj.
$.foo shorthand for calling "foo" on self (in scalar context).
As I understand it, although I could be confused, these have
absolutely nothing to do with w
On Friday 04 April 2008 16:56:44 Audrey Tang wrote:
> In other words, there needs to be no real hard attribute "bar", no
> matter if you call the "bar" method as self.bar(), $.bar(), or simply
> $.bar.
That's what I was trying to say with "uniform access principle", except that
Audrey's version
John M. Dlugosz wrote:
Seriously,
Does this mean that the access of private attributes from trusted
classes is a "different form"? And that's why you need the qualified
syntax when I think it should not be necessary in all cases? Or should
that passage really say "not in non-trusted classes, incl
Audrey Tang audreyt-at-audreyt.org |Perl 6| wrote:
"Every Idiot declaration... "
Sorry, must be a font problem
Seriously,
Does this mean that the access of private attributes from trusted
classes is a "different form"? And that's why you need the qualified
syntax when I think it should not be
John M. Dlugosz wrote:
Audrey Tang audreyt-at-audreyt.org |Perl 6| wrote:
John M. Dlugosz wrote:
A method can refer to private attributes etc. in other objects than
self. This is unlike Smalltalk and like C++. Which objects? Obviously,
those that _have_ them in the first place.
Correct, thoug
I understand your example. In fact, it further clarifies your earlier note.
But that's not what I meant. I was thinking that access was through a
variable, not understanding the real point of the syntax.
Audrey Tang audreyt-at-audreyt.org |Perl 6| wrote:
John M. Dlugosz wrote:
That seems t
John M. Dlugosz wrote:
OK, trust is not implicit on derived classes. Is that because there is
no rule that says it is, or is there a mention of that somewhere in the
official docs?
There is. S12 Line 561:
Every I declaration also declares a corresponding private
I storage location, and the e
Darren Duncan darren-at-darrenduncan.net |Perl 6| wrote:
A method is defined within a role or class, as is an attribute. A
private attribute can generally be referenced only by a method
declared in the same role or class as said attribute.
I think that's not right. A private attribute defi
Audrey Tang audreyt-at-audreyt.org |Perl 6| wrote:
John M. Dlugosz wrote:
A method can refer to private attributes etc. in other objects than
self. This is unlike Smalltalk and like C++. Which objects? Obviously,
those that _have_ them in the first place.
Correct, though those classes also has
John M. Dlugosz wrote:
That seems to be saying that using the method-call form is preferred, as
it abstracts whether it is a real hard attribute or not.
Er, it is not so.
The $.foo notation is good not only for calling accessors, but also as a
way to specify context when calling oneself's met
On Friday 04 April 2008 16:31:56 John M. Dlugosz wrote:
> chromatic chromatic-at-wgz.org |Perl 6| wrote:
> > It shouldn't be.
> So you are saying that...
I was talking about syntax.
> In that case, why allow the variable-name form at all?
Because they're variables. Sure, they're instance vari
On Fri, Apr 04, 2008 at 06:31:56PM -0500, John M. Dlugosz wrote:
> chromatic chromatic-at-wgz.org |Perl 6| wrote:
> >It shouldn't be.
> >
> So you are saying that in the example of
>
>class C {
> has $.a;
> method a ($self:)
You've declared method a twice here. has $.a is equiv
chromatic chromatic-at-wgz.org |Perl 6| wrote:
It shouldn't be.
So you are saying that in the example of
class C {
has $.a;
method a ($self:)
{
side_effect();
return $self.a;
}
} # end C
class D is C {
method foo ($self:)
John M. Dlugosz wrote:
A method can refer to private attributes etc. in other objects than
self. This is unlike Smalltalk and like C++. Which objects?
Obviously, those that _have_ them in the first place. Does the variable
used as the invocant, or return value if it is an expression, have t
John M. Dlugosz wrote:
A method can refer to private attributes etc. in other objects than
self. This is unlike Smalltalk and like C++. Which objects? Obviously,
those that _have_ them in the first place.
Correct, though those classes also has to trust the calling class:
class MyClass { has $!
On Friday 04 April 2008 13:47:40 John M. Dlugosz wrote:
> But, it is also stated that in derived and trusted classes, and even in
> the class itself, $.a is an accessor call? As opposed to $!a which is
> the direct access to the attribute. Is this accessor different from the
> function form used
After reading S12, I have many many notes about things that need to
be tightened up or places that open more questions then provide answers.
But, a lot of it boils down to a core set of issues. Can y'all explain
these to me? Help me see the core concepts, and I can work out the
details and s
22 matches
Mail list logo
