--- Larry Wall wrote:
> On Tue, Oct 25, 2005 at 05:24:52PM +0200, Michele Dondi wrote:
> : But maybe that's just me. Whatever, I guess that the {casual,average}
> : programmer may be scared by its richness and complexity.
>
> But we're trying to design the OO features (indeed, all of Perl 6)
> su
On Wed, Oct 26, 2005 at 09:36:48AM +0200, Michele Dondi wrote:
: On Tue, 25 Oct 2005, Larry Wall wrote:
:
: >But we're trying to design the OO features (indeed, all of Perl 6)
: >such that you can usefully cargo cult those aspects that are of
: >immediate interest without being forced to learn the
On Tue, 25 Oct 2005, Larry Wall wrote:
But we're trying to design the OO features (indeed, all of Perl 6)
such that you can usefully cargo cult those aspects that are of
immediate interest without being forced to learn the whole thing.
It's not the number one design goal, but it's right up there
On Tue, Oct 25, 2005 at 05:24:52PM +0200, Michele Dondi wrote:
: Also, Perl6 OO capabilities are already above the top of my head.
Sure, they're above my head too. Which should be obvious by now... :-)
: But maybe that's just me. Whatever, I guess that the {casual,average}
: programmer may be
On Tue, 25 Oct 2005, Stevan Little wrote:
Well, the point is that it is interesting to note that "text processing"
is an _application area_, whereas "OO programming" is a programming
language paradigm.
Allow me to clarify.
Perl 5 (and below) are known by outsiders (non-perl users) as bein
On Oct 25, 2005, at 6:31 AM, Michele Dondi wrote:
On Fri, 14 Oct 2005, Stevan Little wrote:
I think Perl 6's OO system has the potential to be to OO
programming what Perl 5, etc was to text processing. This, I
believe, is in large part due to
Sorry for replying so late. Thought it seems ap
On Fri, 14 Oct 2005, Stevan Little wrote:
I think Perl 6's OO system has the potential to be to OO programming what
Perl 5, etc was to text processing. This, I believe, is in large part due to
Sorry for replying so late. Thought it seems appropriate to post this in
this time of "Perl 6 fears"
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?
--
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
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 yet
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 ge
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 variabl
[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
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
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
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 mor
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 th
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 h
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 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-ta
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
metho
[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
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 Vackl
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 ma
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 co
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.
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 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 which
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. So
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 stuff
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 b
Piers,
On Oct 14, 2005, at 12:14 PM, Piers Cawley wrote:
Stevan Little <[EMAIL PROTECTED]> writes:
On Oct 12, 2005, at 5:22 AM, Piers Cawley wrote:
We definitely have two instances of A since, B.isa(::A). We also
have
a fragile implementation of count.
:)
Sorry, I purposefully made it a
Stevan Little <[EMAIL PROTECTED]> writes:
> Piers,
>
> On Oct 12, 2005, at 5:22 AM, Piers Cawley wrote:
>> We definitely have two instances of A since, B.isa(::A). We also have
>> a fragile implementation of count.
>
> :)
>
> Sorry, I purposefully made it a kludge as that is usually the way the e
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
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 inheritab
On Oct 13, 2005, at 4:45 PM, TSa wrote:
No, not that class has no state, but that with the currently
specced classes we have inherited behaviors (class methods) but
they do not inherit the accompanying state (class attributes) as
well. I see this as potentially very problematic.
What
HaloO,
Stevan Little wrote:
On Oct 11, 2005, at 8:47 PM, Larry Wall wrote:
You seem to be arguing that a class has no state, but my view is that,
in the abstract, a class encompasses the state of *all* its objects.
It just hasn't picked one particular object to be at the moment.
I love this n
Brent,
On Oct 11, 2005, at 8:17 PM, Brent 'Dax' Royal-Gordon wrote:
Stevan Little <[EMAIL PROTECTED]> wrote:
I would like to propose that class methods do not get inherited along
normal class lines.
I think you're not thinking about many major usage cases for class
methods.
Actually I h
All -
I'm partly to blame for this thread because I put the idea into
Steve's head that class methods being inheritable may be dogma and not
a useful thing. Mea culpa.
That said, I want to put forward a possible reason why you would
want class methods to be inheritable - to provide pure f
Stevan Little <[EMAIL PROTECTED]> wrote:
> I would like to propose that class methods do not get inherited along
> normal class lines.
I think you're not thinking about many major usage cases for class methods.
For one example, look at my Cipher suite. (It's in Pugs's ext/Cipher
directory.) The
Actually, I wondered why you didn't suggest this earlier. :) I
figured you were a step ahead of me: What if I want more than a
boolean out of my class method?
On Oct 12, 2005, at 10:27, Stevan Little wrote:
Gordon,
It just occurred to me that the system shown below could be re-
written to
On Wed, 2005-10-12 at 12:00 -0400, Stevan Little wrote:
> Usefulness aside, why do Roles and Classes need to be seperate
> beasts? In the current meta-model prototype, the role system is laid
> atop the class system so that the following is true:
>
> Class is an instance of Class
> Role is an
On Oct 12, 2005, at 09:41, Stevan Little wrote:
If you use the BUILD submethod, then you never need to worry about
a that, everything is initialized for you by BUILDALL. Now, if you
want to have a constructor which accepts positional arguments
rather than named pairs (as the default does),
Gordon,
On Oct 12, 2005, at 11:04 AM, Gordon Henriksen wrote:
On Oct 12, 2005, at 09:41, Stevan Little wrote:
If you use the BUILD submethod, then you never need to worry about
a that, everything is initialized for you by BUILDALL. Now, if you
want to have a constructor which accepts positi
Gordon,
On Oct 12, 2005, at 10:48 AM, Gordon Henriksen wrote:
Actually, I wondered why you didn't suggest this earlier. :) I
figured you were a step ahead of me: What if I want more than a
boolean out of my class method?
Then you put the class methods back in :)
But then your Objective-C i
Larry,
On Oct 11, 2005, at 8:47 PM, Larry Wall wrote:
On Tue, Oct 11, 2005 at 06:10:41PM -0400, Stevan Little wrote:
: Hello all.
:
: I would like to propose that class methods do not get inherited
along
: normal class lines.
I think most class methods should be written as submethods instead
Gordon,
It just occurred to me that the system shown below could be re-
written to do away with class methods entirely.
class Host {
my $.plugInClass;
}
role PlugIn {
method initWithHost (Host $h:) { ... }
}
role FeatureA {}
role FeatureB {}
role FeatureC {}
class AB {
does Plug
Piers,
On Oct 12, 2005, at 5:22 AM, Piers Cawley wrote:
We definitely have two instances of A since, B.isa(::A). We also have
a fragile implementation of count.
:)
Sorry, I purposefully made it a kludge as that is usually the way the
example is shown in most tutorials about class methods.
Gordon,
On Oct 11, 2005, at 9:10 PM, Gordon Henriksen wrote:
On Tue, Oct 11, 2005 at 06:10:41PM -0400, Stevan Little wrote:
I would like to propose that class methods do not get inherited along
normal class lines.
You mean, make them *not methods?* Because it's not a method unless it
has an i
Stevan Little <[EMAIL PROTECTED]> writes:
> Hello all.
>
> I would like to propose that class methods do not get inherited along
> normal class lines.
>
> I think that inheriting class methods will, in many cases, not DWIM.
> This is largely because your are inheriting behavior, and not state
> (s
On Tue, Oct 11, 2005 at 06:10:41PM -0400, Stevan Little wrote:
> I would like to propose that class methods do not get inherited along
> normal class lines.
You mean, make them *not methods?* Because it's not a method unless it
has an invocant, as far as I'm concerned. (Method implies polymorph
David,
On Oct 11, 2005, at 8:42 PM, Dave Whipp wrote:
Stevan Little wrote:
David,
...
If you would please give a real-world-useful example of this usage
of class-methods, I am sure I could show you, what I believe, is
a better approach that does not use class methods.
...
The exam
On Tue, Oct 11, 2005 at 06:10:41PM -0400, Stevan Little wrote:
: Hello all.
:
: I would like to propose that class methods do not get inherited along
: normal class lines.
I think most class methods should be written as submethods instead.
: I think that inheriting class methods will, in many
Stevan Little wrote:
David,
...
If you would please give a real-world-useful example of this usage of
class-methods, I am sure I could show you, what I believe, is a better
approach that does not use class methods.
...
The example I've wanted to code in Java is along the lines of:
public
David,
On Oct 11, 2005, at 7:49 PM, Dave Whipp wrote:
Stevan Little wrote:
I would like to propose that class methods do not get inherited
along normal class lines.
One of the things that has annoyed me with Java is that it's class
methods don't inherit (dispatch polymorphically). This m
Damian,
On Oct 11, 2005, at 6:53 PM, Damian Conway wrote:
Anyway, I have said my peace, what do you all think?
I think there are serious problems with this proposal. For a start,
it would be very difficult to create *any* objects at all if the
C class method wasn't inheritable.
Actually
Stevan Little wrote:
I would like to propose that class methods do not get inherited along
normal class lines.
One of the things that has annoyed me with Java is that it's class
methods don't inherit (dispatch polymorphically). This means that you
can't apply the "template method" pattern to
Anyway, I have said my peace, what do you all think?
I think there are serious problems with this proposal. For a start, it would
be very difficult to create *any* objects at all if the C class method
wasn't inheritable.
Damian
Hello all.
I would like to propose that class methods do not get inherited along
normal class lines.
I think that inheriting class methods will, in many cases, not DWIM.
This is largely because your are inheriting behavior, and not state
(since class attributes are not inheritable). Let m
59 matches
Mail list logo
