Robert Dober wrote:
>>
>>> Hi,
>>>
>>>
>>> >I see. So you don't really like the fact that modules fit into the
>>> >inheritance chain? That's interesting.
>>>
>>> Actually they both have their own good. I like them both. I dislike
>>> to have them both in a language. Traits injection is clear and less
>>> error prone (there's no possibility of conflicts), but sometimes
>>> method overriding is _very_ useful, where aliasing is very poor way to
>>> create method combination.
>>>
>>> If someone come to the idea to allow modules to have merits from both
>>> mixins and traits at once (without demerit), I'd love to hear.
>> I solved this "problem" over two years ago with fine grained mixins.
>> Please see http://rubyforge.org/docman/view.php/735/309/README.html
>> and look at the synopsis. Ideas (and code) in that library also came
>> from Ara Howard and Mauricio Fernandez.
>>
>> I don't want up front object composition. To me that's like static
>> typing, except for object composition. At worst, a warning should be
>> issued if a double inclusion occurs. This is what the 'use' library
>> does in verbose mode.
> If what you did solves your problem than that is good, it however does
> not address the issues that are adressed by traits.
The multi-mixin (i.e. total ordering) problem is one of the primary
reasons for Traits, or at least, one of the main digs against mixin
inheritence. My library solves that in a dynamic, but not strict, manner.
> And the good thing about traits is that, if you do not want to use
> them, then just do not.
As a third party library they're fine. But core? No.
I was not thinking of making it core, and Matz said too that having
Mixins already he will refrain from putting them into core, I feel
that this is a reasonable choice, no hard feelings at all.
<snip>
> OTOH I have never heard anybody complain that traits remind them of
> static typing, would you mind to elaborate on that Daniel?
In a couple of ways. First, raising an error if method conflicts arise
feels too strict for a dynamic language. I'd like a warning, but nothing
more. Also, a trait requires a set of methods that serve as parameters
for the provided behavior. Like static typing, that means up-front
declarations that don't mesh well with the overall philosophy of dynamic
languages IMO.
Hmm honestly I think that your conclusion is correct but your premises are not.
Traits are as dynamical as modules if you just "use" them, the conflict handling
is an extra you get from combining them.
In the semantics of my traits package that would be
class A
use t1, t2 # conflicts might be defined as this is equivalent to
# use t1+t2 which is equivalent to use t2 + t1 per definition
end
class A
use t1
use t2
end
does almost exactly what you would have with modules only that use t2
will always take effect because of the flattening property.
Forgive me if I am too religious about this, but I feel that traits
are an exciting thing :).
But there is one thing which is "wrong" with my package if you are
going to dynamically extend traits they will break, but that is the
fault of my - simple - implementation not really the fault of traits
:(, it might even be fixable.
Thx for your time.
Cheers
Robert
···
On 10/16/07, Daniel Berger <djberg96@gmail.com> wrote:
> On 10/15/07, Daniel Berger <djberg96@gmail.com> wrote:
>> On Oct 15, 9:38 am, Yukihiro Matsumoto <m...@ruby-lang.org> wrote:
>>> In message "Re: RubyTraits 0.1" > >>> on Tue, 16 Oct 2007 00:23:43 +0900, Trans <transf...@gmail.com> writes:
--
what do I think about Ruby?
http://ruby-smalltalk.blogspot.com/
