Other Inheritance - Android Developers documentation

[LucaMs]

Android Developers documentation:

Known direct subclasses: ... TextView...

but if you click on TextView:

Shouldn't it be shown like:

Java.lang.Object
    ... Object.View
        ...View.TextView

Anyway, I'm thinking if it suits me and how to implement such a thing without having inheritance, i.e. using objects.

For example:

clsMan
... clsWorker
... ... clsEmployee
... ... ... clsManager

Will it be useful (and difficult) to use objects instead of classes? Will using objects involve duplicating many methods?

P.S. ["Playing around"]

Um... to create a new Manager I have to create before all its "parent objects"!
First a Man, then a Worker, then an Employee and only after this long list of actions I can create a Manager!

    Dim Man As clsMan
    Dim Worker As clsWorker
    Dim Employee As clsEmployee
    Dim Manager As clsManager

    Man.Initialize("Erel")
    Worker.Initialize(Man)
    Employee.Initialize(Worker)
    Manager.Initialize(Employee)

    Log(Manager.Name)

And to get (log) the name of the Manager? clsManager could have a property:

Public Sub getName As String
    Return mEmployee.Name
End Sub

but this would imply having to have a similar property in clsEmployee:

Public Sub getName As String
    Return mWorker.Name
End Sub

and so on. Or clsManager should have an instance of all its parent objects, objEmployee, objWorker, objMan.

What a headache ?

EDIT: no, this is "enough", in clsManager, to get its name:

Public Sub getName As String
    Return mEmployee.Worker.Man.Name
End Sub

[Attached a test but B4J, sorry]

 

[Erel]

Or clsManager should have an instance of all its parent objects, objEmployee, objWorker, objMan.

Yes. This is composition pattern.

 

[LucaMs]

It is hard to think about composition rather than inheritance, for example in the case under consideration.

Thinking that a Manager is an Employee, who in turn is a Worker, who in turn is a Man, is logical.

Composing a Manager with Employee, Worker and Man objects is a much less intuitive concept ?

 

[agraham]

Composing a Manager with Employee, Worker and Man objects is a much less intuitive concept

Yes, you are correct. Your example is a classic example of where inheritance works very well because
A Something IS A more specialized Other Thing

On the other hand there are cases where composition works better. For example
A Car HAS A Steering Wheel.

A language like C# can support both. It is a pity that, possibly for historical reasons. B4X only supports composition. But, just maybe Erel is working on this - I'm sure that if he can implement Resumable Subs that return values then adding class inheritance would be a walk in the park! ?

 

[agraham]

Shouldn't it be shown like:

Java.lang.Object
... Object.View
...View.TextView

No. Subject to correction of my understanding by some higher being In some languages, like C#, the name of the class is logically composed of those of its super classes. In Java however class naming does not need to follow the class hierarchy. A bit puzzling I admit but I assume it was a design decision that has some merit that is not obvious to us lower instances of pond life.

 

[agraham]

some higher being ... us lower instances of pond life.

In case you missed it this was an attempt at a joke about class inheritance but I just realised that there is a serious point that can be made. Evolutionary changes are probably a third pattern that cannot easily be expressed by either composition or inheritance.

PS : I've obviously got my philosopher hat on today!

 

[LucaMs]

B4X only supports composition. But, just maybe Erel is working on this

No, Erel asserted that Inheritance will never be implemented.

Furthermore, reading these days a little here and there, many opinions assert that composition is better and can also be used in cases like that, where an object "is a..." (but I still haven't assimilated/digested this ?)

 

[agraham]

Erel asserted that Inheritance will never be implemented.

If so i missed that, which is a pity

The trouble I find with using composition where inheritance would be more obvious is that it causes code bloat in that you need to re-implement all the required properties in the new class. Alternatively you can make the superclass objects Public themselves and access them directly but this ruins the encapsulation of the class properties and requires an understanding of the composition of the object.

As an old school low-level programmer it took me a long time to get to grips with the possibilities offered by inheritance and, because I am tainted by ingrained practices of the past, although I don't use it as often and as intuitively as, say, Erel does in his Java and C# code I do miss it when its possible use is obvious to me.

 

[JordiCP]

Tested it for curiosity... in fact, class inheritance is there, hidden in the Java translation of the project.

There is the #Extends keyword, which only appears as IDE's context help in Activities and Services, but if you add it to a class, magic (dirty magic) happens
Not sure if it's been left there to be useful in some cases, or simply "is there" and can be removed one day.

Assume your package name is com.myapp.b4a

This is our simple parent class
[CODE lang="b4x" title="parentClass.bas"]Sub Class_Globals
Public afield As Int
End Sub

'Initializes the object. You can add parameters to this method if needed.
Public Sub Initialize
afield = 10
Log("parent initialize")
End Sub

Public Sub sayhello
Do While True
Log("Hello "&afield)
afield = afield +1
Sleep(1000)
Loop
End Sub
[/CODE]


We define a childClass, in which, only by mentioning that it extends parentClass, can access it as own methods (except for initialization, which needs an inline Java workaround)
[CODE lang="b4x" title="childClass.bas"]
'Note it is all lower-case
#Extends: com.myapp.b4a.parentclass

Public Sub Initialize( container As Panel )
' Before anything else
Dim JO as JavaObject = Me
JO.RunMethod("initSuper", Null)
' ...
Log($"Parent's field is ${JO.GetField("_afield")}"$) '<- belongs to the parent's class
JO.RunMethod("_sayhello", Array(Me)) '<- calling method of the paren'ts class.
End Sub

#If JAVA
public void initSuper(){
try{
com.myapp.b4a.parentclass mySuper = (com.myapp.b4a.parentclass) this;
mySuper._initialize(this, ba);
}
catch(Exception e){
BA.Log("Oops! Could not init super class");
}
}
#End If
[/CODE]


Of course it is not practical at all (but interesting, at least for me), since parent's class fields/methods have no direct support from B4A code, but only via JavaObject / inline Java, as if they also belonged to (in fact they are part of) to the child class.