> -----Original Message-----
> From: Ara Abrahamian [mailto:[EMAIL PROTECTED]]
> Sent: 22. februar 2002 17:28
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: [Xdoclet-devel] xjavadoc optimisation+API essay
>
>
> > > Assuming that 80% of templates will generate new classes instead of
> > > mutating an existing class we can definitely make it faster by not
> > > instantiating jjtree AST objects. The best solution would be a
> runtime
> >
> > I'm not following here. What kind of templates would want to *modify*
> > existing sources?
> > -Or more specifically: esisting sources' javadocs (cause that's the
> only
> > thing you can
> > modify with xjavadoc).
>
> We don't have such templates currently, but what stops us from letting
> user do that? I mean write a template which generates equals() methods
> from persistent fields and generates that method into the same class,
> not a new one, not a derived one. Or you could go the reverse path, you
> have a web.xml file, now you want to run a chunk of web_xml.j and add
> ejb-refs to that already built file. Quite handy for web.xml/etc which
> are easy to create for the first time and mostly are composed of merge
> files of welcomefile/security/its instead of dramatically dynamic
> content like ejb-jar.xml. The xdocletgui also modifies files.
>
> > One grammar, two parsers.
>
> OK! But switchable in runtime.
>
> > > Flyweight is the way to go. I implemented a simple form of it with
> the
> > > XJavaDoc.getXClass method, so all parameters/return-types/classes
> are
> > > lazy loaded and the XClass pointer is null until it's accessed
> actually.
> >
> > The flyweight pattern has nothing to do with lazy loading. It's about
> > storing
> > extrinsic state as lightweight members (ints) and passing that state
> to a
> > shared
> > object before accessing it. See
> > http://www.enteract.com/%7Ebradapp/javapats.html#Flyweight
>
> "Use sharing to support large numbers of fine-grained objects
> efficiently." From GOF book.
>
> So we share primitives/classes/etc and we also lazy load/instantiate
> them.
>
No! That's not the same as flyweight! We'll (I'll) make a flyweight out of
the
ParameterImpl class. There will be only a few shared instance in the VM. The
number
of shared instances will be equal to the method with most parameters. -So
what about the
internal state (type, name, dimension)? It's set by MethodImpl inside the
parameters()
method before returning the array.
> > XJavaDoc.getXClass(String,boolean) with true is ProxyClass. This means
> > that
> > when you do a
> > superclass() on a class, you'll get an instance of ProxyClass. You can
> > call
> > qualifiedName()
> > on that instance without anything happening, but if you try to call
> any
> > other method, the ProxyClass
> > will ask for the real instance (the subject) by calling
> > XJavaDoc.getXClass(String,boolean) with false.
>
> Amazing.
>
Yes it is. Thanks to Gof. I remember 4 years ago when I read it. I tried to
stuff all the patterns in the book into the application I was building and
ended up with an over-architected application with too many classes, which
was unmaintainable. Now I've realised that patterns are only good when you
really need them.
> > This mix of lazy loading and proxy is quite efficient, but not enough.
>
> Jjtree is guilty here, and ... we just started optimizing it recently.
>
> > I guess what you're talking about is to lazy-instantiate the Xxxx[]
> > arrays.
> > That can be done too.
>
> Lazyloading everything possible. Currently we lazy load XClasses, right?
> But when we load/scan it, we create all XMethod/XConstructor/Xetc object
> too except again XClass refs of parameter types/etc which are lazy
> loaded, but XMethod objects are created for all methods of the XClass. I
> argue in most cases you just want to first check if a class derives from
> class x and has class level @tag y and then move on working on that
> class and maybe (maybe) methods of that classes. Fairly reasonable
> argument imho. Take a look at our own SubTask-derived classes, We check
> if ofType="EntityBean" and havingClassTag="ejb:bean" and then bother to
> process that class. Even further than not instantiating XMethod objects
> is stop parsing that class by checking ofType/havingClassTag!! So just
> quit parsing the whole compilation unit if it doesn't implement
> EntityBean! But that's the extreme :o)
>
Agree!
> > True. XJavaDoc should only be instantiated with setDir, _not_ with
> > setFiles.
> > If dir is known, we can load classes on demand.
>
> You're absolutely right, that's why I killed dirscanner's use in
> XJavaDoc altogether.
>
Smart! This avoids misuse.
> > Good, so we'll not try to be compatible with the javadoc API. Being
> able
> > to
> > use
> > javadoc doclets is not a big issue, and if you think the xdoclet
> migration
> > with the
> > current xjavadoc API is ok, then let's forget about javadoc API.
>
> Don't support docletclass. But try to be as compatible as you can.
> type()/doc()/etc are mini-differences which are easy to handle imho.
>
> Ara.
>
>
>
> _________________________________________________________
>
> Do You Yahoo!?
>
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
>
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
