The problem with this behavior is that if I try to override a constructor to provide custom functionality or fix a bug, the overridden constructor with the undesired code is getting called too, thus giving unexpected results...

I don't want to call the overriden Ext.data.Store constructor, in fact, I expect it to not be called.

The problem is that, now in the 4.1 branch, with the changes made to the callParent function code, the this.callParent() is calling the overriden constructor and I expect it not to do so, instead I expect it to call the Ext.data.AbstractStore constructor...

Yes, this was changed as part of the Ext.define/override functionality. I will add it to the API changes page. If you haven't seen this yet, you might find it useful:

PHP Code:

Ext.define('My.patch.Store', {
override: 'Ext.data.Store',

constructor: function () {
}
});

The override can then be "required" and dynamically loaded or brought into an optimized build. If an override is required (say 'My.patch.*'), it won't actually be used unless the target class is also used.

From a design perspective, overrides in 4.1 are almost like partial classes and will allow a single class to be implemented in multiple, independent pieces (rather than the problematic approach of "AbstractFoo" and "Foo" classes).

I only use overrides to patch bugs. It's pretty common to need to skip the buggy overridden method in such circumstances. Personally I always used the 'old-school' prototype approach when I was doing this anyway, relying on the callParent() magic always struck me as a bit risky when I'm subverting a class's original methods.

From a design perspective, overrides in 4.1 are almost like partial classes and will allow a single class to be implemented in multiple, independent pieces (rather than the problematic approach of "AbstractFoo" and "Foo" classes).

Is this need very common in your overrides?

Don, hi!

I use the "AbstractFoo" and "Foo" approach. Can you explain (in more detail) why this approach is problematic and how I could use overrides in 4.1?

Also, does it mean that classes such as AbstractComponent or AbstractContainer will be eliminated?

I still don't understand why for example there is the AbstractComponent class... why not fold its content into the Component class?

I believe AbstractComponent and AbstractContainer exist so that the code can be shared with Sencha Touch.

If I've understood what Don said correctly, I believe these classes will disappear because the new style of overrides allow this code to be reused without the need for the abstract classes. They are still there in 4.1-pr1 though.

The AbstractFoo/Foo approach can still be valid in many cases, don't get me wrong. Inheritance is still a Good Thing.

AbstractElement/Element and AbstractComponent/Component, however, were really "artifacts of implementation" where we were trying to share code between Touch and Ext JS. An app should never create an AbstractElement or AbstractComponent and really nothing other than Element or Component should even derive from them. This is not really what inheritance is all about, but it was the only tool at hand at the time. The problem is that this rippled through everything, including the docs, forcing these details to be in front of everyone.

It is possible that we will fold such things together in the future and maintain aliases for the old names. If we did this, the AbstractElement class would be renamed to Element and the current Element class would become an override.