A long time ago ... Dan said:
Roles'll get thrown on individual variables and values, sure, but when
I'm writing a class (Yes, I know, but lets suspend disbelief for a
moment :) I'm not generally going to put a pre-existing role on a
class--I'll just inherit from the darned thing. Roles,
On Sun, 2004-02-22 at 11:34, stevan little wrote:
One thing that I noticed was that the authors seem to not intend
Traits to be thought of as being like Classes. As a matter of fact
they distinguish Traits from Classes in their Trait Language
(contained in the above paper). So the idea of
On Thu, Feb 12, 2004 at 09:38:47AM -0800, Larry Wall wrote:
Yes, that's a very good paper, which is why Perl 6 now has something
called Roles, which are intended to degenerate either to Traits or
Interfaces. My take on it is that Roles' most important, er, role
will be to abstract out the
On Thu, Feb 12, 2004 at 05:58:18PM -0800, Jonathan Lang wrote:
: Larry Wall wrote:
: What I'm currently thinking about is a does predicate that tells you
: if an object/class does a particular role completely. If you pull
: part of a role into a class, it returns false, because it doesn't do
:
At 8:30 AM -0800 2/17/04, Larry Wall wrote:
So perhaps we need a different word than does to indicate that
you want to include the Dog interface without including the Dog
implementation. Perhaps we can do that with is like(Dog) or some
such if we don't want to Huffman code it shorter. Then
On Tue, Feb 17, 2004 at 11:39:07AM -0500, Dan Sugalski wrote:
: At 8:30 AM -0800 2/17/04, Larry Wall wrote:
: So perhaps we need a different word than does to indicate that
: you want to include the Dog interface without including the Dog
: implementation. Perhaps we can do that with is like(Dog)
At 9:15 AM -0800 2/17/04, Larry Wall wrote:
On Tue, Feb 17, 2004 at 11:39:07AM -0500, Dan Sugalski wrote:
: At 8:30 AM -0800 2/17/04, Larry Wall wrote:
: So perhaps we need a different word than does to indicate that
: you want to include the Dog interface without including the Dog
:
On Fri, Feb 13, 2004 at 01:22:38PM +0300, Dmitry Dorofeev wrote:
: My stupid question still apply.
: Will it be possible to have
: 'Exclusion' which forms a new trait|Role by removing a method from an
: existing trait|Role ?
There will certainly be some way to exclude or at least hide the
On Thu, 2004-02-12 at 14:03, chromatic wrote:
On Thu, 2004-02-12 at 05:52, Aaron Sherman wrote:
Perhaps I'm slow, but I don't see the difference between a trait and a
Java interface other than the fact that traits appear to be more of a
run-time construct.
The easy answer is that
Hi all,
I see that i am not alone in my thoughts about classic OO drawbacks.
Some smart people created traits for SmallTalk which is something
close to what i want.
Traits are mechanism, recently proposed by Scharli et al, for factoring Smalltalk class hierarchies. By separating the issue of code
Yes, that's a very good paper, which is why Perl 6 now has something
called Roles, which are intended to degenerate either to Traits or
Interfaces. My take on it is that Roles' most important, er, role
will be to abstract out the decision to compose or delegate. But we'd
like them to function as
On Thu, 2004-02-12 at 05:52, Aaron Sherman wrote:
Perhaps I'm slow, but I don't see the difference between a trait and a
Java interface other than the fact that traits appear to be more of a
run-time construct.
The easy answer is that interfaces completely suck while traits don't.
:)
On Thu, Feb 12, 2004 at 11:03:57AM -0800, chromatic wrote:
: On a conceptual level, the different syntax is the worst crime because
: it reinforces the idea that the important question about an object is
: What is this object's position in a class hierarchy?, not Does this
: object have the same
On Thu, 2004-02-12 at 11:49, Larry Wall wrote:
What I'm currently thinking about is a does predicate that tells you
if an object/class does a particular role completely. If you pull
part of a role into a class, it returns false, because it doesn't do
the complete role. However, if you use
On Thu, Feb 12, 2004 at 12:02:50PM -0800, chromatic wrote:
: Is it more useful to find the Dog-like-ness of a class or the notion
: that SomeClass.bark() is semantically Dog-like, not Tree-like?
I expect we'd use .can() for method-based queries.
: I expect to care more that the object does
Larry Wall wrote:
I only see like() as counting the methods available through the public
contract to determine its percentage. Something you could do by hand with
.can(). But there wouldn't be much point in putting it in if people
won't use it. On the other hand, if people want it and it's not
Larry Wall wrote:
What I'm currently thinking about is a does predicate that tells you
if an object/class does a particular role completely. If you pull
part of a role into a class, it returns false, because it doesn't do
the complete role. However, if you use like instead, it returns a
Joseph Ryan writes:
It's surely possible by modifying that class's DISPATCH.
Whether it should actually be in the language is up for debate. I'd say
that if you need to do this with any frequency whatsoever, you're not
thinking about roles right. A good example might be in order... :-)
On Wed, Feb 04, 2004 at 01:30:44AM -0500, Joseph Ryan wrote:
Whether it should actually be in the language is up for debate. I'd say
that if you need to do this with any frequency whatsoever, you're not
thinking about roles right. A good example might be in order... :-)
Well, what if the
Woops, sent it to the wrong list!
- Joe
Joseph Ryan wrote:
Luke Palmer wrote:
Austin Hastings writes:
Hmm. The text and examples so far have been about methods and this
seems to be about multi-methods. Correct me if I'm wrong ...
You're wrong. Consider my example, where via single
Luke Palmer wrote:
Austin Hastings writes:
Hmm. The text and examples so far have been about methods and this
seems to be about multi-methods. Correct me if I'm wrong ...
You're wrong. Consider my example, where via single inheritance we reach a
layered list of methods, each of which
Austin Hastings wrote:
Jonathan Lang wrote:
Actually, no; roles don't _need_ suppress or rename options to
disambiguate a conflict: the priority chain of class methods, then
role methods, then inherited methods provides all the tools that are
_required_ to remove ambiguities: you merely
On Thu, Jan 29, 2004 at 10:54:18PM -0500, Austin Hastings wrote:
-Original Message-
From: Jonathan Lang [mailto:[EMAIL PROTECTED]
Actually, no; roles don't _need_ suppress or rename options to
disambiguate a conflict: the priority chain of class methods, then role
methods, then
-Original Message-
From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED]
On Thu, Jan 29, 2004 at 10:54:18PM -0500, Austin Hastings wrote:
-Original Message-
From: Jonathan Lang [mailto:[EMAIL PROTECTED]
Actually, no; roles don't _need_ suppress or rename options to
Austin Hastings writes:
Hmm. The text and examples so far have been about methods and this
seems to be about multi-methods. Correct me if I'm wrong ...
You're wrong. Consider my example, where via single inheritance we reach a
layered list of methods, each of which replaces the previous
Austin Hastings wrote:
Jonathan Lang wrote:
The danger isn't really in the ability to suppress a method from a
given role or parent; the danger comes from the ability to suppress a
method from _every_ role or parent. A safe alternative to this would
be to define a class method which
-Original Message-
From: Jonathan Lang [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 29, 2004 10:25 PM
To: [EMAIL PROTECTED]; Perl6 Language
Subject: RE: OO inheritance in a hacker style
Austin Hastings wrote:
Jonathan Lang wrote:
The danger isn't really in the ability
-Original Message-
From: Jonathan Lang [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 29, 2004 1:29 AM
To: Joseph Ryan; Dmitry Dorofeev
Cc: Perl6 Language List
Subject: Re: OO inheritance in a hacker style
Joseph Ryan wrote:
Of course, roles are another great way
Hi all.
Sorry if this idea|question has been discussed or has name which i don't know about.
I am not very good at OO but I tried at least 2 times to develop with it though :-)
Last time it was Java. The problem is that when i going to use some 'standard' class
or 3d party class i'd rather to cut
On Wed, Jan 28, 2004 at 03:18:24PM +0300, Dmitry Dorofeev wrote:
I am not very good at OO but I tried at least 2 times to develop with it
though :-)
Last time it was Java. The problem is that when i going to use some
'standard' class
or 3d party class i'd rather to cut off all unnecessary
Dmitry Dorofeev writes:
Hi all.
Sorry if this idea|question has been discussed or has name which i don't
know about.
I am not very good at OO but I tried at least 2 times to develop with
it though :-) Last time it was Java. The problem is that when i going
to use some 'standard' class or
Dmitry Dorofeev wrote:
Hi all.
Sorry if this idea|question has been discussed or has name which i
don't know about.
snip
I'd like to write
Class myclass : a {
forget method area;
forget method move;
method put;
}
so methods getX, getY, size will be 'inherited'.
Methods 'area' and 'move' will
Joseph Ryan wrote:
Of course, roles are another great way to prevent confusion with
multiple inheritance. A good question would be whether something
like forget is useful in addition, or whether everyone should
just use roles. :)
For the record, roles are not a form of multiple inheritence.
33 matches
Mail list logo
