"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]/
