I understand that in many cases functions are irreplaceable (Doug), and I
also understand that in order to stay uniform in the way of working, we then
pass all parameters as functions, but this does nothing to lessen the amount
of code, or speed up it's execution.
I did a quick test here:
http://www.dynapi.f2s.com/dynapi/tcanvas/getWidthTestLarge.htm and the
average time to loop through 3000 x obj.getWidth() was 10% longer than
looping through 3000 x obj.w.
I have found when making widgets I'm gravitating back to the older way of
doing things, where you set your preferences using variables attached to the
widget, this means you can't change these dynamically during use, but most
often you don't need to.
That prevents widgets like the current list or label widget, where every
parameter is dynamically changeable, but the code becomes a lot longer, and
the widgets become so bloated (in the case of list) that they can't be used
in real-world situations.
I think people prefer less functionality, coupled with fast rendering and
reliable use.
There is no reason why a few rules can't be set, like saying in the list
widget only the content can be changed on the fly, while the border
thickness etc has to be defined at creation.
Or have one "update" function, so you can set several parameters, and then
call the "update" function to refresh the display. Currently each parameter
you change in the label widget rewrites the layer content.
> 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.
That's exactly the logic I'm starting to query, because all the properties
you add as a prototyped function, are also mirrored in the constructor,
where the default values are set.
If there are parameters that don't *need* to be changed dynamically, why
bother duplicating code that's already in the constructor, by putting it in
a prototyped function, simply to make your code look more object oriented,
while actually it takes more file-size, and executes slower (see above
test).
Anyway, that should be enough ranting on my part for this weekend :o)
Cheers,
Richard Bennett
[EMAIL PROTECTED]
www.richardinfo.com
(Everything running on, and ported to DynAPI2.53)
visit the DynAPI homepage (and FAQ) ::
http://dynapi.sourceforge.net/dynapi/index.php?menu=1
Browse (and search) the mailinglist here:
http://www.mail-archive.com/index.php3?hunt=dynapi
The basic memory footprint might not be increased
----- Original Message -----
From: "Tuomas Huhtanen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: 07 July, 2001 18:25
Subject: RE: [Dynapi-Help] Splitting the API
> 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
>
_______________________________________________
Dynapi-Help mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-help
