On 5/27/2011 2:54 PM, Jacob Carlborg wrote:
Hi Jacob,
See some of the source code shown here. I did not code them, but can
sense the pattern is not too productive brain cycle invested.
Cycle= trying to locate up the tree of inherited object.
BTW, default D documentation is Not too friendly for inheritance tree
navigation. Unlike in java.
Not to promote deep inheritance tree. I actually like to flatten them
using interface template and adaptor pattern. Memory usage and object
tree creation clock cycle is smaller.
With overloading and also runtime dynamic method invocation, it makes
http://hg.dsource.org/projects/dwt2/file/d00e8db0a568/base/src/java/io/ByteArrayInputStream.d
How big is this problem in practice, how often do need overload (NOT
override) a method in the subclass that exists in the super class?
Actually, the argument of reason of using alias is to prevent hijacking
as mentioned by others in the URL.
Overloading is actually more frequent than overriding base on data
modeling because of polymorphic nature of the OOP concept. I can see no
point of doing various naming for a single calculation. Yes, it can be
done with various different name, Google Go does NOT have overloading.
ie:
// Please note, the internal logics of such methods may or may be the
same, because of dependent of business logic. Hence, functional template
might not be needed.
class RiskAccessment{
double calculate(NormalAccount acc, double intrest){...}
double calculate(CurrentAccount acc, double intrest){...}
double calculate(FixedDeposit acc, double intrest){...}
double calculate(FixedIncome acc, double intrest){...}
double calculate(Equity acc, double intrest){...}
double calculate(FixedAssets acc, double intrest){...}
}
and many other such patterns.
Overriding is for entirely different thing. Hence, I suggested the 2 new
keywords solutions.
--
Matthew Ong
email: [email protected]
