Aynchronicity has nothing to do with whether you use class instance methods or static functions. The only difference is whether `this` or an arg is the instance, and the ability to override in type hierarchies, and whether you can use a plain data object (without functions/methods) as the instance. Every other logical necessity when things change is the same.
Just use the one that's simpler to implement based on what your app is doing! To answer your question, yes I've done async with classes. It poses no additional challenge whatsoever. On Wed, 20 Dec 2017, 8:44 am kai zhu, <kaizhu...@gmail.com> wrote: > On Dec 19, 2017 01:36, "Naveen Chawla" <naveen.c...@gmail.com> wrote: > > > > Using static methods with plain objects can be cool if you don't want > method overriding and/or inheritance. Otherwise using classes and methods > makes that simpler to accomplish. > > @naveen, have you tried adding asynchronous features (e.g. typeahead > search or typeahead input-validation) to a frontend-ui that primarily > relied on classes? you generally cannot implement these features like you > would for BLOCKING code (as taught in college cs) by simply updating a > class-method or two. in practice, you oftentimes have to rewrite the > entire class to accomodate a "simple" ui feature-request that changed the > async data-flow. classes normally end up being a non-reusable pile of > async-hacks as a frontend-ui evolves, which makes them no better than > writing throwaway static-functions from the start. at least there's no > pretension for re-usability when writing throwaway static-functions, with > the more realistic expectation they will be constantly re-written as > async-feature-request get added. > > > On Mon, 18 Dec 2017 at 20:53 Isiah Meadows <isiahmead...@gmail.com> > wrote: > >> > >> For one specific example, plain objects can be treated like C structs. > >> For most scenarios you'd want "methods", you could get away just as > >> easily with functions taking the instance as an argument (in > >> particular, you could still use `this`, although I don't in practice). > >> > >> I've used this pattern quite a bit when I have a bit of state that > >> needs accessed in several places, but actions are more easily > >> encapsulated. This isn't as elegant for things like DSLs, but it's > >> useful for more stateful programming. > >> ----- > >> > >> Isiah Meadows > >> m...@isiahmeadows.com > >> > >> Looking for web consulting? Or a new website? > >> Send me an email and we can get started. > >> www.isiahmeadows.com > >> > >> > >> On Mon, Dec 18, 2017 at 6:25 AM, Naveen Chawla <naveen.c...@gmail.com> > wrote: > >> > Javascript won't lose plain objects. Classes simplify cases of type > >> > hierarchies that require overriden methods, and offer a memory > performance > >> > gain in the case of when there are many instances vs using plain > objects to > >> > do the same (which incurs a memory overhead for each instance's > functions > >> > even when they are the same as each other). The only encapsulated way > of > >> > doing this before ES6 was to use prototype, which is easier to get > wrong > >> > especially if there is more than two levels of depth of method > inheritance. > >> > > >> > You get to chose what works for you. You can even argue for using > plain > >> > objects in certain cases where somebody has decided to use classes. > That has > >> > nothing to do with what the language offers for those whose > applications are > >> > simpler and more performant using classes instead. > >> > > >> > On Mon, 18 Dec 2017 at 03:31 Frederick Stark <coagm...@gmail.com> > wrote: > >> >> > >> >> I appreciate hearing Kai's point of view and think that we've had > this > >> >> exact discussion enough times. At this point it just adds to inbox > weight > >> >> without changing any minds > >> >> > >> >> On Dec 18 2017, at 8:23 am, Terence M. Bandoian <tere...@tmbsw.com> > wrote: > >> >>> > >> >>> I appreciate hearing Kai's point of view and don't think he should > be > >> >>> silenced. > >> >>> > >> >>> -Terence Bandoian > >> >>> > >> >>> > >> >>> On 12/17/2017 2:03 PM, T.J. Crowder wrote: > >> >>> > >> >>> On Sun, Dec 17, 2017 at 7:21 PM, Jordan Harband <ljh...@gmail.com> > wrote: > >> >>> > > >> >>> > Adding features in *no way* sacrifices simplicity or ease-of-use > >> >>> > for smaller web projects; as has been said many times on this > >> >>> > list, if you don't like any new feature, simply choose not to use > >> >>> > it. > >> >>> > >> >>> And in many or even most cases, markedly *improves* simplicity and > >> >>> ease-of-use. As has also been repeatedly pointed out. > >> >>> > >> >>> Kai: Genuine questions are fine. Questions which are really just you > >> >>> pushing your agenda of "don't change anything ever again" and your > personal > >> >>> -- and solitary -- claim that "all this new stuff makes life > difficult for > >> >>> people" are, at best, pointless. Your position has been made > crystal clear. > >> >>> There's no need to bang on about it. > >> >>> > >> >>> -- T.J. Crowder > >> >>> > >> >>> > >> >>> _______________________________________________ > >> >>> es-discuss mailing list > >> >>> es-discuss@mozilla.org > >> >>> https://mail.mozilla.org/listinfo/es-discuss > >> >> > >> >> _______________________________________________ > >> >> es-discuss mailing list > >> >> es-discuss@mozilla.org > >> >> https://mail.mozilla.org/listinfo/es-discuss > >> > > >> > > >> > _______________________________________________ > >> > es-discuss mailing list > >> > es-discuss@mozilla.org > >> > https://mail.mozilla.org/listinfo/es-discuss > >> > > > > > > > _______________________________________________ > > es-discuss mailing list > > es-discuss@mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
