-1
this makes the common javascript-painpoint of pinpointing bugs in
UX-workflows even worse.
you're getting invalid visualization or timeouts from the web-UI during
integration/qa. maybe it's from a bug in following low-level code? if so,
was bug from a) constructor, b) foo, or c) @field?
> class Foo {
> constructor(@field foo) {
> }
> }
> var bar = new Foo(foo);
this is also why i'm against decorators in general. i've used them in
python, and beyond toy-cases, it quickly becomes very confusing whether I
should put my business-logic in the decorator or the function ... and pity
to any poor-soul debugging my code trying to figure it out, or worse ends
up having to refactor the decorator (without breaking any of the functions
it touches).
-kai
On Thu, Nov 29, 2018, 07:33 Isiah Meadows <isiahmead...@gmail.com> wrote:
> Just dropping in real quick to correct a couple things.
>
> First, `arguments` itself is *not* deprecated in strict mode. Things
> like `arguments.caller` are deprecated and throw a `TypeError` when
> the corresponding function is in strict mode.
>
> Second, some of you all were looking to use `Object.assign` to help
> explain. You'd need to do this for it to be correct:
>
> ```js
> class C {
> constructor(a, b, ..., y, z) {
> Object.assign(this, {a, b, ..., y, z})
> }
> }
> ```
>
> (Not TC39, just I felt the need to correct people here.)
>
> -----
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
> On Wed, Nov 28, 2018 at 5:50 PM Augusto Moura <augusto.borg...@gmail.com>
> wrote:
> >
> > I forgot the links in my last email, here they are:
> > [1] https://github.com/tc39/proposal-decorators
> > [2]
> https://docs.google.com/document/d/1Qpkqf_8NzAwfD8LdnqPjXAQ2wwh8BBUGynhn-ZlCWT0
> > Em qua, 28 de nov de 2018 às 20:48, Augusto Moura
> > <augusto.borg...@gmail.com> escreveu:
> > >
> > > In the ~maybe long~ future , after the current decorators proposal
> [1], we can start thinking about a Method Parameter Decorator (already
> proposed [2]), we could do something like:
> > >
> > > ``` js
> > > class Foo {
> > > constructor(@field foo) {
> > > }
> > > }
> > > ```
> > >
> > > In my opinion, it would be a much more powerful approach
> > > Em qua, 28 de nov de 2018 às 16:33, Simo Costa <
> andrysimo1...@gmail.com> escreveu:
> > > >
> > > > In costructor functions and in the constructor() method in ES6
> classes is easily to fall in the following pattern:
> > > >
> > > > F(par1, par2, ..., parN) {
> > > > this.par1 = par1;
> > > > this.par2 = par2;
> > > > ...
> > > > this.parN = parN;
> > > > }
> > > >
> > > >
> > > > So my proposal is to avoid those repetitions by prefixing a dot .
> to each parameter:
> > > >
> > > > F(.par1, .par2, ..., .parN) {}
> > > >
> > > > Simple but quite useful. More info here:
> https://github.com/jfet97/proposal-fast-this-assignments
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > es-discuss mailing list
> > > > es-discuss@mozilla.org
> > > > https://mail.mozilla.org/listinfo/es-discuss
> > >
> > >
> > >
> > > --
> > > Atenciosamente,
> > >
> > > Augusto Borges de Moura
> >
> >
> >
> > --
> > Atenciosamente,
> >
> > Augusto Borges de Moura
> > _______________________________________________
> > 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
