flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FlexJS] Interfaces, Pay as You Go, Performance
Date Mon, 08 Aug 2016 18:01:56 GMT

On 8/8/16, 9:50 AM, "yishayw" <yishayjobs@hotmail.com> wrote:

>Alex Harui wrote
>> On 8/8/16, 6:23 AM, "Harbs" &lt;
>> harbs.lists@
>> &gt; wrote:
>>>> 2) The supposedly heavyweight model that is rich with convenience
>>>> doesn't actually result in heavy instances. The methods are all stored
>>>> on the prototype and not duplicated per instance. So using the
>>>> model doesn't really make the difference one might hope it would.
>> If extra methods are bringing in extra dependencies, then I would
>> having a subclass with those extra methods/dependencies.  If the extra
>> dependencies are a few interfaces, then I would just bake them in.
>> My 2 cents,
>> -Alex
>To make sure I understand your point, I'll rephrase it: as long as we're
>importing new classes to implement the convenience methods we should go
>ahead and add them. They should still implement some interface. Correct?

Well, it is always a trade-off.  If you add 100 APIs that only a few need,
then maybe you want to consider some other way of adding it later.  The
cool thing about JS is you can add methods to a class at runtime.

An interface is also optional.  For example, we don't have an IPoint
interface.  The Point class is just too simple to make it worth it.
Matrix probably doesn't need an interface either unless you think we'll
replace Matrix implementations instead of extending them with

>I hadn't considered compiler optimizations as a way to work around method
>call overhead. I think it makes for a convincing argument for freely using
>interfaces after all.

IMO, the whole point of compiler optimizations (and runtime optimizations)
is to find patterns in good code and make faster code.  Even an If
statement compiles to use the GoTos we aren't supposed to use in our code.
 Look up how Tail Call Optimizations are discussed as a way to optimize
delegate/proxy patterns like we use in the FlexJS wrapper components.
AIUI, the JS runtimes are investing lots of money in runtime optimization
like type inferencing, JIT and other really amazing things.  Some
researchers have shown that you can find some really complicated code path
and rewrite it as a single new inlined entity at runtime and reap huge

As I see it, the entire industry, not just Apache FlexJS, is betting that
folks will need the overhead of structured code development to create
bigger and bigger apps and the runtimes/browsers are going to have to
support it.  So I am betting that we can write good code with interfaces
and the extra overhead of proxying between beads and we'll be better off
by doing that instead of writing hand-tuned JS.

So yes, IMO, more interfaces, but again, make sure they are useful and not
just an academic exercise.


View raw message