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
On Wed, Apr 02, 2008 at 11:56:37PM -0500, Jonathan Scott Duff wrote:
: Or you could setup pmwiki as a nod to our perl6 compiler pumpking :-)
:
: In any case, pmwiki is simpler to setup than twiki.
Yes, but I also know the author of twiki, and it's written in Perl
rather than PHP...
Larry
On Wed, Apr 02, 2008 at 06:08:55PM -0700, Jon Lang wrote:
: In "Question on your last change to S02", Larry Wall wrote:
: > (By the way, you'll note the utility of being able to talk about a
: > postfix by saying .[], which is one of the reasons we allow the optional
: > dot there. :)
:
: Can I
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
Cartesian product of anything with the empty set is empty. Which is
why SQL has outer joins.
On 4/4/08, TSa <[EMAIL PROTECTED]> wrote:
> HaloO,
>
> why is (1,2,3) X () defined to be the empty list
> and not (1,2,3) as is the case with the cartesian
> product of sets which X basically is with pre
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
On Fri, Apr 04, 2008 at 06:51:20PM +0200, TSa wrote:
> HaloO,
>
> why is (1,2,3) X () defined to be the empty list
> and not (1,2,3) as is the case with the cartesian
> product of sets which X basically is with preserved
> order.
(@a X @b X @c).elems == @a.elems * @b.elems * @c.elems
Larry
Cartesain product with the empty set is empty. A x B is the set of all pairs
(a,b) where a is in A and b is in B. If either is empty then there are no such
pairs and the result is also empty.
--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
-- Original message
HaloO,
why is (1,2,3) X () defined to be the empty list
and not (1,2,3) as is the case with the cartesian
product of sets which X basically is with preserved
order.
Regards, TSa.
--
The Angel of Geometry and the Devil of Algebra fight for the soul
of any mathematical being. -- Attributed to H
26 matches
Mail list logo
