If somehow the code could be executed and not just parsed would be easy to
know from what class that method belongs to. But I see the problem now, I
thought it would be easier.
But imagine the among of code that could be reduced with such optimization.
It's well worth the effort.
On Sat, Sep 19, 2009 at 7:31 AM, thron7 <[email protected]>wrote:
> > Talking about optimizations, a "method" optimization is something that I
> > would like to see in the tool chain. Imagine that after you writing your
> > code the tool chain has how to know what methods was called and what
> > methods
> > was called by those methods and so on. In the end, it knows which methods
> > weren't used and can exclude them from the build js file. It would
> greatly
> > reduce the final size.
> >
> > Since the tool chain already scans all files it could save all those
> > methods
> > calls somehow.
> >
> > Maybe thron7 could comment about it. I'm sure they had already thought
> > about
> > that.
>
> And indeed we have :-). The big issue we face here is the deeply dynamic
> nature of Javascript (which we usually all love so much). It is very hard
> to be sure that a certain method of a class is never used, as references
> to methods can come in all disguises. Static methods like
> a.b.c.Class.meth() are easy. Instance methods like obj.meth() are a lot
> harder, since object instances can be passed around arbitrarily, and you
> might have no way of telling when an instance shows up in code which class
> it stems from, unless it was instantiated in the same block. And so forth.
>
> So method pruning might only be possible for certain methods, of certain
> classes, under certain circumstances. The developer might have to make
> additional efforts, like type-tagging formal arguments (oups!) within
> comments, or follow other disciplines. And a potential
> "prune-unneeded-methods" compile option will remain a use-at-your-own-risk
> option where the developer has to make sure he knows what he is doing
> (like some optimization options for standard C/C++ compilers). Such an
> option would never be automatically safe.
>
> If you want, be the first to materialize this train of thought by opening
> an enhancement bug for it :-).
>
> I hope Alex will comment on the low-level stuff next week, as he has been
> concerned with exactly these questions.
>
> T.
>
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
