On Tue, Oct 18, 2005 at 04:43:57PM +0200, Juerd wrote:
: dot sigils are not actually special. They are required on has-variables
: and forbidden on all other. Changing them to be optional is trivial, or
: so I hope.
Dot sigils drive accessor generation, which essentially hoists an
ordinary
Larry Wall skribis 2005-10-19 1:43 (-0700):
On Tue, Oct 18, 2005 at 04:43:57PM +0200, Juerd wrote:
: dot sigils are not actually special. They are required on has-variables
: and forbidden on all other. Changing them to be optional is trivial, or
: so I hope.
Dot sigils drive accessor
On Wed, Oct 19, 2005 at 12:33:11PM +0200, Juerd wrote:
: : make $:foo equivalent to :foo($foo) (conjectural)
:
: This one is new to me. I'm not sure I understand what it's used for. Is
: there already some documentation about it?
It's in my copy of S06, which I haven't checked in
Larry Wall skribis 2005-10-19 4:03 (-0700):
The absence of a dot creates a private attribute. We decided it should
be even easier to declare a private attribute than a public one, so it's
just
has $foo;
and then it is visible only in the lexical scope.
This takes away my objections to
On Wed, Oct 19, 2005 at 04:03:54AM -0700, Larry Wall wrote:
: This one is new to me. I'm not sure I understand what it's used for. Is
: there already some documentation about it?
It's in my copy of S06, which I haven't checked in yet.
Is there an AES commit feed available somewhere?
--
Disclaimer: I don't ~~ @larry :)
[EMAIL PROTECTED] wrote:
class Bar {
our $.bar;
{
my $.foo;
}
}
I assume that the leading $. is what makes the difference, however,
IIRC the $. is just part of the name, and no more special than
that. Which means that I can choose that
On Oct 18, 2005, at 6:56 AM, Miroslav Silovic wrote:
Disclaimer: I don't ~~ @larry :)
[EMAIL PROTECTED] wrote:
class Bar {
our $.bar;
{
my $.foo;
}
}
I assume that the leading $. is what makes the difference,
however, IIRC the $. is just part of the name, and no more
Stevan Little skribis 2005-10-18 10:16 (-0400):
You are probably right, but are the twigils actually special? or is
it just a naming convention.
dot sigils are not actually special. They are required on has-variables
and forbidden on all other. Changing them to be optional is trivial, or
so I
On Tue, 2005-10-18 at 10:16 -0400, Stevan Little wrote:
On Oct 18, 2005, at 6:56 AM, Miroslav Silovic wrote:
Uhm. I'm not sure either. :) The way I read Larry's mail,
multimethods use .isa operator to detect whether $foo belongs to
Foo. And for every class, Foo.isa(Foo) is true (this
[EMAIL PROTECTED] wrote:
U... I'm not sure that allowing $. injection from the nested
blocks is a good thing. I don't think it's ambiguous, but to me it
looks weird and confusing - if a user put the variable in the nested
block like that, it's almost certain he actually meant to write
[EMAIL PROTECTED] wrote:
I think what bothers me most about this is that it seems there is no
way to tell the difference between class methods and instance
methods. That the distinction is only made when the body of the
method does something which is is not supposed to do (method called
Miroslav
On Oct 17, 2005, at 7:35 AM, Miroslav Silovic wrote:
[EMAIL PROTECTED] wrote:
I think what bothers me most about this is that it seems there is
no way to tell the difference between class methods and instance
methods. That the distinction is only made when the body of the
On 2005-10-15 15:28, Ilmari Vacklin [EMAIL PROTECTED] wrote:
On Sat, Oct 15, 2005 at 09:49:30AM -0700, Larry Wall wrote:
On Sat, Oct 15, 2005 at 07:39:36PM +0300, wolverian wrote:
: IMHO just call it self (by default) and be done with it. :)
Let it be so.
Somewhat off-tangent: does this
HaloO,
Stevan Little wrote:
Now, as for class methods, I suppose it is possible to just stash then
in the classes symbol table like with variables. However, do we then
loose the method call syntax?
I think not. But the current notion seems to drift closer to my
idea of free methods versus
On Oct 17, 2005, at 12:32 PM, TSa wrote:
This also means that they would not (directly) be inheritable
since inheritence moves along superclass lines, and not with
@ISA. I am also not sure what you mean about multi-methods
either, could you please explain more?
Symmetric MMD at least
Larry,
On Oct 14, 2005, at 2:15 PM, Larry Wall wrote:
Look guys, I want it to just consistently be
method bark (Dog $d) {...}
regardless of how instantiated the dog is. Think of partially
instantiated subroutines via .assuming. A sub is a sub regardless of
how much it's been curried.
On Sat, Oct 15, 2005 at 10:34:34AM -0400, Stevan Little wrote:
: I think what bothers me most about this is that it seems there is no
: way to tell the difference between class methods and instance
: methods. That the distinction is only made when the body of the
: method does something
On Sat, Oct 15, 2005 at 08:25:15AM -0700, Larry Wall wrote:
[snip]
Of course, there's never been any controversy here about what to call
self, oh no... :-)
IMHO just call it self (by default) and be done with it. :)
--
wolverian, contributing to the general disagreement
On Sat, Oct 15, 2005 at 07:39:36PM +0300, wolverian wrote:
: On Sat, Oct 15, 2005 at 08:25:15AM -0700, Larry Wall wrote:
: [snip]
:
: Of course, there's never been any controversy here about what to call
: self, oh no... :-)
:
: IMHO just call it self (by default) and be done with it. :)
Larry,
On Oct 15, 2005, at 11:25 AM, Larry Wall wrote:
: But we have to think a bit more about the notion of currying class
: objects into real objects, or something approaching real objects.
:
: This is an interesting thought, I will have to ponder it some,
but it
: has a nice smell. Of
Larry,
On Oct 15, 2005, at 11:25 AM, Larry Wall wrote:
On Sat, Oct 15, 2005 at 10:34:34AM -0400, Stevan Little wrote:
: I think what bothers me most about this is that it seems there is no
: way to tell the difference between class methods and instance
: methods. That the distinction is only
On Sat, Oct 15, 2005 at 09:49:30AM -0700, Larry Wall wrote:
On Sat, Oct 15, 2005 at 07:39:36PM +0300, wolverian wrote:
: IMHO just call it self (by default) and be done with it. :)
Let it be so.
Somewhat off-tangent: does this mean that .foo is always $_.foo?
Larry
--
Ilmari Vacklin
On Fri, Oct 14, 2005 at 01:43:39PM +1100, Stuart Cook wrote:
: On 14/10/05, Stevan Little [EMAIL PROTECTED] wrote:
: So anyway, here are a few ideas, in no particular order:
:
: method bark (::Dog $d:) { ... }
: # not sure if this notation is already taken or not
:
: method bark
Larry,
I have been giving a lot of thought to the way you have been
describing classes lately. I think I understand where you are going
with it, but I need to understand some of the details.
On Oct 14, 2005, at 2:15 PM, Larry Wall wrote:
This only reinforces my view that all the meta
Well, I suspected there would not be much support for my initial
proposal on class methods, but I felt I had to try. Not being the
type of person who gives up easily, I want to revise the proposal
(incorporating some of the ideas in the responses).
I propose that class methods are
On 14/10/05, Stevan Little [EMAIL PROTECTED] wrote:
So anyway, here are a few ideas, in no particular order:
method bark (::Dog $d:) { ... }
# not sure if this notation is already taken or not
method bark ($Dog $d:) { ... }
# not sure I like this one myself, but to me it helps
26 matches
Mail list logo
