PDA

View Full Version : Extending private methods



8 Apr 2014, 12:09 PM
Should the following use case cause an exception? (it doesn't today)




Ext.define('Test.view.Panel1', {
extend : 'Ext.Panel',

xtype : 'somepanel',

privates : {
sayHi : function() {
console.log('Say hi is private!');
}
}
});

Ext.define('Test.view.Panel2', {
extend : 'Test.view.Panel1',

privates : {
sayHi : function() {
console.log('Should throw an exception!')
}
}
});

LesJ
8 Apr 2014, 1:02 PM
Privates makes no difference in this example. Both methods are public.

Ext.define('MyClass', {
sayPublic: function () {
console.log('public!');
},


privates : {
sayPrivate : function() {
console.log('private');
}
}
});


var obj = new MyClass();


obj.sayPublic();
obj.sayPrivate();

8 Apr 2014, 1:11 PM
Jsript (lowest common denominator) has no privates truly. Have you read the guides?

LesJ
8 Apr 2014, 1:19 PM
Using the Ext JS class system is possible to create private methods.

The "What's new" document doesn't state if this was a goal or not.

http://docs.sencha.com/extjs/5.0.0/whats_new/5.0/whats_new.html

skirtle
8 Apr 2014, 1:35 PM
From what I read in that guide, the intention of privates is simply to prevent accidental overrides, it has nothing to do with invocation visibility (how would that even be possible?).

Overriding privates using other privates is explicitly mentioned as supported:


If this is intentional, you simple wrap the function in “privates” like Ext.Component.

evant
8 Apr 2014, 1:41 PM
@skirtle is correct. It's to prevent you from accidentally overriding private methods that we'll introduce in versions that may conflict with your own.

8 Apr 2014, 1:52 PM
Indeed. My main question still stands ;)

evant
8 Apr 2014, 2:02 PM
We've never prevented you from overriding privates. If you want to, go for it (at your own risk).

To do it correctly we'd need to do it library-wide, which we haven't done. It's something we'll work on over time.

8 Apr 2014, 2:30 PM
OK.

superstructor
9 Apr 2014, 3:03 AM
It is my experience that sometimes you have no option except to override privates; e.g. a bug in the framework until a fix is released, or something that just can't be made to work the way you need it to any other way. It should be avoided at all costs, but should not throw an exception as that would give you no way to solve some issues. Maybe a warning in the log is still worthy of considering ?

9 Apr 2014, 3:06 AM
During a meetup yesterday, the question was asked "why privates? Why not finals?" He has a good point.

9 Apr 2014, 3:09 AM
It is my experience that sometimes you have no option except to override privates; e.g. a bug in the framework until a fix is released, or something that just can't be made to work the way you need it to any other way. It should be avoided at all costs, but should not throw an exception as that would give you no way to solve some issues. Maybe a warning in the log is still worthy of considering ?

+1

dongryphon
9 Apr 2014, 2:00 PM
@Jay / @superstructor -

This code:




Ext.define('Test.view.Panel1', {
extend : 'Ext.Panel',

xtype : 'somepanel',

privates : {
sayHi : function() {
console.log('Say hi is private!');
}
}
});

Ext.define('Test.view.Panel2', {
extend : 'Test.view.Panel1',

privates : {
sayHi : function() {
console.log('Hello from private override');
}
}
});


Will not throw an exception because the derived class is requesting "override of private method" privilege. This is the intended result. So it does prevent override of private methods as that is still necessary (/cc @superstructor).

As @skirtle and @evant pointed out the only objective with privates is to help detect (not prevent) overriding framework private methods. Obviously we need to override those methods internally as well, which is why...

The finals concept was considered (briefly) and discarded. It would also fly in the face of patchability via overrides.

skirtle
10 Apr 2014, 3:09 AM
I may have misunderstood but I believe Jay was asking why are they called privates rather than finals, with no suggestion of changing the actual behaviour. The name privates has connotations around where they can be invoked, not just how they are overridden. The term finals is arguably a closer match to how other languages use these terms.

LesJ
10 Apr 2014, 3:48 AM
Can we have private static methods? :D

brian428
10 Apr 2014, 4:35 AM
The term finals is arguably a closer match to how other languages use these terms. Hmm...not really, at least not in Java. A final method means it can't be overridden at all. I suppose they could have named the wrapping object something like "internal:", but I'm not sure it really matters that much. It's probably too widespread of a change to mass-replace the name at this point. It really should only affect developers who actually want to override a private method from a superclass, and I'd think if someone is at that point, they understand what is going on.

skirtle
10 Apr 2014, 7:51 AM
Hmm...not really, at least not in Java. A final method means it can't be overridden at all.

I would suggest that if you carefully consider the effects of the keywords private and final on methods in Java, the ExtJS behaviour is much more closely aligned with final. Sure, the ExtJS version lets you sudo round it, but it's much closer. In practical terms it isn't really comparable to private at all, though the intent may be similar.

However, this is all a bit academic because, as you say:


It's probably too widespread of a change to mass-replace the name at this point.

brian428
10 Apr 2014, 7:59 AM
I would suggest that if you carefully consider the effects of the keywords private and final on methods in Java, the ExtJS behaviour is much more closely aligned with final. In practical terms it isn't really comparable to private at all, though the intent may be similar.

That's why I mentioned a name like "internal:", to avoid any terminology baggage. Really, neither final nor private are very close to what these are. The Java "protected" modifier is probably the closest, conceptually. (Since the intent is for subclasses to be able to override these if necessary).

dongryphon
10 Apr 2014, 8:47 AM
The final concept as pointed out is not right because such languages that support it don't allow any overrides. With privates we do... but only internal to the framework. Once you cross over that line they are similar to final so I can see the confusion there. It is clearer from the internal perspective because we do have many methods that are intended to be overridden by derived classes just not end-user classes. Such methods will also align with "private" in doc terms.