actually, if the value is passed, the `B` constructor will throw, but not
in `A`

Properties that has been directly assigned have no reason to be specified
as default in the prototype, if the constructor needs to directly assign
them ... right?

```javascript
function A(value) {
  this.value = value || 0;
}
```

That's it, there is no reason to introduce an inconsistent behavior that
behaves in a completely unexpected way with properties maybe meant to be
inherited as non writable, as the specification, rightly or wrongly, say.

Will this ever be fixed? I start a post of 4 parts about descriptors, and
the more I write and test, the less I can explain people that ES5.1 is
actually a good standard ... there are so many little different things ...
but above one, I really don't get who even thought about it and why.

Apologies for the rant, I stop here, but I really hope this mess will be
cleaned up pretty soon.

Best Regards




On Fri, Mar 28, 2014 at 3:00 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> For the sake of examples, I honestly find current V8 hack, tested in
> node.js inconsistent, kinda pointless, and quite disturbing, with or
> without strict code.
>
> ```javascript
> function Class(value) {
>   this.value = value;
> }
> Object.defineProperties(Class.prototype, {
>   value:  {value: null},
>   method: {value: Class}
> });
>
> var a = new Class(123);
> a.value; // 123 ... why?
>
> var b = Object.create(Class.prototype);
> Class.call(b, 123);
> b.method(123);
>
> b.value; // null ... I mean ... **null**
> ```
>
> Even worst when it comes to default values ...
>
> ```javascript
> function A(value) {
>   this.value = value;
> }
> Object.defineProperty(
>   A.prototype,
>   'value',
>   {value: 0}
> );
>
> function B(value) {
>   if (value) {
>     // best of all .. it won't assign
>     // and it won't throw neither
>     // congrats?
>     this.value = value;
>   }
> }
> Object.defineProperty(
>   B.prototype,
>   'value',
>   {value: 0}
> );
>
> var a = new A(123);
> a.value; // 123
> a.value = 456;
> a.value; // 456
>
> var b = new B;
> b.value; // 0
> b.value = 456;
> b.value; // 0
>
> var b = new B(123);
> b.value; // 0
> b.value = 456;
> b.value; // 0
> ```
>
> Why JavaScript engines need so much fragmentation with these kind of
> unspeced behavior ... this, as a developer, I've never got it.
>
> Best Regards
>
>
>
> On Thu, Mar 27, 2014 at 10:28 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> I know it won't get updated any time soon but unfortunately, and
>> specially in some emerging market, [these kind of phones](
>> http://www.amazon.com/LG-Navigation-OPTIMUS-ME-BLK/dp/B005HEEBQI/ref=sr_1_62?s=electronics&ie=UTF8&qid=1395940823&sr=1-62&keywords=android+phone)
>> are still quite common ... you guys should speed up spreading FirefoxOS on
>> $25 deals !!!
>>
>> Anyway, I was just saying Android 2.x is like the IE6 of these days, IMO
>> ... and I am not sure it will go away any time soon.
>>
>> Best Regards
>>
>>
>> On Wed, Mar 26, 2014 at 11:36 PM, Brendan Eich <bren...@mozilla.org>wrote:
>>
>>> Andrea Giammarchi wrote:
>>>
>>>> on Android 2.3.6 (or lower) you can [try this page](
>>>> http://www.3site.eu/jstests/configurable.html) which will show an
>>>> alert like
>>>>
>>>> ```
>>>>
>>>> Sorry for the initial false alarm, at least I am sure few didn't know
>>>> about the getters and setters bug in actually quite recent Android 2
>>>> browsers.
>>>>
>>>
>>> Android 2.3 (Gingerbread) may be quite recent on a lower-end phone, but
>>> it is incredibly out of date and not being maintained. Especially its old
>>> WebKit fork. V8 was backported, but that was in 2010 -- pretty sure it is
>>> not patched up to anywhere near current level.
>>>
>>> http://en.wikipedia.org/wiki/Android_version_history#
>>> Android_2.2.E2.80.932.2.3_Froyo_.28API_level_8.29
>>>
>>> /be
>>>
>>
>>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to