Re: Question of the Day: What about all this asynchrony?
Yes, I understand. Thanks for being polite! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Question of the Day: What about all this asynchrony?
Hi, Micheal, you sound like one of the foolish virgins that forgot to bring oil for their lamps. You know that you need to do more research and that you lack conceptual understanding. Now, because you've brought to little, your asking for what you failed to bring. No, go rather to them that sell, and buy for yourself. Listen to those who were wise enough to bring oil for their lamps and can see clearly on this issue. Imagine if everybody started sending emails to es-discuss with your level of appropiateness If they did, I'd unsubscribe, mark it as spam, and create a custom filter just to ensure all emails with the words 'es-discuss' would be immediately deleted. tl;dr Slap yourself. I responded simply because I was annoyed that I actually read everything you said. Yawn...I mean, I would actually add something of value but umm... I wasted all my reading time on this. lol I've silently followed es-discuss for years. Please excuse me ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The Existential Operator
Claude Pache,
I had to read up on this existential operator to realize your question. In
your example the variable 'a' is the target/operand of the existential
operator. If 'a' isn't null or undefined then the result will be the result
that you'd expect had you not used the operator, assuming theres not a
TypeError in the expression. Here I choose to define an operator as a
shorthand function of which I don't find overly complicated.
function example() {
If (a !== null a !== void(0)) return a;
return void(0);
}
If 'a' is undefined...
var a = void(0);
example(a).b.c
Would normally throw but with the existential operator...
var result = a?.b.c
Does not.
result === void(0) // true
Another thought.
var a = {};
var result = a?.b.c;
Will throw because there can be no property 'c' on undefined.
var result = a?.b?.c; -- Awesome semantics!
And of course: result === void(0) // true
On Tue, May 20, 2014 at 3:30 AM, Aaron Powell m...@aaron-powell.com wrote:
It might be worthwhile keeping an eye on the C# language discussion on the
same operator - http://roslyn.codeplex.com/discussions/540883
*From:* es-discuss [mailto:es-discuss-boun...@mozilla.org] *On Behalf Of *A
Matías Quezada
*Sent:* Tuesday, 20 May 2014 7:56 PM
*To:* Claude Pache
*Cc:* es-discuss
*Subject:* Re: The Existential Operator
I think the current use of this operator will only make sense if the
operator interrupts the whole sentence so
a?.b.c
Will be the same as
a a.b.c
And
a?().b?.c?.d
Will be same as
a (x = a(), x.b (x.b.c x.b.c.d))
---
A. Matías Quezada
Senior Javascript Developer
amati...@gmail.com
2014-05-20 11:31 GMT+02:00 Claude Pache claude.pa...@gmail.com:
Le 20 mai 2014 à 05:50, Dmitry Soshnikov dmitry.soshni...@gmail.com a
écrit :
Hi,
(I remember, I mentioned this couple of years ago, but not sure about
whether it was considered, etc)
Will the Existential Operator for properly accessors be something
interesting to consider for ES7 spec? Currently CoffeeScript uses it well.
```js
var street = user.address?.street;
```
The `street` is either the value of the `user.address.street` if the
`address` property exists (or even if it's an object), or `null` /
`undefined` otherwise.
This (roughly) to contrast to:
```js
var street = user.address user.address.street;
```
(the chain can be longer in many cases).
The same goes with methods:
```js
var score = user.getPlan?().value?.score;
```
If potentially it could be interesting for ES7, I'll be glad helping
with the proposal, grammar and algorithm (unless it was considered
previously, and decided that it's not for ES for some reason).
P.S.: I tried to solve this issue using default values of destructuring
assignment, but it doesn't help actually.
Dmitry
Question: What is the semantics of the following:
a?.b.c
Is it the same thing as
(a?.b).c
(a a.b).c
or the same thing as:
a a.b.c
(For the sake of the argument, just ignore the distinction between falsy
and null/undefined.)
If it is the second option, I fear that the semantics of the so-called
existential operator is more complicated than just an operator.
—Claude
___
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: Need a champion? StringView strawman
I disagree. I think this should progress. It doesn't have to add any additional functionality to Typed Arrays. As it stands I would consider it a replacement for the purposes of TextEncoder and TextDecoder APIs. Currently the Mozilla TextDecoder Web API does not accept ASCII as a valid encoding option and defaults to UTF-8, if left unspecified. On Fri, Jan 10, 2014 at 1:52 PM, Brendan Eich bren...@mozilla.com wrote: Kenneth Russell wrote: Adding a StringView to Typed Arrays would bring along all of the complexities of character set encoding and decoding to the Typed Array definitions. Typed Arrays were designed to be small, simple, and comprehensible enough that they would be easily implementable and optimizable. I believe that adding a StringView would contradict these goals. + a lot. What can we do to make sure this thing stays dead, if it is dead? Anne may know some weird W3C protocol trick. ;-) /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
Re: Need a champion? StringView strawman
On Fri, Jan 10, 2014 at 3:14 PM, Boris Zbarsky bzbar...@mit.edu wrote: I'm curious. What would you expect such an option to do? Byte-inflate like ISO-8859-1? Byte-inflate but throw on bytes with values 127? Act as a synonym for ISO-8859-9? Something else? Exactly how StringView handles the option now. If I generate a random string using byte values then each char in that string should correspond to a single byte when specifying the ISO-8859-1. It doesn't really make since to use UTF-8 for bytes when that data should be manipulated as bytes in the first place. In the case of data being represented as a string but need to be handled as bytes. https://bugzilla.mozilla.org/show_bug.cgi?id=957424 UTF-8 being the default is not the problem of course. Throwing an exception for ASCII is. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
UDP Datagrams. On Fri, Jan 10, 2014 at 3:28 PM, Brendan Eich bren...@mozilla.com wrote: Dwayne wrote: Currently the Mozilla TextDecoder Web API does not accept ASCII as a valid encoding option and defaults to UTF-8, if left unspecified. That's a feature. The '90s are over, let's not go back. Why do you want ASCII, and what do you do with it? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
I mean char code points in the range (0-255) a byte. Use the desired terminology or name. Primarily because of this bug - Expose raw data on UDP socket messages: https://bugzilla.mozilla.org/show_bug.cgi?id=952927 I generate a random string using code points that I eventually convert to bytes. Specifically in the case of a two or 20 char/byte ID. Where I need to be able to use the entire 16 bit or 160 space and then send as bytes and trust that ID will be same for both parties consistently. -- To elaborate, I need to bencode this information before converting to bytes. I understand all of this could be worked around by just using String.charCodeAt or the synonymous String.codePointAt but why then have such a powerful API and disallow the fore-mentioned feature? And why exactly have to separate APIs? On Fri, Jan 10, 2014 at 3:40 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/10/14 4:29 PM, Dwayne wrote: Exactly how StringView handles the option now. If I generate a random string using byte values then each char in that string should correspond to a single byte when specifying the ISO-8859-1. OK, so specify ISO-8859-1, if that's what you're really doing. Or are you saying that you just want ascii to be a synonym for iso-8859-1 here? But it'd be a lie, because ASCII actually means something, and it means something different from ISO-8859-1. But really, if you just have bytes, not text, why are you generating a string from those byte values at all? This is where a typed array would make more sense... -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
No joke. But as far as optimization goes I'm limited. You wrote the book so thanks for at least hearing me out. ;) On Fri, Jan 10, 2014 at 4:07 PM, Brendan Eich bren...@mozilla.com wrote: Dwayne wrote: UDP Datagrams. Use a Uint8Array and string decoding/encoding API. Browsers have to copy anyway, you're not optimizing by using the (soon to be dead, I hope) StringView. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Need a champion? StringView strawman
Compensate the lack of rawData property -- Bug 952927 Buffer is a Uint8Array which has non standard methods on its prototype using a WeakMap technique. -- This module will be used with BitTorrent PWP as well so its definitely necessary. https://github.com/DecipherCode/Firebit/blob/master/lib/dgram.js#L78 And here is a snippet covering the other reason(s): http://pastebin.mozilla.org/3986282 Thanks. On Fri, Jan 10, 2014 at 7:31 PM, Brendan Eich bren...@mozilla.com wrote: Dwayne wrote: Primarily because of this bug - Expose raw data on UDP socket messages: https://bugzilla.mozilla.org/show_bug.cgi?id=952927 Answering for bz: why do you need string-views or string-anythings to wrangle bytes in and out of a Uint8Array? Can you show some code? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
