On 8/8/16, 9:50 AM, "yishayw" <[email protected]> wrote:
>Alex Harui wrote >> On 8/8/16, 6:23 AM, "Harbs" < > >> harbs.lists@ > >> > wrote: >> >>>> 2) The supposedly heavyweight model that is rich with convenience >>>>methods >>>> doesn't actually result in heavy instances. The methods are all stored >>>>once >>>> on the prototype and not duplicated per instance. So using the >>>>'lightweight' >>>> model doesn't really make the difference one might hope it would. >> >> If extra methods are bringing in extra dependencies, then I would >>consider >> 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 >not >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 plugins/beads. > >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 benefits. 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. Thanks, -Alex
