-
Notifications
You must be signed in to change notification settings - Fork 158
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
Ensure internal slots are used when available #231
Comments
Would this affect anything besides |
Sorry, I probably made the original post too strong. If people think it's better as is, I'm fine with dropping this point. But I'm just suggesting to follow the convention @jswalden established in Intl.Locale. I'm not sure if it would be more overhead in practice... |
One area where direct use of internal slots should be avoided is time zone lookup, so that e.g. |
@gibson042 can you elaborate on that? it seems like use of internal slots is unrelated to whether it's possible to observe inconsistencies in timezone data. |
If mapping IANA names to time zone data always goes through a code-exposed interface, then attenuation is possible by simply replacing the interface. Otherwise, it requires replacing every function that can accept a time zone name anywhere in its input. |
I think it's totally reasonable to need to replace all of Temporal in order to control the specific data that's exposed. |
Aside from being a forward compatibility hazard (even if you did replace every function, what happens when a host starts shipping Temporal v2 with new functions?), that burden is so great that it basically incentivizes suppressing Temporal altogether, as SES currently does with Intl—it's like requiring full replacement of Error to hide stack traces or full replacement of Math to prevent use of |
Can you elaborate on why you'd need to attenuate the timezone data in this fashion? |
Two reasons, both mentioned in the original comment.
|
For the former, it seems like it’d be better to have an explicit way for users to inject replacement timezone data - and for the latter, how would it be nondeterminism if it’s always right or always wrong for a given api in a given timezone? Can you help me understand the attack vector here? |
"an explicit way for users to inject replacement timezone data" is precisely what I'm asking for. And the nondeterminism in question is unpredictable output from code like
|
@gibson042 I'm confused by your comment. How are you imagining that this would work? It sounds like you're making a much bigger feature request here than what I was getting at when I opened this issue. I'm not convinced that we should go in this direction, but I'm not even sure what you're proposing. I want to suggest that we pursue this in a separate issue where you lay out out from the beginning. |
I'm starting to take a look at this issue. In many of the cases where we apply Get to an object where we could get its internal slots instead, it's in operations like ToPartialDate, ToPartialDateTime, etc. which are only used in However, the problem as originally described does occur for ToDurationLike and ToTimeDurationLike, which are used in all the |
(And I'm also wondering... if you call const dateTimeObj = Temporal.DateTime.from('2020-01-22T14:30:00');
const someDateObj = Temporal.Date.from('1999-12-31');
const otherDateObj = Temporal.Date.from('2020-01-22');
Object.defineProperty(someDateObj, 'year', {
get() { return 2000; }
}); // spec doesn't say the property is non-configurable...
log(dateTimeObj.with(someDateObj)); // does Get => '2000-12-31T14:30:00'
log(otherDateObj.with(someDateObj)); // reads internal slot => '1999-12-31' |
It seems like I’d want to do that often, to clone/convert one type of another type, creating a distinct object? |
I thought the API for such cloning was |
True, I was thinking that it wouldn't be useful to clone an immutable Date object, but I guess you can set expando properties on it, and it's not immutable in that regard.
According to the current spec, Any thoughts about the other question above, whether |
@ptomato even if immutable and frozen, it still has identity ( |
Anyone have an opinion on the pathological code I wrote in #231 (comment) ? I think that question is the only thing blocking this pull request. |
For For |
I think I agree with #341 since |
OK, now that the scope of where we do coercion is reduced, and also that we're allowing so much dynamicism with calendars and timezones, I agree that it makes sense to use Get in these cases. |
Discussed in Feb. 27 meeting, closing this accordingly. |
Please elaborate? I very much want intrinsic data for a Temporal instance to be stored with internal slots, and only exposed via accessors/methods on the prototype. |
Why wouldn't it be useful to call |
|
|
That's similar to the question I asked in #231 (comment) about using internal slots of other Temporal types than the type whose with() method you're calling. The closed PR didn't cover that case anyway. I can put this on the agenda for next week's call, although I guess there's also |
Could you explain how this is not already the case? |
The proposal is far too large and changes far too quickly for me to have any idea what things are like at a given moment; that an issue with this title is closed as “we don’t want this” leads me to inquire. |
To use The sensible options in terms of temporal objects would be:
while those are all possible, the more general supported case is the one with a plain javascript object. The question therefore becomes: How do these cases behave?
We're looking to treat these identically and to do that we want to get the properties rather than looking at the internal slots. We also think that the core case for using the internal slots would be the case of So while the data is actually stored in intrinsic slots that are accessed via getter properties, and where we have a "typed" interaction we do use these slots generally. The case for with does not lend itself to that philosophy. |
Gotcha - i agree we want to Get the properties inside |
I see these being used effectively in some cases, but in other cases, there are ordinary Gets being applied to objects, in a way which I think deviates from our typical conventions in ECMAScript. For example, in the ToPartialDate, ToPartialTime, and ToDurationLike algorithms: If these are passed a Date, Time or Duration, the internal slots should be directly used.
The text was updated successfully, but these errors were encountered: