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
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
--- 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)
such
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 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
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 being a
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
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
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?
--
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
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
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 example
is
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
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
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
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.
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
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
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
(since
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
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,
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
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
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
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
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),
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
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
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
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
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
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
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 Cnew() class method
wasn't inheritable.
Damian
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
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
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
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
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
52 matches
Mail list logo
