None of my posts from 12 hours ago got through, so I'm reposting them:
Hi all, I just noticed Eytan's widget spec proposal is on the site: http://dynapi.sourceforge.net/doccenter/index.php?EytansWidgetSpec I had hoped a widget-spec would clear up confusion around the different existing models, and simplify existing code in use, by dropping things like getSubClass() if we never actually used them. This spec doesn't. But I should add that I don't know enough about OO programming to judge if the proposal could be beneficial, or add more confusion than benefit. As I see it, we currently have: 1) DynObject. 2) this is inherited by DynDocument, and DynLayer. 3) When we make a widget, we inherit from Dynlayer. 4) Complex widgets could inherit from a widget, subclassed off DynLayer. the proposal specs suggest putting a TWidget class between step 2 and 3. It seems it would be a wrapper for non-graphical widgets... So does TWidget actually replace step step 2? Is the idea that we create a non-graphical canvas to build widgets like glide.js, or pathanim.js?? And, for graphical widgets we would have TComponent, which *contains* a dynlayer, without inheriting all it's properties, *but* inherits all properties from TWidget, which are basically those of Dynlayer, with a classname added. I see Tcomponent looks quite useful, with it's added functionality, but it's just a widget isn't it? what's the difference between ButtonImage inheriting from Dynimage, that inherits from dynlayer. Or ButtonImage inheriting from Dynimage, that inherits from TComponent inheriting from TWidget, that inherits from dynLayer (or not?), which inherits from DynObject. As you see I am more than a little confused about the logic behind this, I hope it's for performance reasons, and not to build an object model that closely resembles that of another language. I see the same thing popping up in Dan's new code, where Java syntax is being implemented, seemingly for the simple reason that the author feels most at home with this syntax. In my opinion, the only object model we should be closing in on, in our structure and naming, is DOM2. (note I'm not saying DOM is a language or anything) But as I said at the start, I am not very well versed in other OO oriented languages, so I might be missing the advantages. Personally, what I thought a widget spec proposal might look like, would be a collection of syntactical rules - like a naming convention. For instance a few ideas: * The constructor is always made using the function system: function myWidget(){ } Not using " myWidget= new Object() ", or " myWidget=[ ] ", or anything. * To subclass, we use the name of what we're subclassing off, so: this.dynlayer=Dynlayer this.dynlmage=DynImage Not, this.superclass=Dynlayer. * eventlisteners are placed inside the constructor, not as seperate functions (or not?) * functions are prototyped onto the widget, not built inside the constructor, and not using the " : " syntax. Just some ideas... Also one newbee question, is inheriting, and subclassing synonymous in this context? That should be enough to get the ball rolling :o) Cheers, Richard. _______________________________________________ Dynapi-Dev mailing list [EMAIL PROTECTED] http://www.mail-archive.com/[email protected]/
