--- 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"
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 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
32 matches
Mail list logo
