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 o
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, whe
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
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
: >implement
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
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 pe
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
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
method
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 t
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 decision to compose or delegate. But we'd
like th
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
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 t
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 someth
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
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 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.
:)
Seri
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
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.
Java interfaces are actually a very nice compromise between multiple and
single inheritance.
You can not get rid of t
On Thu, 2004-02-12 at 08:14, Dmitry Dorofeev wrote:
> 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.
Perhaps I'm slow, but I don't see the difference between a trait and a
Java interf
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
Joseph Ryan wrote:
> Well, what if the two classes you want to inherit from weren't
> designed with roles in mind? For instance, there might be two
> CPAN modules that each have a dozen methods that you want to
> inherit, but they each have 1 that overlap whose conflict you
> want to easily resolv
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 inh
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
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 pr
> -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 "re
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
>
> -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:
&g
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
> -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:
>
> >
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 inherit
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' cla
Dmitry Dorofeev wrote:
Hi all.
Sorry if this idea|question has been discussed or has name which i
don't know about.
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 be n
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 unnecessa
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 o
34 matches
Mail list logo
