OK, my original mail must have been unclear. Of course subclasses (or
whatever you want to call them) can override postMixInProperties(). But
you'd never have code like this:
var foo = dojo.widget.createWidget(...)
foo.postMixInProperties();
If we were programming in java or C++ then we would make
postMixInProperties() protected. There's no native javascript support
for that (also, btw, dojo.defineWidget() doesn't support private
variables) but the API doc would be a lot nicer if it didn't list
postMixInProperties() as though it were a method that widget users (as
opposed to widget writers) could use.
Adam L. Peller wrote:
ok, I'll bite... as long as we chain up, why can't we override these?
postMixInProperties seemed like a good place to do overrides, for
example. Or is there just a concern that people won't chain up?
On 10/27/06, Bill Keese <bill@xxxxxxxxxxxxxxx> wrote:
By the way, I found some good examples of protected methods (or to be
pedantic, methods that subclasses override but that users aren't
supposed to call):
postMixInProperties()
fillInTemplate()
postCreate()
onResized()
etc.
We can't very well start putting underscores in front of those method
names now. It would be nice if we had some way to notate their status
to the parser though, so those functions showed as a different color or
something.
_______________________________________________
dojo-contributors mailing list
dojo-contributors@xxxxxxxxxxxxxxx
http://dojotoolkit.org/mailman/listinfo/dojo-contributors
_______________________________________________
dojo-contributors mailing list
dojo-contributors@xxxxxxxxxxxxxxx
http://dojotoolkit.org/mailman/listinfo/dojo-contributors
