Re: How to refer to the current prototype of a class.

[/#!/JoePea]

On Sun, Jul 31, 2016 at 4:15 AM, Claude Pache 
wrote:

> What is the issue with just `Foo.prototype`?


​It means it is subject to renaming (therefore mistakes) when the class
name needs to be changed. Also, consider how lengthy it is to access a
getter or setter:

```js
Object.getOwnPropertyDescriptor(Foo.prototype,
'someSetter').set.call(this, value)
```​

vs

```js
current.someSetter = value
```

Having such a keyword for convenience may also encourage class designers to
avoid the [Fragile Base Class Problem](
https://www.cs.cmu.edu/~aldrich/papers/selective-open-recursion.pdf).


*/#!/*JoePea
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Object.freezing proxies should freeze or throw?

[Raul-Sebastian Mihăilă]

Initially posted on github (https://github.com/tc39/ecma262/issues/652),
but I think the mailing list is more appropriate.

Usually methods on Object that change some internal state of the
objects/properties of the objects either succeed or throw. However,
Object.freeze can fail to freeze proxies without throwing:

```js
  const target = Object.seal({x: 2});
  const proxy = new Proxy(target, {
defineProperty() {
  return true;
},

set(target, prop, value) {
  target[prop] = value;
}
  });

  Object.freeze(proxy);
  console.log(proxy.x); // 2
  proxy.x = 100;
  console.log(proxy.x); // 100
```

Should this be allowed?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Static `super` may cause a unwanted "memory leak".

[Michał Wadas]

Specification doesn't guarantee any optimization, not even garbage
collection, so conforming implementation can allocate objects until OOM.

On Sat, Aug 6, 2016 at 5:57 AM, /#!/JoePea  wrote:

> Ah, interesting to know. Is such an optimization guaranteed?
>
> */#!/*JoePea
>
> On Tue, Aug 2, 2016 at 1:59 PM, Jason Orendorff  > wrote:
>
>> On Tue, Aug 2, 2016 at 3:09 PM, Bergi  wrote:
>>
>>> Why would `tmp` be stored as the [[HomeObject]] when the function
>>> doesn't use `super`? In that case a [[HomeObject]] is not needed at all.
>>>
>>
>> To clarify this: of course the JS engine knows whether the code uses
>> `super` or not and can decide to retain the [[HomeObject]] only when
>> there's some danger of its actually being needed. But do implementations
>> actually do this optimization in practice?
>>
>> SpiderMonkey has a findPath() primitive that searches the GC heap for
>> paths from one object to another, handy for answering questions like this
>> one:
>>
>> js> function SomeFactory(name) {
>>   let tmp = {
>> [name]() { /* this doesn't use `super` */ }
>>   }
>>   return findPath(tmp[name], tmp);
>> }
>> js> SomeFactory("foo") === undefined
>> true
>>
>> That is, there is no GC-path from the method back to the object;
>> apparently [[HomeObject]] is not being retained. What if we change the
>> method to use `super`?
>>
>> js> function SomeFactory2(name) {
>>   let tmp = {
>> [name]() { return super[name](); }
>>   };
>>   return findPath(tmp[name], tmp);
>> }
>> js> typeof SomeFactory2("foo")
>> "object"
>> js> SomeFactory2("foo").length
>> 1
>>
>> Now there is a direct GC-reference from the method to its home object, as
>> expected.
>>
>> -j
>>
>>
>> ___
>> 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

Re: Operating with arbitrary timezones

[Jon Zeppieri]

On Sat, Aug 6, 2016 at 4:27 AM, Alexander Jones  wrote:

> I'm not sure I properly conveyed myself above given what you're saying.
> Let me back up and explain more clearly now I have an actual keyboard in
> front of me.
>
> Currently we have `Date.prototype.toLocaleString()`, which conflates two
> concerns:
>
> 1. Taking an unambiguous *time point* to a { year, month, day, hours,
> minutes, seconds, milliseconds, timezoneOffset } for the selected
> *timezone* (which is the subject of this thread).
> 2. Formatting those "local datetime components" in a way appropriate to a
> specific locale.
>
>
Ah -- you're right. I didn't understand what you were getting at before.
This was very helpful. Thanks. - J
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Operating with arbitrary timezones

[Alexander Jones]

I'm not sure I properly conveyed myself above given what you're saying. Let
me back up and explain more clearly now I have an actual keyboard in front
of me.

Currently we have `Date.prototype.toLocaleString()`, which conflates two
concerns:

1. Taking an unambiguous *time point* to a { year, month, day, hours,
minutes, seconds, milliseconds, timezoneOffset } for the selected
*timezone* (which is the subject of this thread).
2. Formatting those "local datetime components" in a way appropriate to a
specific locale.

Example:

```
d.toLocaleString("en-GB", {timeZone: "Europe/London"})
"06/08/2016, 09:02:13"
d.toLocaleString("en-US", {timeZone: "America/New_York"})
"8/6/2016, 4:02:13 AM"
```

What I'm suggesting is that these two concerns could be better separated.
Hypothetically, think of a new class with the awful and purely illustrative
name `LocalDatetimeComponents`:

```
const now = new Date();

const ldc = now.toLocalDatetimeComponents({timeZone: "Europe/London"});

assert(ldc instanceof LocalDatetimeComponents);

assert(ldc.month === AUGUST);

assert(ldc.timeZoneOffset === -1 * 60);
// UTC+1 for this specific time point, UTC+0 in winter

assert(ldc.timeZoneName === "BST");
// or GMT in winter

assert(ldc.toLocaleString("en-GB", {timeZoneName: "short"}) ===
"06/08/2016, 09:02:13 BST");
```

Note that the vast majority of the many possible `LocalDatetimeComponents`
values would not normally constitute real datetimes. But one benefit of
this separation is that it can express and format things like the time
2015-06-30T23:59:60.123Z (an actual time point within the most recent "leap
second") in spite of the fact that Date itself has no possible
representation of it. Perhaps some class or function other than `Date` can
produce `LocalDatetimeComponents` objects, maybe one that supports leap
seconds in applications that actually need it.

Alex

On 6 August 2016 at 00:08, Jon Zeppieri  wrote:

>
>
> On Fri, Aug 5, 2016 at 6:32 PM, Jon Zeppieri  wrote:
>
>>
>>
>> On Fri, Aug 5, 2016 at 6:21 PM, Alexander Jones  wrote:
>>
>>> Don't confuse timezones with timezone offsets. They are different
>>> concepts.
>>
>>
>>
>> How am I confusing them? You wrote:
>>
>> What I meant by Date+Time components was actually { year, month, day,
>>> hours, minutes, seconds, offset }. I think it makes sense to formalise this
>>> as an expression of a time point (aka Date) *in a particular timezone*. For
>>> example this can be used to decide e.g. "are these two time points in the
>>> same month in this specific timezone", where that month may be e.g. 31 days
>>> + 1 hour. It could also be formatted for display.
>>
>>
>> And I'm saying, in response, that if you want to formalize the concept of
>> a time point in a particular time zone, this isn't a good way to do it. If
>> instead you want to formalize the concept of a particular point in time at
>> a particular UTC offset, then it's fine, of course, but at that point, I'd
>> just reiterate Tab's response.
>>
>> - Jon
>>
>
>
> Actually, let me try to clarify this a bit more. It sounds like you do not
> want a DateTime type to contain (what I would call) a robust concept of a
> time zone, because you think that date "projections" (by which I think
> you're referring to the kind of date arithmetic that I mentioned in an
> earlier post) are a separate concern.
>
> (I'm fine with that, by the way. Off the top of my head, I can't think of
> any date/time libraries that use a time zone as a separate input to date
> arithmetic functions, but it's a reasonable design.)
>
> However, you say that it would be useful to have the offset as part of a
> DateTime object, so that you could answer questions like: "Are these two
> points in time in the same month in this specific time zone?" Well, first
> question: which specific time zone (offset, actually, since that's what you
> want in the objects, right)? We're talking about either a two argument
> predicate function or a binary method, I assume. You might say that it
> doesn't matter which offset you use -- coerce in either direction you want;
> they're either in the same month or not. True (under certain assumptions,
> which I'll get back to in a moment) -- but if you're not interested in
> which month (and which offset), then you don't need the offset in the
> representation at all, because if you could coerce both to UTC to answer
> the question, then... well, you could just represent them in UTC.
>
> And all of this assumes that the question is a meaningful one to start
> with. I'll happily elide the question of what calendar we're talking about,
> but assuming we only care about the proleptic Gregorian calendar: when
> would you ever be interested in whether two points in time fall within the
> same month at a given UTC offset -- as opposed to a more robust notion of
> time zone? I might, at some point, care if two points in time are in the
> same month in America/New_York, but I can't