[CLOSED]Ext.AbstractComponent mixins

[gevik]

If I understood this correctly, mixins can be used to dynamically add(remove?) functionality to existing classes. They provide a notion of multiple inheritance and make overriding a step easier etc..

Regarding the Ext.AbstractComponent mixins: It seems a bit odd to have the Ext.util.Observable as a mixin since all the derived components from Ext.AbstractComponent statically implement events and event handlers.

Is there a particular reason why the Ext.util.Observable is used as a mixin? Shouldn't Ext.AbstractComponent extend from Ext.util.Observable instead?

[renku]

all the derived components from Ext.AbstractComponent staticallyimplement events and event handlers.

What do you mean by "statically implementing"?

As I see things, only the Ext.util.Observable implements the event handling functionality. The derived classes of Ext.AbstractComponent only use that functionality.

For the derived classes of Ext.AbstractComponent it doesn't really make any difference whether the event handling methods come from parent or mixin.

As for mixin v/s parent it's more of a matter of style. (With the notable difference that this.callParent() doesn't work for mixins.) IMHO Observable is the kind of thing that you might want to mix into classes that already have a parent class. And if you are going to use Observable in one place as a mixin, then why not opt for consistency and use it everywhere as a mixin.

[gevik]

>> For the derived classes of Ext.AbstractComponent it doesn't really
>> make any difference whether the event handling methods come from parent or mixin.

This is true but if we where introduced with new inheritance concepts in Ext4, at least we should use them properly. Imagine what would happen when you remove the Obervable mixin from the AbstractComponent. Then entire event functionality will be removed.

>> As for mixin v/s parent it's more of a matter of style. IMHO Observable
>> is the kind of thing that you might want to >> mix into classes that
>> already have a parent class. And if you are going to use Observable in
>> one place as a mixin, then why not opt for consistency and use it
>> everywhere as a mixin

Exactly for this reason AbstractComponent should inherit from Observable since it is the "ultimate" base class for all components.

[renku]

Imagine what would happen when you remove the Obervable mixin from the AbstractComponent.

The same that would happen if you remove the parent class? There is no way to dynamically add or remove mixins. For that kind of thing plugins are much more appropriate.

[TommyMaintz]

You shouldn't be removing the Observable mixin from Component. If you do, then you have to expect events not to be working anymore. Like renku said, if we want to be able to mixin observable behavior into a class that extends another class, then we should consistently use it as a mixin throughout the framework.

[gevik]

Guys, don't get me wrong. I do not want to remove the observable functionality. That was just an example.

All I want to point out is this:
Because Ext.AbstractComponent does not inherit from any other class, there is no reason why it uses the Observable as a mixin. It should inherit from Observable and use it accordingly.

my 2 cents....