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