Re[2]: Operators overriding
I dislike this proposal.
1 It is not very good to limit overrideable operators to value classes.
2 It is not very good to have a lot of custom operators, it will break code
readability and will allow more efficient obfuscration.
3 I think that most of binary non-assigning operators must return a new object
and thats' why they should be not object methods, but the methods taking 2 (or
more if chained!) objects and return the result usually of same type.
вторник, 22 декабря 2015г., 21:45 +03:00 от Sander Deryckere <
sander...@gmail.com> :
>IMO, operator overloading is important and different enough to warrant a
>separate syntax.
>
>But the difficulty isn't in defining the operator, but in the ambiguous cases.
>Like what to do when there are 2 different types, how to make sure certain
>relations will stay correct, ...
>
>There's a nice presentation from Brendan Eich here:
>http://www.slideshare.net/BrendanEich/value-objects2
>
>Regards,
>Sander
>
>2015-12-18 21:24 GMT+01:00 KOLANICH < kola...@mail.ru > :
>>Hello. What do you think about overriding operators using proxies?
>>For example
>>function A(r=""){
>>this.rep=r;
>>return new Proxy(this,{operators:{"+":function(a,b){return new
>>A(a.rep+"+"+b.rep);}}});
>>}
>>let a=new A("a"), b=new A("b");
>>let c=a+b;
>>console.log(c.rep);//a+b
>>
>>___
>>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
Operators overriding
Hello. What do you think about overriding operators using proxies?
For example
function A(r=""){
this.rep=r;
return new Proxy(this,{operators:{"+":function(a,b){return new
A(a.rep+"+"+b.rep);}}});
}
let a=new A("a"), b=new A("b");
let c=a+b;
console.log(c.rep);//a+b
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Language design
I have tested Boris's build The results are: chrome is broken in large part Mail.ru mail interface is broken Gmail is broken google docs is broken peacekeeper is not broken 3 russian it news portals are not broken (UI is OK, on the one sending the comment worked with minor bug in UI, but when I tried one more time, it disappeared, so maybe not 3 but 2) Google is partly broken Microsoft.com is not broken mail.live.com is broken mail.yandex.ru is broken reddit is not broken (I havent tested send) facebook is broken Probably this is because of JQuery, my projects (I don't use JQuery in them) work fine.___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Language design
Hello all. I have opened the page https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/ECMAScript_6_support_in_Mozilla and was horrified. What happened with JS? Why do we need all this methods? Why a lot of functionality is now doubled, and a lot of new badly designed API and language features was introduced? I understand the word compatibility, but I think that no compatibility worth enough to be preserved sacrificing the language design making it self-contradictary. For example, Object.is compares identity. Operator === also compares identity but in a bit differrent way. Why not just make == check equality only between compatible types, === check identity (that the object is the same) and throw out Object.is. Operator [] casts its argument to string ... but not when used with Symbol (why not just allow the key to be any object and match using ===). New iterator API relyes on Symbol.iterator. Why do we need it? Why not just use strings and prototypes? fromCodePoint doubles fromCharCode, but differs a bit. Why didn't you repurpose fromCharCode, just allowing it to take a string arguments describing codepages? Iterability and enumerability are distinct, but iterability is just enumerability with numeric key (yeah, I know that it is possible to create endless or random iterator, but in fact this means that you just don't need to use the key provided). Why there is iterability, but not enumerability with properties of iterability and enumerability united? Why we need enumerability to make it work with for ... in and iterability to make it work with for ... of? Why can't we use methods definitions to define methods as a function declaration? Why JS is so badly designed?___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re[2]: Language design
You missed that Object.is(-0, +0) (and with arguments transposed) is false,
while -0 === +0.
No. I really think that -0 === +0 also should be false, because they are
different objects. So should be 0==0. I don't think it will break a lot of
code, because I cannot mind a situation where such comparisons can be needed
(except comparing zIndex and other numeric attributes casted to strings
automatically, but it is not very hard to insert parseFloat there).
If your point is that Object.is does not pull its weight
My point is that there shouldn't not be a lot of similar API which behavior is
not intuitively clear.
I don't know what you think about it, but I think that this should have
semantics of comparison by value. We can compare numbers, so let 3.0==3 be
true. A string and a number have different semantics (string is array of
characters, number is number), so let 3==3 be false.
Also ({a:1}=={a:1}) should be true; undefined==undefined should be true;
null==null should be true;NaN== NaN should be false;
Number.POSITIVE_INVINITY==Number.POSITIVE_INVINITY should be false.
=== has identity semantics
undefined===undefined shoulld be true; null===null should be true;NaN=== NaN
should be true; Number.POSITIVE_INVINITY===Number.POSITIVE_INVINITY should be
true because they all in fact a special value.
-0==+0 should be true, because it is the same number. -0===+0 should be false
because they are different values (which in case of integer can be understood
as differrent objects of class Number).
And again, I don't think that someone strongly relies on current semantics of
comparison because of its counterintuitivity.
Behaving the described way we only need the two operators.
Пятница, 12 июня 2015, 16:45 -07:00 от Brendan Eich bren...@mozilla.org:
Edwin Reynoso wrote:
Yes please edit it, you don't have to repost. BTW the only thing I can
agree with is the `Object.is()` which to me seems like the only
problem it solves is `Object.is(NaN, NaN)` now returns true
You didn't agree with the root post (whose sender has had the mod flag
set for moderated postings, btw). That root post ignored compatibility
constraints that have been discussed to death over the years, and just
glibly asserted that == and === could be changed. So, I don't believe
you agreed with that noise. Am I mistaken?
If your point is that Object.is does not pull its weight, make a
stronger case for why people should have to write it by hand.
You missed that Object.is(-0, +0) (and with arguments transposed) is
false, while -0 === +0.
/be
___
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
Converting strings to template strings
I needed a functionality but haven't found it. See https://stackoverflow.com/questions/29182244/convert-a-string-to-a-template-string for more details. I think that this should be included into standard; Also we need a standard format string functionality like https://msdn.microsoft.com/en-us/library/system.string.format.aspx and https://docs.python.org/2/library/string.html#string-formatting ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
