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