Skip to content

Latest commit

 

History

History
76 lines (72 loc) · 5.43 KB

2018-08-21.md

File metadata and controls

76 lines (72 loc) · 5.43 KB

Decorators call agenda and notes Tuesday, August 21, 2018, 17:00 UTC

Attendees:

  • Bradley Meck (BF)

  • Jordan Harband (JH)

  • Ron Buckton (RB)

  • Justin Ridgewell (JRL)

  • Diego Ferreiro Val (DFV)


Agenda & notes:

  • toString regardless of ordering

    • BF: No strong objection to including. Would not want it if it’s not a simple substring of the sourceText

    • RB: If it’s @dec export, either export is included or it’s excluded. Or we change what the grammar says is part of the toString. If export comes first, it’s a no brainer.

    • BF: I object to concatting.

    • RB: I agree.

    • JH: RB wants to not include them? And BF wants to include, but only if we don’t concat.

    • JRL: We could take it the other way, we could include export into exported class declarations. Then including export in @dec export class X {} isn’t a big deal.

    • RB: Having decorators in toString allows for eval case, and allows contextual information. Those are the real reasons to include. Both of those apply to including export.

    • BF: Does anyone feel that we need them in toString?

    • JH: I feel like we need to include them.

    • DFV: What decorators mean to a class and what export means to a class are very different.

    • JH: We disagree because we think static and export are very different things.

    • RB: Yes. And this comes from other languages that do this.

    • JH: I don’t think we’ll make two independent decisions. We’ll either have decorators before export, and include export. Or we’ll have export then decorators, and we can include decorators in that case.

    • BF: I would need convincing to do a concat.

    • RB: The question that came up in the F12 debugger, can a debugger eval code that includes the export keyword?

    • BF: It can happen.

    • RB: but you said you inject export?

    • BF: No, just don’t want to concat. I just want a regular, single substring.

    • RB: My preferences are, don’t include. Then include the export in @dec export. Then concat if we can compromise.

    • JRL: If we do @dec export, could we just include export in class declaration?

    • JH: Export probably won’t go in toString. Concat probably won’t happen. My preference is export @dec and include decorators in toString. Or we do @dec export and decs aren’t included.

    • JRL: Why the strong dislike for including export?

    • JH: Because it’s not a value modifier.

    • RB: I think the issue here is that export looks like a modifier. It should be modifying the class.

    • … I took a break taking notes 😬 … Lots of “mental model” talk...

    • JH: We can take the two options to committee:

      1. Think of including export as a modifier

        • Include export in toString

        • Decorators before export

      2. Think of export as a module thing

        • Don’t include export in toString

        • Export before decorator

    • BF: That we can use export not on a declaration ( export { binding as name }) means that it really can’t apply export as a modifier in every case. If we break the export class X into two statements, it would break the toString.

    • JRL: Do these other languages that use export as a modifier, do they also allow you to break up the export into an export and a declaration.

    • RB: I would have to see.

    • JRL: We can also disallow decorators on export keyword.

    • DFV and JH: That would force the hand of the ordering, because we would have to decide if toString is included in the broken class declaration.

    • RB and BF: We could do a user survey, but you have to be careful of bias.

    • RB: Typescript will conform to whatever ES decides.

    • JRL: What if using decorators completely censored to toString? Kinda like [native code]

    • JH: That would eliminate debuggability kind of like using .bind, but unlike bind, there are things that can’t be accomplished without decorators.

    • RB: I don’t think there’s value in censoring instead of just not including them.

    • JRL: We also haven’t discussed decorators on method’s toString. Are we basing that decision off of decorators on classes?

    • RB and JH: Yes.

    • JH: We’ll propose adding static keyword to toString in MF’s toString proposal.

    • RB: Back to the survey, do we want to do that?

    • JRL: I think we’d need to include others in the discussion to do a survey.

    • BF: No opposition, but it’ll mean a long time.

  • Next Steps

    • JRL: What are our next steps?

    • RB: Need to discuss mental model approach?

    • JRL: Is this a discussion that needs to happen in another meeting, or on GitHub?

    • JH: I’m not sure we can convince the other in another meeting. We could propose including export in toString, and work from there?

    • JH: Also getting static included in toString.

    • JRL: Sounds like we can get the two mental model approach on GitHub, discuss all the changes necessary to support those models, and the pros/cons of them.

    • RB: One thing we can discuss: Does it make sense to decorate exports to change its behavior?

    • Next agenda will include decorating export.

  • Decorating Export discussion on Github
  • Two mental model approach on Github
    • @ljharb @rbuckton, please create an issue.