Re: protected methods

Inline.

On 10/27/06, Scott J. Miles <sjmiles@xxxxxxxxxxxxx> wrote:

>(also, btw, dojo.defineWidget() doesn't support private variables)

Actually, that's not really true either, as long as you define your private variables with accessor methods in your initializer (among other things).  I just double-checked, you use .apply at the end of _makeConstructor for the initializer.

Fwiw, there's nothing stopping you from writing code like this in an
initializer:

function() {
  var privateKey = "secretKey";
  var privateMatchKey = function(inKey) {
        return (inKey === privateKey);
  }
  this.matchKey = function(inKey) {
        return privateMatchKey(inKey);
  }
}

This is Crockford's solution, right?  I seem to remember that this solution has some of the same problems as some of the inherited references in dojo.declare (although I could be wrong about that, it's been a while).

I believe the correct idea is that prototype methods do not support
(so-called) private variables (usually expressed as closures on the
constructor).

Actually, that's not *quite* accurate.  Closures work just fine on a prototype object; it's just that that particular object will be the only one with access to those variables.   Of course, many times it's pointless to even try it, but it can be done (I did some of that way back when with f(m)).

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

One of the amazing things about _javascript_ is that you can model ideas from almost language.  However...that doesn't mean we always *should*. 

Most of the arguments going back and forth between the various factions of Dojo committers usually run along the lines of "don't layer things on top of JS that isn't really there" and "what I want is a version of Java (or at least Java-like constructs) within the browser".   The problem the former faction has with the latter isn't so much that you can't do that or think of things that way, it's that in the end it's not what JS is--and the code that gets produced eventually reflects that.  The widget system happens to be an excellent example of this.

However, that architectural approach does come at a price, and usually that price is performance, unfortunately.  I'm not going to suggest something like rewriting the widget system (although I think we *really* need to look at certain parts of it), but I will probably continue to argue against layering metaphors that aren't really accurate on top of what we are doing.  I've been arguing pretty hard offline with Owen, for instance, over the use of the term "Class" in the API docs (and probably this will get discussed at today's meeting), and the more we discuss things the more I'm becoming convinced that what we should probably do is throw out *all* of the metaphors and just describe things the way they actually *are*.  The best example of this I can think of off the top of my head would be:

http://dojotoolkit.org/api/#dojo.widget.Button

...the inheritance chain.  As I argued with Owen, I realized that we shouldn't call it that at all--it should be called the Prototype Chain, and the order of objects should be reversed, because *that's what it actually is*.

In other words, instead of layering development metaphors over things, we should just use the language in it's most natural state--and promote that usage as well, through good code and through education.

trt

_______________________________________________
dojo-contributors mailing list
dojo-contributors@xxxxxxxxxxxxxxx
http://dojotoolkit.org/mailman/listinfo/dojo-contributors