Ext.define() "config" inconsistency

Ext.define() "config" inconsistency

It seems something is wrong with such important part of new class system as "config" declaration.

1) Somewhere on forum was information about proper usage of "config" option in class definition.
"config" option in define() must be used only to create "new" config properties. If you define class which "extend" another class with properties already exists,you don't have to specify it in "config" section.
Something like:

But if you want to redefine "default" value for "config" property,then that do you need to do?
Hot to change only "url" or "baseParams" leaving rest of declaration intact?

I've heard about "deeply merge" functionality for "config" preprocessor,but it only work if "config" option declared in "define()"-it looks for "config" property to make it's work(invoke addConfig()).
So,if I define "loader" option directly,not enclosed in "config", it wouldn't be handled as "config" property, but as simple "field" member. That's not correct IMHO.

If you declare something as "config" property earlier, it's natural to expect it to be handled that way in derived class. So, "config" preprocessor must lookup already defined "config" properties,search them in new"extend" class definition and treat them as same type of property-execute deep merge,for example.
I mean,it's not become simple "field"-it declares default value for existent "config" property.
Now it's not work this way. To trigger preprocessor to see properties as "config" you must declare "config" option in define(), even though it maybe be already defined on level above as "config" property.

And even though, this strange construction work (who calls constructor(config) for base class and at which moment? I firmly believed, it's only for Ext.create('class', {config}) ), it's not equivalent for base and derived classes. Look that I mean:

simple baseParams becomes cryptic objectClass in derived class x2.
Strange, but loader=ComponentLoader understand it, and component loaded successfully with proper query parameters.
But it seems sometimes framework/third party component will not be such forgiving.Object!=objectClass anyway and can't be used interchangeably. I'm glad it worked for ComponentLoader,but changing object type silently is not the best practice IMHO.

Also, I'm talking not only about confusing practice for work with "config" properties, but about inconsistency in docs.
Where's generated getLoader()/setLoader() methods?
Why I need to declare property as "config" several times only to be recognized as "config" property,although it was already declared in "config" of base class. Even more, you say in one of posts that it's not required for derived classes to have "config" section when base class already declared needed properties. You define class one time and it must derive all properties from base class-logical.
But if you don't use trick presented here, you get simple property(overwrite/not merge effect) treatment from framework, not "config" property as you may expect.

only to give "loader" property "config" preprocessor recognition.
Is "title" not in the same category as "loader" config property anymore?
Why enclosing "config" and custom "constructor" is required only to get proper handling?
And not exactly correct,if you ask me,because "title" in example overwrite "title" as property-getTitle()/setTitle() is not available anymore,though panel work...partially,but "title" becomes simple(not "config") property. Strange things happens behind the scenes...principle of least surprise,where are you?

Even better, it seems most of "config" properties in framework does not have declared accessors,such as get*/set*,though docs says it must be auto generated for "config" properties.Look at "title" in panel.
So, until you explicitly define "config"(already declared for panel,for example) properties using method above,you will see simple property treatment even for documented "config" properties.
As it turns out "title" does not have getTitle()/setTitle() by default.

I haven't seen a guide or an example that uses (correct me if I walked over some) so we don't recommend it.

Here is the back story on the config object in Ext JS 4... when 4 was first being created we started working on this config system but to get Ext JS 4 out the door we couldn't implement it throughout the framework so none of our widgets support it so it's really just an application feature for Ext JS 4.

In Sencha Touch 2, the framework was really built around the config object and it works fantastically but the framework started off by using it.

Since we haven't fully implemented it throughout the framework for Ext JS 4, no class in Ext JS 4 executes this.

I'm not saying you can't use it, I use it in my own app utility classes but I wouldn't expect the Ext JS 4 classes to support it yet.

Every single article about new class system touch "config" subject somehow,starting from 2011.
But official documentation mixing and matching "property" and "config" freely,exchanging context-in one case it will be class definition in another place it's instance related.Very confusing.

OK,so according to new rules EVERYTHING related to class definition must be enclosed in "config"? Why "title" in first item not enclosed in "config"? It's not "config" property? It's somehow known "config" property? If I write "items" without wrapping it into "config",component stop working?
"config" property suddenly becomes "simple" instance property?
Why "config" preprocessor can't walk up the class hierarchy and determine what properties "config" and which not by itself?
Where's the logic? Why I must act that way and not the other?

Does I feel better about "Touch 2.0"? Maybe...but not so much.
I really appreciate all hard work you make,but all cornerstone disputable concepts must be defined upfront cleanly,not be afterthought consideration.

I'm not sure you have a strong grasp on what the config object really does in ST2. There is no logic of what is a config or what isn't. Properties in the config object get the getter and setter created so if there is code that uses getItems and you put items outside the config, that items array you are trying to use isn't part of what getItems returns. The items within the config get prefixed with an underscore so you have the items property you use and the _items that came from what was inside the config object likely in a superclass.