Hi all, Do traits let you share state also or only behavior? Best, Laura |
2015-01-28 16:41 GMT+01:00 Laura Risani <[hidden email]>:
Traits only share behaviors. As you guessed, it is still questionable to many people if multiple inheritance is good because state can be inherited multiple times. For example, what do happen if C inherits from A and B and that both A and B have a field name i. There are existing solutions for this problem but they're all not perfect. Traits were implemented language-side only. If you want you can implement multiple inheritance language side only too (as for traits, you'll have to add virtual copies of methods and if state is shared too you'll have virtual copies of instance variables to run on our current VM), and see which one you prefer. I'd be glad to hear your feedback on that.
|
In reply to this post by laura
Mostly, multiple inheritance is difficult to implement well in a simple enough form. The only language I know of that has a reasonably usable version of it is Eiffel (probably Nit too, but I don't know enough about it http://nitlanguage.org). There is the diamond inheritance problem, the problem that inheritance (even in Smalltalk) mixes subtyping (interface extension) and reuse of implementation, problems of how to linearize method lookup, etc. On 28 January 2015 at 16:41, Laura Risani <[hidden email]> wrote:
|
In reply to this post by laura
Because smalltalk methods require so little code that overt-delegation is both easy to author and to understand. If on the other hand, one needs to repeatedly tell the compiler what types of data shall be used used, and then insert numerous delimiters, such delegation becomes onerous... and ... then one would beg for a compiler solution. -cam On Wed, Jan 28, 2015 at 10:41 AM, Laura Risani <[hidden email]> wrote:
|
In reply to this post by laura
Laura, Obviously, I should have let the experts answer, and I did not answer all of your questions in that last quick-off-the-cuff diss-the-strongly-typed-languages answer. My apologies. For me, i like to keep the namespace clean. And one must admit, with multiple inheritance, things can get confusing, and in some cases, the wrong methods come into play. If one breaks free of inheritance as a means to gain polymorphism, code re-usability can grow considerably, and the ability to substitute classes to be used by a 3rd party libraries grows with it. I generally prefer delegation(/decoration) approaches to inheritance, in part just to control the namespace and "interface" of a class. Traits are still not widely available in different smalltalks, are they? -Cam On Wed, Jan 28, 2015 at 10:41 AM, Laura Risani <[hidden email]> wrote:
|
In reply to this post by laura
On Wed, Jan 28, 2015 at 11:41 PM, Laura Risani <[hidden email]> wrote:
|
Thank you all for your insights, they were very educational to me. On Thu, Jan 29, 2015 at 5:49 AM, Ben Coman <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |