Well, before I start arguing with you, I'd like to know what argument you're
making. ;-)
Are you saying we should go back to having a MIME-type (and/or pragma) opt-in?
Your subject line suggests that. Or are you saying we should simply not support
some of the new features in non-strict code?
Perhaps, but the mobile web is WebKitty. The ES6 semantics is incompatible with
Chrome and Safari's behavior here.
Dave
On Dec 26, 2012, at 2:37 PM, Brandon Benvie bran...@brandonbenvie.com wrote:
This appears to be correct. A number of the examples can be boiled down to
the following test:
On Dec 26, 2012, at 2:30 PM, Mark S. Miller erig...@google.com wrote:
Sorry, I'd completely forgotten about those earlier options. I am
arguing only the latter. Specifically Any ES6 features that don't fit
into non-strict mode without contortion, including let and nested
function, should be
On Dec 11, 2012, at 2:45 AM, Andreas Rossberg rossb...@google.com wrote:
Late to the party, sorry. First, let's be clear there are a couple possible
semantics that could be called temporal dead zone. At this point I'm not sure
what various people had in mind; I suspect different people may have
On Dec 26, 2012, at 3:35 PM, Mark S. Miller erig...@google.com wrote:
I think you did coin 1JS. What do you mean by it? Does it bear on
the present issue or not?
I coined the just one JavaScript here:
https://mail.mozilla.org/pipermail/es-discuss/2011-December/019112.html
And it got
On Dec 26, 2012, at 7:40 PM, Brendan Eich bren...@mozilla.com wrote:
Many also believe that hoisting is an excellent feature, not a weirdness.
For functions, I can defend hoisting, although if I had had more time, I
might have done a let ... in ... or BCPL'ish equivalent form that groups
On Dec 26, 2012, at 8:36 PM, David Herman dher...@mozilla.com wrote:
- JS is dynamically scoped, so having an implicit dummy value isn't a problem
for the type system.
Holy misnomers, batman. I meant dynamically typed. May Bob Harper have mercy on
my soul. [1]
Dave
[1] He won't. He'll
On Dec 24, 2012, at 1:48 AM, Anne van Kesteren ann...@annevk.nl wrote:
I thought I'd give a heads up as over on www-...@w3.org we're
discussing two cases where we likely need to change the prototype
chain of objects: document.open() and methods that do the equivalent
of document.adoptNode()
On Dec 24, 2012, at 2:17 AM, David Bruant bruan...@gmail.com wrote:
The ability to change the [[Prototype]] of an object is orthogonal to the
__proto__ problem. If it's necessary for DOM objects to change the
[[Prototype]] for backward-compat or security reasons, it can do so, I guess.
On Dec 27, 2012, at 1:23 AM, Andreas Rossberg rossb...@google.com wrote:
Let's start with TDZ-RBA. This semantics is *totally untenable* because it
goes against existing practice. Today, you can create a variable that starts
out undefined and use that on purpose:
I think nobody ever
On Dec 27, 2012, at 1:51 AM, Andreas Rossberg rossb...@google.com wrote:
I think hoisting can mean different things, which kind of makes this debate a
bit confused.
Yep. Sometimes people mean the scope extends to a region before the syntactic
position where the declaration appears, sometimes
On Dec 27, 2012, at 2:13 PM, Andreas Rossberg rossb...@google.com wrote:
It's true that with TDZ, there is a difference between the two forms above,
but that is irrelevant, because that difference can only be observed for
erroneous programs (i.e. where the first version throws, because 'x'
On Dec 28, 2012, at 8:32 AM, Domenic Denicola dome...@domenicdenicola.com
wrote:
Dave and Sam may have a different answer, but I'd answer that the aliasing
semantics follows from a module system's role as (among other things) a name
spacing mechanism.
This idea of modules as namespaces
On Dec 28, 2012, at 9:12 AM, Andreas Rossberg rossb...@google.com wrote:
We haven't had the opportunity to discuss that one, but now that you mention
it, I should say that I actually think exports as accessors are a no-go.
It's just a thought, and I can see already that it's controversial, so
On Dec 28, 2012, at 9:16 AM, Domenic Denicola dome...@domenicdenicola.com
wrote:
The aliasing isn't observable for immutable bindings, only for mutable ones.
In my experience, all of the module exports I've seen from NPM modules I've
used were immutable.
This is amusingly tied to the
On Dec 28, 2012, at 9:39 AM, Domenic Denicola dome...@domenicdenicola.com
wrote:
On Dec 28, 2012, at 12:28, David Herman dher...@mozilla.com wrote:
Another example where this could come up is initialization. Since imports
tend to be at the beginning of a module, you could end up reading
On Dec 28, 2012, at 10:31 AM, Kevin Smith khs4...@gmail.com wrote:
However, I agree that the destructuring syntax for module imports may not be
the clearest choice in terms of raising the right expectations. (As we have
discovered already, it has other issues, namely people confusing the
On Dec 28, 2012, at 2:11 AM, Andreas Rossberg rossb...@google.com wrote:
That doesn't prove that it was a *bug*. That's a question about the
programmer's intention. In fact, I don't think you can. For example, I
mentioned let-binding at the bottom:
{
console.log(x);
On Dec 28, 2012, at 2:29 AM, Andreas Rossberg rossb...@google.com wrote:
Can these plenty be enumerated? Apart from const, which ones have TDZs?
All declarations whose initialization cannot be hoisted. My understanding is
that that would be 'const', 'class' and 'private', although we have
Andreas pointed out [1] that the question of defaulting to undefined vs
uninitialized is orthogonal to the question of read-barrier vs read-write
barrier:
Even with TDZ-RBA you can have that meaning for let x (and that semantics
would be closest to 'var'). What TDZ-RBA gives you, then, is
On Dec 26, 2012, at 3:03 PM, David Bruant bruan...@gmail.com wrote:
The initial value. We can look into what it would mean to make it
modifiable, but we'd probably not make that the API; we'd probably just have
a setter.
Good point.
[Adding MarkM into the mix for this part]
I wish to
On Dec 28, 2012, at 11:48 AM, Andreas Rossberg rossb...@google.com wrote:
All understood, but what's the difference to __defineGetter__?
That MS does not appear to feel pressure to implement __defineGetter__ but it
does feel pressure to implement __proto__.
Dave
On Dec 28, 2012, at 11:47 AM, Andreas Rossberg rossb...@google.com wrote:
We can identify two classes of lexical declarations:
1. Those where initialization can be performed at the start of the scope
(which is what I meant by hoisted above), and the bound variable can safely
be accessed
On Dec 26, 2012, at 10:56 PM, Brendan Eich bren...@mozilla.com wrote:
It does not even contain the word strict. IIRC (and I asked about this at
the last TC39 meeting and got verbal confirmation), the idea of module {...}
implying strict mode was latent, or intended. I'm not sure about out of
On Dec 28, 2012, at 12:20 PM, Brendan Eich bren...@mozilla.com wrote:
I get nervous when speculations about future adoption ratios or incentives
for developers are made without enough data or table-stakes ante'ing (bolded
tripled *biggest* doesn't count as money!).
OK, I've made that same
On Dec 28, 2012, at 12:11 PM, Brendan Eich bren...@mozilla.com wrote:
David Herman wrote:
Andreas, can you explain why you dismiss TDZ-RBA-UNDEF as a viable option?
The bug that motivates all the arguments you've made is
read-before-initialization, not write-before-initialization
On Dec 28, 2012, at 12:30 PM, Brendan Eich bren...@mozilla.com wrote:
But even if*not*, it's not worth proliferating the number of cases that are
implicitly strict.
To answer that, you have to speculate on costs and benefits of strict mode
for classes outside of modules, not talk about
On Feb 7, 2013, at 9:48 AM, Brandon Benvie bran...@brandonbenvie.com wrote:
The goal here is not to claim that all is lost with the module system in
full, because I do think that's not a certainty yet. I do think it is a
likely enough outcome that there should be a fallback to capture the
That sounds reasonable to me.
Dave
On Mar 15, 2013, at 11:01 AM, Kevin Smith khs4...@gmail.com wrote:
Anyway, my questions are cleared up (for now). Can't wait for those wiki
updates! ; )
Ah - one more comment.
The signatures for `load` and `evalAsync` indicate that they will
On Mar 21, 2013, at 12:25 PM, Kevin Smith khs4...@gmail.com wrote:
Ideally, everything will just work, so that legacy modules can be used
transparently alongside ES6 modules.
I disagree with this premise. It shouldn't be ES6's responsibility to
auto-detect historical non-ES6 systems. If you
On Mar 22, 2013, at 7:47 PM, Brendan Eich bren...@mozilla.com wrote:
Kenneth Russell wrote:
I hope that the ES6 integration of typed arrays will not require
normalization of NaNs on write, even if other specification changes
need to be made to avoid requiring it.
What other specification
On Mar 20, 2013, at 1:57 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Mar 20, 2013, at 1:42 PM, Kevin Reid wrote:
That normalization on read is is my case 1 above — it is necessary _for that
implementation_. A conformant implementation could use a different strategy
which does
Patrick Walton send me this link to a fascinating approach to exploiting weak
references in engines using conservative stack scanning to discover the address
of objects:
https://github.com/justdionysus/gcwoah
I don't fully grok all the details, but IIUC the attacker sprays the heap with
Interestingly, I wonder if the idea of only collecting weak references between
turns is immune to such attacks, since it's not possible to have a bogus
reference on the stack between turns, where there is no stack.
Dave
On Mar 26, 2013, at 5:55 PM, David Herman dher...@mozilla.com wrote
On Mar 27, 2013, at 4:52 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Tue, Mar 26, 2013 at 11:44 PM, Oliver Hunt oli...@apple.com wrote:
That said I believe that this does kill any dreams i may have had w.r.t
primitive-keyed WeakMaps, kudos to MarkM.
Wouldn't a primitive-keyed
On Mar 27, 2013, at 6:51 AM, Andreas Rossberg rossb...@google.com wrote:
There actually are (third-party) projects
with ports of V8 and/or Chromium to big endian architectures.
It would be helpful to have more information about what these platforms and
projects are.
WebGL
code should not
On Apr 9, 2013, at 9:33 AM, Brandon Benvie bben...@mozilla.com wrote:
On 4/9/2013 9:27 AM, Anne van Kesteren wrote:
1) Given translation you're required to use CORS for cross-origin
fetching to protect intranets (unfortunate as that may be). So like
script src is out of the equation. This
Hi Kevin,
Thanks, I do agree with most of your points, but it doesn't take into account
anonymous export. I'm gonna bite the bullet here and tempt the bikeshedding
demons by making an incremental suggestion for a syntax for anonymous
import/export that adds to your syntax.
export default
On Apr 16, 2013, at 10:20 AM, Andreas Rossberg rossb...@google.com wrote:
On 16 April 2013 18:55, David Herman dher...@mozilla.com wrote:
I'm gonna bite the bullet here and tempt the bikeshedding demons by making
an incremental suggestion for a syntax for anonymous import/export that adds
On Apr 20, 2013, at 10:36 AM, Kevin Smith zenpars...@gmail.com wrote:
Yeah, but it's a false dilemma, I think. No trivial naming convention is
necessary, and no ad-hoc syntax is necessary. Asking the developer to name a
thing with a well-chosen identifier is completely reasonable in my
On Apr 20, 2013, at 5:17 AM, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
I don't understand. Are you saying that it has a higher cost to
standardize a trivial convention than it is to standardize additional
ad-hoc syntax?
Answering for Dave: you bet it is.
The cost
On Apr 20, 2013, at 9:21 PM, Mark S. Miller erig...@google.com wrote:
* Communicating Event Loop concurrency model,
- with the two-priority event loop already required by both browser and
server.
* Object.observe
* Distribution compatible promises (at least Promises/A+)
*
On Apr 21, 2013, at 8:55 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Deleting Object.prototype.__proto__ will not be be specified as disabling
{__proto__: foo}.
Was that what we'd agreed to? I hadn't remembered that. I don't like it because
it's special-case syntax, but I can also
On Apr 22, 2013, at 5:18 AM, Andreas Rossberg rossb...@google.com wrote:
I'm sorry, but I'm afraid this is one of these moments where I have no
idea what the heck you guys are talking about. ;)
The needs of the many outweigh the needs of the few. -- Mr. Spock
On Apr 22, 2013, at 6:48 AM, Andreas Rossberg rossb...@google.com wrote:
(And semantics, I presume, because
Dave hasn't actually told us how the anonymous export would be
distinguished internally.)
Yes I have! I've explained it before, at least at the March meeting and again
in passing in
On Apr 22, 2013, at 9:43 AM, Kevin Smith zenpars...@gmail.com wrote:
Dave, what do you think about the syntax tweaks I presented upthread?
I think it's okay. I could go into detail but I don't think it'll go well in
this thread, so I won't.
I feel pretty strongly that if we're going to do
On Apr 21, 2013, at 2:05 PM, David Bruant bruan...@gmail.com wrote:
Data ownership (like HTML5 Transferables or Rust unique pointers) is another
interesting track that covers different (also interesting) use cases in my
opinion.
Probably to be considered as part of the ES7/ES8 work on The
On Apr 25, 2013, at 4:08 PM, Claus Reinke claus.rei...@talk21.com wrote:
You argue for a two-level system of non-lexical names to support
configuration - okay. But why does that imply you have to drop
the lexical naming altogether, instead of using a three-level system
(from external to
On Apr 26, 2013, at 7:20 AM, Claus Reinke claus.rei...@talk21.com wrote:
You believe you have worked out the core parts that caused you to
postpone lexical modules,
We're still on the hook to finish a wiki-complete design of the core by the
May meeting. I'm a busy guy.
Dave
On Apr 26, 2013, at 7:27 AM, Kevin Smith zenpars...@gmail.com wrote:
What you propose, with logical names, is a global namespace of short
human-readable names with *no* conflict resolution authority. How do you see
that working? From a namespace perspective, how is that any different than
On Apr 29, 2013, at 6:34 AM, Andreas Rossberg rossb...@google.com wrote:
...you are generally assuming the use of some package manager. This
is a fairly significant assumption, that I wished I had heard being
made explicit in any of the previous discussions. AFAICT, it is key,
and without it,
On Apr 30, 2013, at 4:55 PM, David Herman dher...@mozilla.com wrote:
On Apr 30, 2013, at 7:25 AM, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
And as Andy points out correctly, that raises the question whether
having 'close' makes much sense at all.
I think we have
On May 2, 2013, at 6:25 AM, Andreas Rossberg rossb...@google.com wrote:
On 1 May 2013 02:06, David Herman dher...@mozilla.com wrote:
It also has a smell to it: the idea that an expression can cause a return,
without the syntactic appearance of `return`. (I'm not opposed to the idea
of being
On May 2, 2013, at 9:51 AM, David Herman dher...@mozilla.com wrote:
On May 2, 2013, at 6:25 AM, Andreas Rossberg rossb...@google.com wrote:
On 1 May 2013 02:06, David Herman dher...@mozilla.com wrote:
It also has a smell to it: the idea that an expression can cause a return,
without
Brendan reminded me I never replied to the earlier part of this thread.
On Apr 29, 2013, at 8:37 AM, Andy Wingo wi...@igalia.com wrote:
For what it's worth (which is very little) this seems like a decent
plan to me.
Actually it's worth a lot to me! Your blog post on StopIteration was part of
On May 8, 2013, at 7:39 AM, Andreas Rossberg rossb...@google.com wrote:
On 7 May 2013 21:17, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Thu, May 2, 2013 at 10:47 AM, Andreas Rossberg rossb...@google.com
wrote:
My point on the topic of external naming is that the language (1)
should not
On May 8, 2013, at 8:05 AM, Andreas Rossberg rossb...@google.com wrote:
You seem to believe otherwise, but I think you still need to explain
how any of the above cases is not sufficiently (or even superiorly)
supported by lexical modules + the loader API.
The most important flaw of this is
On May 13, 2013, at 10:51 AM, Andy Wingo wi...@igalia.com wrote:
If I'm implementing an iterator via a generator and I have to perform
a inner-iteration over an contained iterable (for example, some sort
of flattening operation) the way I code that inner iteration shouldn't
depend upon
On May 13, 2013, at 11:07 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
It closes down this whole edge-case focused discussion and that's valuable in
itself. Also, since it turns try {yield expr} finally{} into a syntax error
we could revisit the decision in a future edition if
On May 10, 2013, at 7:18 AM, Andreas Rossberg rossb...@google.com wrote:
Can you explain how one form of module declaration is easier to move
around? In a single script there surely is no difference.
Clients of a module can write:
import { f } from foo;
and regardless of how the module
On May 13, 2013, at 6:11 PM, Brendan Eich bren...@mozilla.com wrote:
We've been over this at least twice. Let's get it right. No close, yield in
try-with-finally ok.
+1
Merge next and send by letting next take an optional parameter? Ok by me.
+1
Make yield* work on any {next, throw}, not
On May 13, 2013, at 4:15 PM, David Herman dher...@mozilla.com wrote:
On May 13, 2013, at 11:07 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
It closes down this whole edge-case focused discussion and that's valuable
in itself. Also, since it turns try {yield expr} finally
On May 15, 2013, at 10:42 AM, Andreas Rossberg rossb...@google.com wrote:
(1) Change the set-up of .ondemand calls.
(2) Change the invocation of your bundling tool.
As soon as you have to go there, you've lost almost all advantages of
the ID-based declaration form. Its assumed convenience
On May 9, 2013, at 6:30 AM, Andreas Rossberg rossb...@google.com wrote:
In your scheme, I honestly cannot tell. Which ones are absolute
logical module names, which ones are relative logical module names,
and which ones are relative URLs?
I realized I left this sub-thread hanging. While I
On Jun 3, 2013, at 1:55 PM, Juan Ignacio Dopazo dopazo.j...@gmail.com wrote:
Now that it's been decided that braces are not a form of destructuring and
the colon replaced with `as`, what's the benefit of using braces? Why not
this previous proposal?
import foo as foofoo from foo;
On Jun 3, 2013, at 10:29 AM, Axel Rauschmayer a...@rauschma.de wrote:
Bikeshedding:
Well, here comes a fun thread...
Rationale:
– Reducing the grawlix factor.
– Making non-default imports more convenient – which I assume will happen
more often(?)
That's what this comes down to: do you
On Jun 3, 2013, at 9:33 AM, Yehuda Katz wyc...@gmail.com wrote:
On Mon, Jun 3, 2013 at 12:24 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: sam...@gmail.com [mailto:sam...@gmail.com] On Behalf Of Sam
Tobin-Hochstadt
I would just write `import {} from someModule;`
That
On Jun 3, 2013, at 12:24 AM, Domenic Denicola dome...@domenicdenicola.com
wrote:
Ah, that makes sense! It's a nice way of prohibiting `scriptexport function
foo() { }/script` as well, assuming inline `script` corresponds to
`Script`. It would be helpful to update the wiki with this, or more
On Jun 4, 2013, at 6:31 AM, Kevin Smith zenpars...@gmail.com wrote:
Looks good, but I'm thinking that this should probably _not_ be allowed:
import {,} from x;
Right you are! Fixed, thanks.
Dave
___
es-discuss mailing list
On Jun 5, 2013, at 11:51 AM, Kevin Smith zenpars...@gmail.com wrote:
It occurs to me that this is valid under the current grammar:
import { default as foo } from foo;
export { foo as default };
We've discussed using a well-known symbol for the default export, but this
simple
On Jun 5, 2013, at 3:59 PM, Axel Rauschmayer a...@rauschma.de wrote:
This makes a lot of sense. It would obviate the need for braces, right?
No, at least not for imports. This is only about exports. I'd argue we should
keep the braces on export { x, y, z } for symmetry with imports.
Dave
On Jun 6, 2013, at 11:05 AM, Axel Rauschmayer a...@rauschma.de wrote:
OK, so you don’t want to replace
import foo from single_export_module;
with (braceless!)
import default as foo from single_export_module;
That's correct, I don't want to use `import default`.
Dave
On Aug 8, 2013, at 7:09 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Aug 8, 2013 at 3:03 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
To me the answer always seemed obvious: use the slow-script dialog. What am
I missing?
That seems like a bad answer. Slow-script
On Aug 8, 2013, at 2:08 PM, K. Gadd k...@luminance.org wrote:
Why is the slow script dialog box even relevant for setImmediate? As I
understand it, setImmediate is equivalent to DoEvents in Visual Basic/Windows
Forms and pumping the message loop in a normal C application. That is, you
can
On Aug 4, 2013, at 8:01 AM, Axel Rauschmayer a...@rauschma.de wrote:
My guess: if you re-export something from a module, then you still have to
import it if you want to use it in that module. Is that correct?
Correct.
Examples of re-exporting:
export * from crypto;
On Aug 12, 2013, at 5:40 PM, François REMY francois.remy@outlook.com
wrote:
I don't think of you as unimaginative, but I think there are other options.
:)
Sure, there must be a way to kill a script that's burning your CPU but it
doesn't have to be a dialog.
That's fine, I guess I
On Aug 12, 2013, at 5:43 PM, David Bruant bruan...@gmail.com wrote:
- I see *no* reasonable alternative to runaway microtask churn other than
slow-script dialog.
So did Dominic [1]. I suggested something else [2] and he found the idea
interesting. What do you think?
Quoting you from
[2]
On Aug 12, 2013, at 6:32 PM, David Bruant bruan...@gmail.com wrote:
How do people recover today from when the user click stop script?
They don't; it's a crash -- the web equivalent of this application has stopped
responding. You might as well ask for a solution to the halting problem! :)
Dave
On Aug 14, 2013, at 9:54 AM, Dmitry Soshnikov dmitry.soshni...@gmail.com
wrote:
throws
to bind to undefined you would say:
var {p=undefined} = {};
OK, so it's turned out to be refutable nevertheless.
This is *not* what I remember of the conversation, at all.
My understanding was
On Aug 15, 2013, at 9:27 PM, David Herman dher...@mozilla.com wrote:
we couldn't really come to any conclusions without Brendan and Andreas there
My mistake, Brendan was there. It was only Andreas who wasn't there.
Dave
___
es-discuss mailing list
On Aug 20, 2013, at 1:31 PM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
[In this page](http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects),
and in the latest meeting note too, I can read both uint8 and Uint8, as
example.
Bug. Fixed, thanks.
**The Question**
How is
not
suitable for a lightweight migration to structure like logic)
Thanks.
On Tue, Aug 20, 2013 at 4:55 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Awesome, thanks!
On Tue, Aug 20, 2013 at 4:12 PM, David Herman dher...@mozilla.com wrote:
On Aug 20, 2013, at 1:31 PM
, Aug 20, 2013 at 4:12 PM, David Herman dher...@mozilla.com wrote:
On Aug 20, 2013, at 1:31 PM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
[In this
page](http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects), and in
the latest meeting note too, I can read both uint8
If necessary, i.e. if people want to release it before modules, we can make it
available in a single top-level object, but I would not at all favor dumping
everything onto the global scope.
Dave
On Aug 21, 2013, at 12:07 PM, David Herman dher...@mozilla.com wrote:
The intention has always
On Aug 21, 2013, at 12:49 PM, Dmitry Lomov dslo...@chromium.org wrote:
I really hope that uint64 from value type spec and uint64 from typed object
spec are one and same thing (we now in typed objects spec allow using
uint8/uint16/.. co to be used as conversion functions).
Agreed, and my
On Aug 21, 2013, at 2:36 PM, Brendan Eich bren...@mozilla.com wrote:
David Herman wrote:
Any, String and Object should still be uppercase. The naming convention is:
value types lowercase, reference types uppercase.
Is String really a reference type? Currently you can't tell, and JS docs
In Lisp it makes sense to allow binding keywords because there's no such thing
as a keyword: once you bind it, it's a variable and you can refer to it. In JS
it's impossible to refer to it as a variable so it's just an (un)attractive
nuisance.
The only place where I could see this being
On Aug 27, 2013, at 9:47 AM, Filip Pizlo fpi...@apple.com wrote:
I do. Placing named properties on arrays makes sense. Consider a matrix
implemented as a Float32Array, with named properties telling you the numRows
and numCols. Just one example.
There are of course other ways to achieve
On Aug 30, 2013, at 9:39 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I think the right-way to think about structs is as an record structure with
no properties fixed behavior provided by a wrapper. Very similar to the ES
primitives except that structs can be mutable. The way to
On Aug 30, 2013, at 12:46 PM, Filip Pizlo fpi...@apple.com wrote:
OK - by sanepants do you mean that there is no weirdo aliasing? Going back
to my example of field 'a' aliasing field 'b' - is it possible?
There is plenty of aliasing possible, but I'm trying to understand what you
mean
On Aug 30, 2013, at 3:46 PM, David Herman dher...@mozilla.com wrote:
E.g., if I have a struct type
var T = new StructType({ a: t1, b: t2, ... });
then for any given instance x of T, I know for sure that x.a and x.b do not
alias the same storage.
(Except, of course, if t1 and t2
On Aug 30, 2013, at 3:54 PM, Filip Pizlo fpi...@apple.com wrote:
Yup, that's what I was concerned about. And reading over the spec I agree.
But just for sanity, we're guaranteeing this because you cannot create a
struct type instance by pointing into an arbitrary offset of a buffer - you
On Aug 30, 2013, at 4:20 PM, Filip Pizlo fpi...@apple.com wrote:
This is the kind of weirdness that I hope struct types *don't* have, if their
alleged purpose is to help people optimize their code.
This is a great point, thanks. On the one hand, I concluded long ago the
exposure of the
Axel wrote:
The problem is that you have to bite the bullet of syntactic inconvenience
for either default imports or normal imports.
Correct. This is the #1 justification.
Rick wrote:
Subjectively, this is really hard to read, versus the curlies which provide a
visual boundary (also
On Sep 8, 2013, at 12:45 PM, Brendan Eich bren...@mozilla.com wrote:
Erik Arvidsson wrote:
Oh, I forgot about that wart.
Are default imports a wart no matter the syntax, or only because of this
brace imposition issue you've identified? If the latter, perhaps there is
another solution
On Sep 26, 2013, at 1:10 PM, François REMY francois.remy@outlook.com
wrote:
TLDR == The web needs a way to express executable code that does not rely
on its parent context, is guaranteed to be side-effect-free, and can be
executed safely anywhere (even in a different
On Sep 26, 2013, at 3:20 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Maybe the exception could be enumerability exception could be concise methods
with string literal property names that do not parse as IdentifierName.
http://www.youtube.com/watch?v=VX4DJUr5oYg
Dave
On Sep 26, 2013, at 3:48 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
I don't understand why this is happening. There was fairly strong consensus
on symbols at the last meeting, and nothing new has been brought to the
table. Why are people's opinions suddenly changing? Vague
On Sep 26, 2013, at 3:47 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Oh, that's not Hungarian notation, it's just a name space qualifier.
Don't talk down -- Rick was making a metaphor.
But, if you assume that we will added a real private state mechanism into ES
6.1 or ES6.2 will
So let's assume there is such a registry. You can avoid accidental collisions
with the ugliest name in the universe -- gensym that thing to the n'th degree
-- but you're no longer forcing all clients to deal with the ugliness. You've
abstracted it behind your library. Let's say I'm implementing
501 - 600 of 654 matches
Mail list logo
