Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chat about dynamic import guards, asset references, and caching complications #5

Open
mikesamuel opened this issue Dec 6, 2019 · 6 comments

Comments

@mikesamuel
Copy link
Member

Will post time once we've agreement and recording of call post.

Scope for discussion is tentatively issue #3 and #4.

@mikesamuel
Copy link
Member Author

Time is Thursday, December 19

  • 3:00 – 4:00pm US ET
  • 12:00 - 1:00pm US PT

via hangouts

If anyone else wants to join, respond here.

Will try to record.

@engelsdamien
Copy link

I'd like to join

@ljharb
Copy link
Member

ljharb commented Dec 19, 2019

Can someone post the new link? :-)

@mikesamuel
Copy link
Member Author

Sorry for my crap network connection. Thanks for bearing with me.

I'm sure I missed a lot, but to capture some points discussed:

  • ISE/TT doesn't need or want to change the kinds of keys used for internal caches. My intent was to allow in order
    1. the host to check the brand of the argument to import(...) and control/post-process its conversion to a string
    2. as before, resolution, cache checking and network / file system stuff happens
  • TT has a concept of default policies which is why the brand checks are not entirely separable from the stringification.
  • Node.js resolution involves a lot of fstat-ing so not all hosts have this clean separation. @bmeck Are you concerned about opening the door to more entangling? @bmeck pointed out some language related to (loading module, module reference) pairs, and the spec explicitly allowing different module resolution for the same "absolute reference."
  • It's not my intent to introduce any concept of absolute module reference to ecma262.

@ljharb You were saying something about my not having gotten committee-wide signoff on the appropriateness of brand checks for something related to this proposal. I didn't catch that. What was that case that I need to make?

@ljharb
Copy link
Member

ljharb commented Dec 19, 2019

@mikesamuel to clarify :-) bradley mentioned past committee pushback on the concept of brand checks, and i'd clarified that the pushback was about coding in a nominal style (as opposed to a duck-typing/interface-checking style), and thus that pushback didn't likely apply to this proposal.

What I was talking about more broadly was that it seems like these small pieces (that will be pieced together for TT) only sometimes make sense in isolation, and so for all of them to make sense, it might be more productive to find a simple way of teaching the committee how to understand TT as a whole - an understanding I personally still lack.

@mikesamuel
Copy link
Member Author

@ljharb Thanks for explaining. Attending remotely, I have a hard time telling whether I'm only getting questions from the usual suspects because everyone else feels similarly or has checked out. @engelsdamien suggested a TT-background preso for next meeting. I'll see that it directly addresses how the branding enables the claims we think important.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants