overriding / callParent behavior change (bug?)

[maksimenko]

Hello there,

When overriding a constructor in ExtJS 4.1, the overridden constructor gets called when this.callParent() (instead of on this.callOverriden()) is used on the new function.

Ext.override(Ext.data.Store, {
     constructor: function () {
           ...... 
           this.callParent(); // this calls the overridden Ext.data.Store constructor instead of the Ext.data.AbstractStore constructor
           ....
     }
});

Is this an intentional behavior change or an unnoticed bug?

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...

Let me know if you need more info

[mitchellsimoens]

Have you tried callOverridden()?

[maksimenko]

Hello Mitchell,

Maybe I didn't explain myself correctly.

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...

Hope I explained myself better this time,

[dongryphon]

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:

    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).

Is this need very common in your overrides?

To bypass the original method, in 4.1, you have to go old-school:

    constructor: function () {
        ... 
        Ext.data.AbstractStore.prototype.constructor.call(this);
        ...
    } 

[skirtle]

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.

[LesJ]

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?

[skirtle]

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.

[mitchellsimoens]

Abstract classes are still a good idea IMO... Creating your own components sometimes you can just extend the abstract to accomplish what you need.

[maksimenko]

Hello Don,

Thanks for your response.

As skirtle do, I mostly use overrides to patch bugs, so, in those cases I'd like the overridden method not to be called.

I've a few overrides in 4.0 and now I had to do a few for 4.1 so I could test the app ( and I've seen great perf. improvements in every browser... but still couldn't test on IE6 with a surface error )

Anyway, now I understand the reasoning behind the change. And the workaround of using the old school way of calling the superclass method works fine, so it's OK.

Thanks again for your response

[dongryphon]

@LesJ,

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.