Right, shorter, ok. So that saves us a few bytes on downloads, at the
cost of easy to manage documentation, and slightly more cluttered code?
Is there any additional penalty besides larger file and verbose code?
For instance, will having longer names slow down the JavaScript engines
on browers? The transfer of extra bytes are probably negligible in
comparison to all the images that are likely to be transferred, and
would probably barely add up to a single image in most cases. If
someone used many or most (up to all) available DynAPI code, how much
bigger might we be talking? MB bigger? Percentage bigger than using
the same options with the shorthand "p."?
Leif
----- Original Message -----
From: "Raymond Irving" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 10, 2004 11:42 AM
Subject: Re: [Dynapi-Dev] Suggestions
>
> "p." is much shorter than "classname.prototype."
>
> I think it was more for saving space than anything
>
> On another note:
>
> Can I now update CVS with the copy that I have? Did
> you download and test the code from
> www.xwisdomhtml.com?
>
>
> __
> Raymond Irving
>
>
> --- Leif W <[EMAIL PROTECTED]> wrote:
> > What was the basis of the original decision to use
> > "p" instead of the
> > "standard" way? Was it for performance? Was it
> > before there was a
> > standard? If it's for performance, it might not be
> > good to change it in
> > the release code. But could development code be
> > written in standard
> > format, then be converted to use "p" everywhere for
> > production via some
> > util? Would it bee too insane to approach it this
> > way? Is there a
> > better way?
> >
> > Leif
> >
> > ----- Original Message -----
> > From: "Doug Melvin" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, June 10, 2004 10:58 AM
> > Subject: Re: [Dynapi-Dev] Suggestions
> >
> >
> > > YEs! let's get a cvs update!
> > > There have been a few fizes as of late.
> > >
> > > As for the prototyping, switching it over to the
> > "standard" way would
> > now be
> > > too difficult..
> > > (i don't think) I could dedicate myself to that
> > conversion, but
> > someone will
> > > have to commit it
> > > (i have been trying to get sourceforge to sent me
> > my damned password
> > for 3
> > > years now, maybe it's fixed now?)
> > >
> > > cheers
> > > ----- Original Message -----
> > > From: "Peter Romianowski" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Thursday, June 10, 2004 10:12 AM
> > > Subject: Re: [Dynapi-Dev] Suggestions
> > >
> > >
> > > > Hi,
> > > >
> > > > just some short comments on JsDoc.
> > > > I am using JsDoc for quite a while now and it
> > works well for me. But
> > using
> > > it for the (current)
> > > > dynapi codebase brings a lot of problems because
> > of the way dynapi
> > handles
> > > to definition of classes.
> > > > JsDoc only "accepts" classes (prototypes)
> > written the "standard"
> > way:
> > > >
> > > > function MyClass() {
> > > > }
> > > >
> > > > // Superclasses must be defined like this
> > > > MyClass.prototype = new MySuperClass();
> > > >
> > > > // Methods like this:
> > > > MyClass.prototype.myFunction=function() {
> > > > }
> > > >
> > > > The "dynapi way" is this:
> > > >
> > > > function MyDynapiClass() {
> > > > // Inheritance (I think JsDoc recognizes
> > this too)
> > > > this.MyDynapiSuperClass=MyDynapiSuperClass;
> > > > this.MyDynapiSuperClass();
> > > > }
> > > >
> > > > var p = dynapi.setPrototype ('MyDynapiClass',
> > 'MyDynapiSuperClass');
> > > >
> > > > p.myFunction=function() {
> > > > }
> > > >
> > > > The problem is that methods are declared using
> > the "p-variable".
> > This way
> > > JsDoc does not regocnize
> > > > the class-methods. One would have to patch JsDoc
> > or rewrite the
> > dynapi...
> > > >
> > > > Generelly I really like the idea of using JsDoc
> > (I use it ;) This
> > leads to
> > > much cleaner code and helps
> > > > a lot understanding the code (because it
> > includes comments then).
> > > >
> > > > >> Of course, you still have
> > > > >> to comment your code at some level, which
> > takes time, energy and
> > > > >> discipline. :p
> > > >
> > > > But it buys you a lot! I remember the pain I had
> > understanding the
> > dynapi
> > > completely. There are concepts
> > > > (the "old" Stylemanager, SODA) that are really
> > not so easy to
> > understand
> > > in the first place. Missing documentation
> > > > makes it even harder.
> > > >
> > > > As soon as the "new" DynAPI 3.0 is in CVS I
> > really would like to
> > > contribute some of my extension and help out
> > > > in documentation. Perhaps(!) I will have a
> > deeper look into JsDoc to
> > > extend it. The idea of a Java-based
> > > > javascript-javadoc is great. If someone has the
> > time starting such a
> > > project I would be a happy contributer
> > > > to it! ;) Perhaps looking at Rhino
> > (http://www.mozilla.org/rhino/)
> > or
> > > another Java-based JS-Interpretor could
> > > > help here...
> > > >
> > > > Just my 2 cents,
> > > >
> > > > Peter
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Rob Butler wrote:
> > > >
> > > > > Hey Leif,
> > > > >
> > > > > Nice to (virtually) meet you.
> > > > >
> > > > > I don't think that JSdoc will parse / JavaDoc
> > anything but
> > Javascript at
> > > this point. But similar tools could possibly be
> > built for those other
> > > languages. Other people who use those languages
> > all the time may
> > already
> > > have done that. But if we at least get the Dynapi
> > Javascript code
> > Javadoc'd
> > > that would be a good thing, since it's the lion's
> > share of the code,
> > and
> > > what people are going to use the most.
> > > > >
> > > > > JSdoc uses a Perl templating framework, so if
> > need be the
> > templates
> > > could be modified to perform custom output / html
> > generation. I would
> > say
> > > to use them as they are initially and modify the
> > templates later as
> > Dynapi
> > > needs. The JSdoc tool seems to build a collection
> > of object tree
> > structures
> > > that contain all the information about the code.
> > Then the collection
> > of
> > > object tree structures are used in the templates
> > to generate the HTML.
> > This
> > > is great because after the parsing stage all the
> > collected info is
> > available
> > > for use in any way you want during the html
> > generation stage in the
> > > templates.
> > > > >
> > > > > If JSdoc were re-done in Java (again
> > preferably as an ant task) I
> > would
> > > suggest using either Velocity or Freemarker as a
> > templating framework
> > to do
> > > the same thing as the Perl templating framework.
> > The "port" to Java
> > could
> > > probably be done in a few parts & stages. One
> > part would work on
> > getting a
> > > Java version of the parsing system that builds the
> > collection of tree
> >
> === message truncated ===
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> From Windows to Linux, servers to mobile, InstallShield X is the
> one installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Dynapi-Dev mailing list
> [EMAIL PROTECTED]
> http://www.mail-archive.com/[EMAIL PROTECTED]/
>
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the
one installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://www.mail-archive.com/[EMAIL PROTECTED]/
