I'm not that concerned about the methods themselves. After all, they are
properties of the prototype object, hence not in the critical path of memory
usage. But then again, what if I know that I won't need those methods. I'm
absolutely sure that they are totally useless in my application. In that
kind of a situation I would be very pleased to see the code of that object
splitted in many different js files. Just include the files you need and you
have the objet you need. That's the beauty of javascript. You can manipulate
the object structures in the fly. And this modification for dynobject and
dynlayer would take less time than writing this mail. :)
Anyway, the properties that are assigned inside constructors are the pain
(in javascript generally). My opinion about "optimal" javascript object is a
such object, which gets pretty much all of its objects through the prototype
(dynamically of course :) and has only one or two instance variables.
Now back to real world.. ;)
Tuomas Huhtanen
> well, first off, If I write a widget that HAS to so some stuf _BEFORE_ it
> get's resized, then using MyWidget.w = 100 will break it.
> BUT I can overload the setWidth method to perform the nesseary tasks and
> THEN reside the widget.
> Just one example.
> Also using methods allows us to very easily implement all sorts of events.
>
> As for setWidth in specific:
> --code starts----
> this.w=(w==null)?this.w:w<0?0:w;
> if (this.w==null) return;
> if (this.css!=null) {
> if (is.ns4) this.css.clip.width = this.w;
> else {
> this.css.width = this.w;
> this.css.clip = 'rect(0px '+(this.w||0)+'px '+(this.h||0)+'px 0px)';
> }
> }
> if (noevt!=false) this.invokeEvent('resize');
> --code ends----
>
>
> None of this would be done with OBJ.w = 100.
> Using the setWidth method you can even inhibit the resize event (note the
> noevt param)
>
>
> ----- Original Message -----
> From: "Richard Bennett" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, July 07, 2001 1:45 AM
> Subject: Re: [Dynapi-Help] Splitting the API
>
>
> > Quite right,
> > I was also wondering why we need to prototype a method for simple
> variables.
> > I almost never use :
> > this.getWidth()
> > but simply :
> > this.w
> >
> > Why use this.getHTML(), when the value is stored in this.html already??
> >
> > I understand in cases where more has to be done than simply setting or
> > returning a value, but we have so many methods that do nothing more than
> > return a value, or set a value. Why is this needed, is it simply done to
> be
> > more object-oriented? In which case doesn't file-size and
> performance have
> > priority over conforming to an OO model?
> >
> > Richard.
> >
> >
> > ----- Original Message -----
> > From: "Tuomas Huhtanen" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: 07 July, 2001 10:33
> > Subject: RE: [Dynapi-Help] Splitting the API
> >
> >
> > > On thing to do is to try to save as much memory as possible. The
> tendency
> > > seems to be that if a variable can be used, it will be used. For
> example,
> > > the property isChild in dynobject is not needed at all. The
> information
> is
> > > already in the parent property. isChild==(parent!=null).
> > >
> > > The other thing to do is to try to save some code. Or to
> modularize it a
> > > bit. One thing that could be used more extensively, is the dynamic
> > extension
> > > of objects. The ideal situation could be of course that if
> you dont need
> > to
> > > support netscape, just leave the netscape module out.
> Currently all that
> > > kind of code is just inside if else loops in dynobject.
> > >
> > > Just a couple of ideas,
> > > Tuomas Huhtanen
> > >
> > >
> > > _______________________________________________
> > > Dynapi-Help mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.sourceforge.net/lists/listinfo/dynapi-help
> > >
> >
> >
> > _______________________________________________
> > Dynapi-Help mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/dynapi-help
>
>
> _______________________________________________
> Dynapi-Help mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/dynapi-help
_______________________________________________
Dynapi-Help mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-help
