Re: protected methods

Surprise surprise but I agree. :) 

Another really prevalent example of API design atrocity is every and any API that plays to the design of java swing. I hope I'm not insulting anyone on the list here, but if you've ever had to create large-ish applications using this api you'll dislike it very much. If you've ever done the same thing in non java swing api's you'll learn to pretty much hate swing. They got the cross platform part right but that's about where it ends. The biggest source of hatred for me personally is GridBagLayout and the lack of rendering hints. 

Despite all the flaws it still seems to find it's way into many frameworks. They keep getting the right idea about carrying over analogies that people can re-use existing knowledge for, but they are the wrong analogies. GWT is guilty of this doubly as they seem to drop the functional programming advantages js offers AND make you create swing code at the same time. Lovely. I refuse to believe any of the plexers here are part of the same group there, but if they are please accept my apologies beforehand. (even if they are sort of meaningless after the bashing just gone through ;) )

So, saying classes and methods sounds innocent enough on the surface - but they really aren't the same as objects and functions. Objects seem more appropriate because of the fact that you can't actually create a native type in the language unless you modify the browser you are working in first. Maybe when they allow pre-compiled ~things~ to be installed somehow it will work, but I'm guessing even supporting the upcoming js2 class analogies will be a tough feat of programming to accomplish in the existing vm without either a more robust runtime to use or more pre-compilation steps.

On 10/27/06, Tom Trenka <ttrenka@xxxxxxxxx> wrote:

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

-- 
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer

Open source based consulting work centered around dojo/tapestry/tacos/hivemind. 
http://blog.opencomponentry.com
_______________________________________________
dojo-contributors mailing list
dojo-contributors@xxxxxxxxxxxxxxx
http://dojotoolkit.org/mailman/listinfo/dojo-contributors