OO inheritance in a hacker style
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 off all unnecessary methods (and may be even
properies!),
then adding my own. I know it kills inheritance but it is much more to my Perl habit
of hacking code.
example:
Class a {
method getX;
method getY;
method size;
method area;
method move;
}
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 not present in myclass at all!
so
$a = new myclass;
$a.area()
will return an error.
At some level of inheritance methods area() and move() may be reimplemented again if required.
I see few benefits
1. Much more flexible to build what programmers need. Becouse we have both 'joining'
and 'breaking' around us in real life.
2. Inheritance diagrams may become less in size, showing only what programmer use or
need in classes.
3. probably there are some optimization possibilities (especially for properties)
i see some drawbacks
1. kills traditional OO mainstream, theory and books
2. hard to keep track both for 'added' methods and for 'killed' methods in mind.
3. hard to know if 'killed' method called from the other methods in the class. But
that may be
not a problem if we just declare forget blah, without affecting run-time.
I am very interested what Perl gurus think about it. Even if you consider this as
stupidiest idea ever.
Which is probably true :-)
-Dmitry Dorofeev.
Traits: to renew OO inheritance in a hacker style discussion
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 reuse from the inheritance hierarchy, traits allow one to avoid problems with methods defined too high in the inheritance hierarchy while sharing common implementation. Early experience with traits in Smalltalk shows that traits are an effective way to improve code sharing in class hierarchies. This positive experience with traits in the untyped Smalltalk world suggests that traits may be useful in statically typed languages too. Schâ•—arli et al. recently proposed a mechanism called traits as a way to foster code reuse in objectoriented programs [SDNB03]. They have prototyped the mechanism in the context of the Squeak implementation of Smalltalk. Using traits, they refactored the Smalltalk collection classes achieving a 25% reduction in the number of method implementations and a 10% reduction in source code size [BSD03]. This early experience suggests that traits are a promising mechanism for factoring class hierarchies and supporting code reuse and may be useful for statically typed languages too. The main contribution of this paper is to present a typed calculus of traits that can serve as the foundation for integrating traits into a statically-typed object-oriented language such as JAVA [AG98] or Moby [FR99, FR03]. A trait is collection of named methods. In Smalltalk traits, these methods cannot directly reference instance variables; instead, they must be pure behavior. The methods defined in a tr ait are called the provided methods, while any methods that are referenced, but not provided, are called required methods. An important property of traits is that while they help structure the implementation of classes, they do not affect the inheritance hierarchy. Traits are formed by definition (i.e., listing a collection of method definitions) or by using one of several trait operations: Symmetric sum merges two disjoint traits to create a new trait. Override forms a new trait by layering additional methods over an existing trait. This operation is an asymmetric sum. When one of the new methods has the same name as a method in the original trait, the override operation replaces the original method. Alias creates a new trait by adding a new name for an existing method. Exclusion forms a new trait by removing a method from an existing trait. [Urrh!] Combining the alias and exclusion operations yields a renaming operation, although the renaming is shallow. The other important operation on traits is inheritance, the mechanism whereby traits are integrated with classes. This operation merges a class C, a trait, and additional fields and methods to form a new subclass of C. Often, the additional methods provide access to the newly added fields. The additional methods, plus the methods inherited from C, provide the required methods of the trait. An important aspect of traits is that the methods of a trait are only loosely coupled; they can be removed and replaced by other implementations. In this way traits are a lighter-weight mechanism than either multiple inheritance or mixins. grabbed from http://www.cs.uchicago.edu/research/publications/techreports/TR-2003-13 see also http://www.iam.unibe.ch/~schaerli/smalltalk/traits/traitsPrototype.htm Hope that it is something interesting for real Perl hackers who will make Perl 6 the best language ever. -Dmitry Dorofeev.
Re: Traits: to renew OO inheritance in a hacker style discussion
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 the method with Java interface. Plus, interface is only declaration, you must implement methods in each class which use interface. AFAIK (last touched Java 5 years ago) Look at example: While the purpose of this paper is not to argue the merits of traits per se (see [SDNB03, BSD03] for such arguments), it is helpful to understand the motivation for traits. In languages with single inheritance, such as Smalltalk, it is often the case that inheritance does not provide sufficient flexibility for structuring a class hierarchy. Consider the case of two classes in different subtrees of the inheritance hierarchy and assume that they both implement some common protocol. If this protocol is not implemented by a common superclass, then each class must provide its own implementation, which results in code duplication. On the other hand, if we lift the implementation of the protocol up to the common superclass, we pollute the interface of the superclass, which affects all of its subclasses. Furthermore, if the protocol is defined by building on methods defined in intermediate classes, we will have to add these methods to the common superclass as well. This problem resul ts from the dual nature of classes. Classes serve as both object generators and as superclasses. In the former case, the implementation of a class must be complete, whereas in the latter case the class implementation may have abstract methods that are implemented by a subclass. Traits provide a mechanism to separate these two aspects of classes and allow code to be reused across the class hierarchy. Multiple inheritance [Str94] and mixins [BC90, FKF98] represent two other attempts to solve this problem, but they both introduce semantic complexities and ambiguities (e.g., multiple copies of instance variables in the case of multiple inheritance, and problems with the order of method definition in the case of mixins) [SDNB03]. It is from link i provided in previous post. -Dmitry Dorofeev.
Re: Traits: to renew OO inheritance in a hacker style discussion
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 them to function as interfaces when the Role is "abstract", and we'd like them to function as Traits when you don't happen to specify any state attributes. But for hiding the delegation decision, you at least have to allow the amount of state that lets you remember the object you're delegating to. Of course, the Traits paper didn't go into traits with state, though it did mention it as a future research topic. We're just doing that future research for them. :-) Perfect ! 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 ? or should I read some docs on Roles to be smarter ? Thanks. -Dmitry By the way, we distinguish Traits from traits (which are compile-time properties applied by "is". To apply a Role we use "does". Larry
