On Nov 24, 2011, at 7:37 AM, David Bruant wrote:
Le 24/11/2011 16:04, Sam Tobin-Hochstadt a écrit :
You can't do the following:
import {new, delete} from @reflect;
because you can't bind `new' and `delete'. Even if this were allowed,
then `new(...)' would still be a syntax error.
Oh
On Nov 28, 2011, at 12:30 PM, Norbert Lindenberg wrote:
Sounds like RangeError is the one to use for the Globalization API. If I
don't hear objections, I'll remove ValueError from the spec, replace its uses
with RangeError, and file a ticket against the language specification to have
the
On Nov 29, 2011, at 2:34 PM, Allen Wirfs-Brock wrote:
On Nov 30, 2011, at 9:06 AM, David Herman wrote:
And then pedants like me will object to your interpretation of range in
this context. :) The way range is being used is as an interval, which is
common in CS, and not the same
On Nov 30, 2011, at 7:14 AM, Anton V. Yacenko wrote:
It's interesting to me why () syntax returns object, and why not {}.
I assume you're talking about generator expressions, which have the syntax of
array comprehensions but using parentheses as their outer delimiter. The idea
originally came
On Dec 16, 2011, at 11:52 AM, David Bruant wrote:
However, I have questions and concerns about the public counterpart.
Why does it exists?
It exists to prevent unintentionally leaking private names. When you have a
private name and you do a property get of another object, if that object
On Dec 17, 2011, at 4:04 AM, David Bruant wrote:
I propose to accept that o[n] may disclose 'n' if 'o' is a proxy.
This is just a non-starter. Then you can't use private names as private names.
(One good news is that mostly static analysis
can assist us in finding where we may disclose 'n'
Happy new year, everyone. I've got some good news.
There's been grumbling lately about the ES6 version opt-in [1]. The detractors
are not right about everything, but it's true that both the MIME type opt-in:
script type=application/ecmascript;version=6
...
/script
and the
On Dec 31, 2011, at 6:08 PM, Oliver Hunt wrote:
# What about eliminating the window from the scope chain?
Short answer: giving up.
I think we can drop the global object from the scope chain in ES. In the
context of the browser we need to come up with a way to trigger it.
Maybe. I don't
On Jan 12, 2012, at 2:23 PM, François REMY wrote:
If not (as it seems to me), it means that a block lambda will not be used as
a statement by itself. If it's the case, it should defined as an Expression
only, where there's no anonymous block to conflict the syntax. That solution
has been
On Jan 13, 2012, at 4:27 AM, François REMY wrote:
To be useful, I think the behavior should be
(1) yes
(2) yes
(3) doesn’t happen; see 2.
(4) doesn’t happen; see 2.
That's correct. The return is bound to getAnyWhere and breaks out of the
forEach loop.
However, it seems rather complex
On Jan 13, 2012, at 9:04 PM, Axel Rauschmayer wrote:
I think it’s a valid concern. The idea is: If I can implement my own loops
(the nice-looking paren-free syntax feeds that illusion!) then I also want
those loops to have break and continue. You could statically determine what
construct,
On Jan 15, 2012, at 11:32 PM, Axel Rauschmayer wrote:
Could we call block lambdas just lambdas? The former seems a bit pleonastic.
Block lambdas is a proposal that combines block-based syntax with lambda-based
semantics. There have been other proposals in the past which provide lambda
On Jan 16, 2012, at 11:09 AM, Brendan Eich wrote:
With completion values as In ES1-5, not even depending on
http://wiki.ecmascript.org/doku.php?id=harmony:completion_reform, it might be
enough to say:
foo {||
exit: {
...
if (...) {
On Jan 16, 2012, at 5:47 PM, Allen Wirfs-Brock wrote:
One of the thing that an ES6 (or extended code as it is currently known
in the ES6 draft) mode that is distinct from strict mode does is allow us
do add additional Early Errors that aren't in ES5 for various existing
constructs. It
On Jan 16, 2012, at 6:00 PM, Allen Wirfs-Brock wrote:
On Jan 16, 2012, at 5:49 PM, David Herman wrote:
On Jan 16, 2012, at 5:47 PM, Allen Wirfs-Brock wrote:
One of the thing that an ES6 (or extended code as it is currently known
in the ES6 draft) mode that is distinct from strict mode
On Jan 16, 2012, at 10:30 PM, Axel Rauschmayer wrote:
Lastly, there is one aspect of automatic language version detection that I
still don’t understand: With David Herman’s solution, I’d expect browsers to
first scan all of the code and then determine what semantics to use (at least
On Jan 28, 2012, at 8:04 PM, Mark S. Miller wrote:
Can we leave magical out of a spec convo?
It was intended only for humorous emphasis. But even magical and non
magical would be less confusing than the current terminology!
In some PL research circles, they use exotic as a somewhat less
On Feb 13, 2012, at 4:03 PM, Rick Waldron wrote:
I speak for myself and my colleagues when I say that we've had our fill of
including scripts _just_ for the sake of having a common testing interface.
A reasonable point. OTOH, I wouldn't want to over-engineer. And the larger the
API, the
On Feb 13, 2012, at 6:43 PM, Dean Landolt wrote:
On a related note: has anyone given any thought to what shims should do about
emulating @std modules? Or is there a programmatic loader API that's easy
enough to shim in? That would make this kind of cowpath-paving far more
fruitful.
On Feb 28, 2012, at 12:53 PM, Xavier MONTILLET wrote:
I don't think we should care about old brosers when building ES 6. People
won't use just one part of it. They'll use all of it or just stick with ES
5/3.
I'm afraid this is simply false.
Dave
On Feb 28, 2012, at 4:22 PM, Yehuda Katz wrote:
However, this means that all downstream users would need to use ['delete']
something that is sufficiently weird and confusing to new developers that we
always avoid it.
Which should be enough reason for us to avoid it in standard libraries as
On Mar 3, 2012, at 2:24 AM, Axel Rauschmayer wrote:
let sub = sup : {p:1, q:2};
This one has been one my least-objectionable options.
let sub = sup ~ {p:1, q:2};
Doesn't work; ~ is a unary operator.
let sub = sup {p:1, q:2};
Has a pretty strong not equal to connotation.
let sub = sup
On Mar 3, 2012, at 6:54 AM, Dean Landolt wrote:
I like, though + is a little easier on the eyes.
Ambiguous. + is a unary operator.
One argument for the wrong direction being wrong: if A : B is common math
syntax for A is a subtype of B, if you turn the arrow around it'd read A is a
On Mar 3, 2012, at 1:28 PM, Quildreen Motta wrote:
- sounds too much like return (local or not).
And it's ambiguous. - is a unary operator.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Mar 3, 2012, at 3:24 PM, Dean Landolt wrote:
On Sat, Mar 3, 2012 at 5:20 PM, David Herman dher...@mozilla.com wrote:
This argument seems to over-reach. C and C++ use - for pointer indirection.
Perl uses - for method calls.
This is precisely why it can't really be overloaded any further
On Mar 2, 2012, at 4:31 PM, Luke Hoban wrote:
What do you think? Do you like - better than | ? Is it ok to not have it
available for some possible future function shorthand?
Using - for the proto-of operator effectively also removes the ability to
use = as function shorthand later, due
On Mar 6, 2012, at 12:37 PM, Brendan Eich wrote:
Isaac Schlueter wrote:
Certainly, this is quite nice:
myList.forEach((item) { .. })
Less nice for map because of the hated six-letter keyword, but yeah.
What if the anonymous form didn't require `return`, i.e., used the body's
On Mar 6, 2012, at 1:50 PM, Brendan Eich wrote:
Just replied to Isaac on this. We run into the completion-value leak
objection and I do not see a way around it.
One way around it is to question the hazard. :)
Seriously, whether
{|x| f() }
or
(x) { f() }
is more likely to be an
On Mar 6, 2012, at 1:55 PM, Brendan Eich wrote:
The risk here may be small but people have run into it before in CL and other
LISPs and expression languages. It's a bit scary in JS, what with OCAP the
fundamental security model. So I don't think we should treat it lightly and
TC39 has not,
On Mar 6, 2012, at 2:30 PM, Rick Waldron wrote:
Here's where the foot goes in the mouth... Why couldn't ()[no
LineTerminatorHere]{} be used with block lambda's semantics?
I'm sayin'. :)
Seriously, though, Brendan's objecting (as MarkM has in the past) that
(x) { f(x); }
is more likely
On Mar 6, 2012, at 2:37 PM, Brendan Eich wrote:
You didn't show the expression-bodied variant:
myList.map((x) x + 1)
which is even shorter, if it's doable at all (I haven't worked out a good
grammar yet).
That's actually a pretty good space to aim at, IMO. I conjecture the majority
On Mar 6, 2012, at 2:56 PM, Brendan Eich wrote:
David Herman wrote:
Moreover, if you wanted to do some control along with an expression, you
could use do-expressions:
myList.map((x) do { for (...) { ... } f(x) })
Note that combination (expression closures + do-expressions) brings
On Mar 8, 2012, at 9:27 AM, Mike Samuel wrote:
http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders mentions
a system module loader.
Has the behavior of the system module loader been speced at all?
Not really. The plan is to leave it mostly unspecified; it's sort of the
Pineal
http://www.youtube.com/watch?v=Xm_7FLKRS4Y
Dave
On Mar 8, 2012, at 2:23 PM, Andreas Rossberg wrote:
Today, I came up with this odd way to implement an isOdd predicate in
tentative ES6, and thought I share it:
function isOdd(n) {
let is = n isnt n;
return eval(Array(2 * n).join(is ) +
I can mostly dig it -- I've been trying to encourage minimal classes for quite
some time now.
The part that I'm least happy about is that this doesn't allow for declarative
private methods, because if we had the computed syntax like what we're adding
to object literals, it would clash with
On Mar 20, 2012, at 6:59 PM, Allen Wirfs-Brock wrote:
On Mar 20, 2012, at 11:55 AM, David Herman wrote:
The part that I'm least happy about is that this doesn't allow for
declarative private methods, because if we had the computed syntax like what
we're adding to object literals, it would
Technically you don't even need typed arrays to do it; it's just more work to
implement a pure library that extracts the bit strings. With typed arrays it
was utterly trivial (though you have to be slightly careful to avoid writing
unportable code.)
FWIW.
Dave
On Mar 21, 2012, at 12:00 AM,
On Mar 20, 2012, at 3:55 PM, Allen Wirfs-Brock wrote:
I don't actually see how this is substantially different, in concept from Sam
Ruby's decimal work.
I assume you mean this?
https://mail.mozilla.org/pipermail/es-discuss/2008-September/007466.html
The important difference here is that
Sorry for the delay. Yes, good catch. Your fix looks good to me. I'm updating
the module syntax on the wiki today, and I'll incorporate your fix. I'll send a
message to es-discuss when it's updated.
Thanks!
Dave
On Mar 6, 2012, at 4:39 PM, Xavier CAMBAR wrote:
Hi all,
I was looking at the
H'lo,
Thanks to some a-maz-ing [1] work by Andreas Rossberg (I'll spare the gory
algorithmic details), the linking process no longer needs the syntactic
distinction that static module bindings are only created via the `module`
(contextual) keyword. This frees us up to simplify the syntax,
On Mar 21, 2012, at 3:44 PM, Luke Hoban wrote:
Great to see the updates. A couple of questions:
import foo.js as Foo;
import foo from foo.js;
These two forms look rather confusingly similar given how different they are,
and the inversion of order of where the filename lives doesn't
On Mar 21, 2012, at 4:25 PM, Kris Kowal wrote:
On Wed, Mar 21, 2012 at 4:05 PM, Axel Rauschmayer a...@rauschma.de wrote:
Honest question: Are nested modules really needed?
There is a chance that they would be useful for bundling. Modules
can’t be concatenated.
Yeah, I believe that's the
On Mar 21, 2012, at 9:28 PM, John J Barton wrote:
equals makes sense when it is assigment:
module Bar = load(bar.js);
It's not an assignment, though. Which is why Brendan didn't like it in the
first place, since he felt programmers would get confused that it was a dynamic
assignment
On Mar 21, 2012, at 9:41 PM, Brendan Eich wrote:
Perhaps Python has the right syntax, then?
from foo.js import foo;
import foo.js as Foo;
I suppose we could. I always thought this was an awkward choice on Python's
part. The first line always reminds me of the Yinglish constructions my
On Mar 22, 2012, at 4:55 AM, Andreas Rossberg wrote:
One point that I haven't seen mentioned yet (and it is unrelated to syntax):
export call makes me cringe -- making modules callable is not just weird,
it seems completely future-hostile to the possibility of having parameterized
modules.
On Mar 22, 2012, at 4:46 AM, Andreas Rossberg wrote:
Nice! One question: is there a reason why you not just define
Program ::= ModuleBody
?
No exports from a Program.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
On Mar 22, 2012, at 4:48 AM, Andreas Rossberg wrote:
On 22 March 2012 07:33, Brendan Eich bren...@mozilla.org wrote:
But why make misleading syntax? More of a question for John: why write
|load(bar.js)| there, looking for all the world like a function call
evaluated in order at runtime,
On Mar 23, 2012, at 9:14 AM, Allen Wirfs-Brock wrote:
This would be a new kind of Temporal deal zone. I don't think we need it.
Agreed.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Mar 23, 2012, at 5:05 PM, Irakli Gozalishvili wrote:
I'v being trying to figure out how ES.next module path resolution would work.
Unfortunately proposal is not very clear about it:
http://wiki.ecmascript.org/doku.php?id=harmony:modules
There's more info about the resolution semantics on
On Mar 23, 2012, at 1:17 PM, Brendan Eich wrote:
class Point extends Evil {
constructor(ax, ay) {
public x, y;
super();
this.x = ax;
this.y = ay;
}
...
}
class Evil {
constructor() {
console.log(this.x);
}
}
Should undefined by
On Mar 21, 2012, at 9:13 AM, Allen Wirfs-Brock wrote:
On Mar 20, 2012, at 11:32 PM, David Herman wrote:
Well, hang on now. The 'constructor' syntax is not just the constructor
property. It still carries special status; the semantics of a class says
look for the property called
On Mar 23, 2012, at 11:45 AM, Roger Andrews wrote:
Concerning UTF-16 surrogate pairs, how about a function like:
String.isValid( str )
to discover whether surrogates are used correctly in 'str'?
Something like Array.isArray().
No need for it to be a class method, since it only
On Mar 23, 2012, at 6:30 AM, Steven Levithan wrote:
I've been wondering whether it might be best for the /u flag to do three
things at once, making it an all-around support Unicode better flag:
+all my internet points
Now you're talking!!
1. Switches from code unit to code point mode.
Presumably the JS source, as a sequence of UTF-16 code units, represents the
tetragram code points as surrogate pairs.
Clarification: the JS source *of the regexp literal*.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
On Mar 24, 2012, at 3:01 PM, Nadav Shesek wrote:
What about setting arbitrary expressions as the value for prototype methods?
Being able to use higher-order functions to dynamically create functions is
very important for functional style programming. I use it very often to
decorate
On Mar 24, 2012, at 5:54 PM, Allen Wirfs-Brock wrote:
I primarily favor sticking with constructor because the
safety/maximally-miminal proposal is all about being conservative...
I think you'll find what I'm saying is as conservative as what you've been
advocating. Your reply demonstrates
On Mar 24, 2012, at 11:23 PM, Norbert Lindenberg wrote:
On Mar 24, 2012, at 12:21 , David Herman wrote:
I'm still getting up to speed on Unicode and JS string semantics, so I'm
guessing that I'm missing a reason why that wouldn't work... Presumably the
JS source of the regexp literal
On Mar 24, 2012, at 10:20 PM, Allen Wirfs-Brock wrote:
On Mar 24, 2012, at 7:29 PM, Brendan Eich wrote:
I suspect Dave misinterpreted Nadav's question. So did I, when I originally
read it.
Oh, yes, thanks for the clarification. I thought he was talking about the
superclass position, but
On Mar 24, 2012, at 10:54 PM, Brendan Eich wrote:
It's the right trade-off, and not just to get appropriately minimal classes
into ES6 -- the computed method case is often part of a generative framework
anyway, so won't obviously fit into any general, declarative syntax.
Since we've gone
On Mar 25, 2012, at 10:30 AM, Brendan Eich wrote:
Still, I prefer to defer anything like the above (and of course, defer the
better traits thinking you showed).
Yep, definitely.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
On Mar 26, 2012, at 10:32 PM, Brendan Eich wrote:
This is actually one of the reasons I still come down on constructor over
new - I'd really like to discourage screwing around with
ctor.prototype.constructor. That always felt like a major wart IMO. Making
it ReadOnly/DontDelete would be
On Mar 27, 2012, at 9:14 PM, Russell Leggett wrote:
I'm sure this is a bit of a tangent, but the other major related case is
passing a method as an argument but needing to retain the correct this.
Obviously, that is what bind was meant for, but that is inconvenient when
passing methods for
On Mar 29, 2012, at 6:23 AM, Domenic Denicola wrote:
Bigger question: It sounds like TCP was sacrificed in favor of maximal
minimalism, which makes sense.
No, maximal minimalism is not our universal principle for ES6. It's important
for classes, for various reasons, but it's not our approach
On Mar 28, 2012, at 2:19 PM, Erik Arvidsson wrote:
With your proposal I have to do let f = obj.foo;
obj::f which is even longer than the original.
That's not a fair argument. There's no need for the let-binding; you can write
obj::obj.foo
or
::obj.foo
Now, you might feel that it's
On Mar 30, 2012, at 7:42 AM, Claus Reinke wrote:
DaveH's presentation about module loaders
Shouldn't any newly designed async loading APIs support promises?
No, for the very simple reason that promises have not been standardized and
won't be in ES6.
For ES proposals, promises seem to be
Hi James,
1) Multiple mrls for System.load():
System.load(jquery.js, underscore.js, function ($, _) {})
or
System.load([jquery.js, underscore.js], function ($, _) {})
Makes sense. The former is a bit muckier but more convenient than the latter.
I'll play with the alternatives, thanks.
---
Benefits of compile time binding
---
This is what I need help in understanding. The benefits I have heard so far:
1) Being able to check export names/types. As mentioned, this feels
like a very shallow benefit, since it does not apply to properties
outside of the
On Mar 31, 2012, at 6:47 PM, David Herman wrote:
This can be and has been done in other dynamically typed languages [1], and
it can be done for JS, too.
[1] http://www.ccs.neu.edu/home/stamourv/papers/numeric-tower.pdf
___
es-discuss mailing list
es
On Mar 31, 2012, at 11:11 AM, James Burke wrote:
We should try for the equivalent of import *, sorry if I was too short
on this point. I'll expand what I meant:
I think it should be a runtime-like thing (probably using the wrong
word there), and just allow it for any object via
On Apr 7, 2012, at 1:40 PM, Erik Arvidsson wrote:
This does not work for rest parameter since ... is only allowed inside
array literals.
var tail = (x, ...xs) = xs;
This can of course be solved in numerous ways but it is not true that
the Expression is a cover grammar for
On Apr 13, 2012, at 10:53 AM, Allen Wirfs-Brock wrote:
On Apr 13, 2012, at 10:10 AM, Brendan Eich wrote:
In general, delegation (depth D) plus optionality (degree N paramters) makes
an (2N)^D worst-case combinatorial explosion.
This is IMHO a strong argument for a sentinel in-language to
On Apr 13, 2012, at 9:38 AM, Russell Leggett wrote:
Yes, but as I said, and Erik pointed out is in the wiki, it is a lot more
likely that someone would pass f(foo) or f(obj.foo) where foo might be
undefined.
Bingo.
Expecting undefined as a possible valid argument (as opposed to a missing
On Apr 13, 2012, at 11:35 AM, Oliver Hunt wrote:
What happens if i have:
function foo(a=1, b=2) { log(a, b, arguments.length); }
foo();
1, 2, 2
foo(undefined);
1, 2, 1
foo(3);
3, 2, 1
foo(undefined, undefined);
1, 2, 2
foo(undefined, 3);
1, 3, 2
foo(3, undefined);
3, 2, 2
On Apr 13, 2012, at 11:46 AM, Allen Wirfs-Brock wrote:
On Apr 13, 2012, at 11:22 AM, David Herman wrote:
On Apr 13, 2012, at 10:53 AM, Allen Wirfs-Brock wrote:
That sentinel could simply be a empty argument position:
new Intl.Collator( , {usage: search});
That's not enough
On Apr 13, 2012, at 11:51 AM, Allen Wirfs-Brock wrote:
both sides of this debate seem a little smelly. But, Pretending that
undefined isn't a real value seems more smelly to me.
There's no need to think of it as pretending it's not a real value. Think of it
as saying that the undefined value
On Apr 13, 2012, at 11:48 AM, David Herman wrote:
On Apr 13, 2012, at 11:35 AM, Oliver Hunt wrote:
What happens if i have:
function foo(a=1, b=2) { log(a, b, arguments.length); }
foo();
1, 2, 2
Oops: 1, 2, 0
Dave
___
es-discuss mailing
On Apr 13, 2012, at 12:05 PM, Oliver Hunt wrote:
On Apr 13, 2012, at 11:48 AM, David Herman dher...@mozilla.com wrote:
On Apr 13, 2012, at 11:35 AM, Oliver Hunt wrote:
foo(undefined);
1, 2, 1
Uh what? I pass no arguments and arguments.length is 2, and i pass one
argument
Hi Xavier,
It's great to see this project! I'll take a closer look soon. I will see if I
can help contribute to this.
Dave
On Apr 18, 2012, at 5:20 AM, Xavier CAMBAR wrote:
Hi,
I wanted to announce that I've been working on a project called Shepherd
Agreed. This is easy to spec and implement, highly composable (it fits neatly
into the algebra of destructuring patterns everywhere, as opposed to just in
object property-name positions), has no problems with side effects, and does
not violate restrictions that IINM strict mode is supposed to
On Apr 19, 2012, at 2:18 PM, Allen Wirfs-Brock wrote:
//initialize some variable with default objects
let {
unidentifedAdult: mom,
unidetifiedAdult: dad,
unidentiedChild: brother,
unidentifiedChild: sister
} = peopleConstants;
why is this less desirable than:
On Apr 21, 2012, at 1:38 PM, Angus Croll wrote:
a function shouldn’t work radically (and silently!) different depending on
how it is invoked
every current JS function behaves exactly this way :-)
No, not at all. What Axel is saying is that you're proposing a new distinction
that *does not
On Apr 23, 2012, at 2:45 PM, David Herman wrote:
You cannot distinguish whether a function was called as a method, as a
function, or via .call/.apply. There's no way to tell.
PS Well, there's stack inspection, but we're all grownups here.
Dave
On Apr 23, 2012, at 3:53 AM, Alex Russell wrote:
This means that most users of most functions can still use .call() and
.apply() without apprehension. Functions are still just functions.
You're assuming your conclusion: that there's some sort of platonic ideal
(just functions) of JS
On Apr 23, 2012, at 2:44 PM, Brendan Eich wrote:
Brendan Eich wrote:
Without arguments runtime semantic shifts, and with |this| lexical, there
aren't many strict mode changes left IIRC, and they are pretty edgy edge
cases.
True enough, but I hang tough on wanting arrows to imply
On Apr 24, 2012, at 9:51 AM, Rick Waldron wrote:
On Tue, Apr 24, 2012 at 12:33 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Apr 23, 2012 at 3:36 PM, David Herman dher...@mozilla.com wrote:
box = {
_value: 0,
get: () - this._value,
set(v) { this._value
On Apr 24, 2012, at 10:03 AM, Tab Atkins Jr. wrote:
There doesn't seem to be a need there for thin-arrow (dynamic this) functions.
(Edit: Oh, I see, leaning on the completion value of thin-arrow
functions here lets you shave a few characters off. The readability
loss of mixing the two
On Apr 24, 2012, at 2:09 PM, Allen Wirfs-Brock wrote:
On Apr 24, 2012, at 1:40 PM, David Herman wrote:
On Apr 24, 2012, at 10:03 AM, Tab Atkins Jr. wrote:
There doesn't seem to be a need there for thin-arrow (dynamic this)
functions.
(Edit: Oh, I see, leaning on the completion value
On May 8, 2012, at 9:19 AM, Rick Waldron wrote:
non-strict, non-opt-in:
typeof null === null; // false
implied opt-in:
Changing typeof null always seemed questionable to me in terms of value. It
doesn't really give you significant new functionality, it just kinda seems
more sensible.
On May 10, 2012, at 1:05 AM, Brandon Benvie wrote:
On this tangent, I personally almost always mean isArrayish in this very
common situation. That is, indexed with a length such that almost all
Array.prototype methods would work on it out of the box. The number of
arrayish interfaces
On May 22, 2012, at 9:29 AM, Erik Arvidsson wrote:
I think this proposal has one fatal flaw and that was what brought it
down the last time we had a proposal which used the same concepts.
Given:
class C(x) {
public method() {
return x;
}
}
It seems like the arguments to the
These are a combination of my edits of Rick's notes from the first topic, my
notes from subsequent topics, and then my reconstruction from memory of the
conversation on the last topic. So for those present, please feel free to
correct the record.
Dave
On May 29, 2012, at 9:33 AM, Tab Atkins Jr. wrote:
Same thoughts here. Regular devs (like me!) only see
[[DefineOwnProperty]] when creating a literal, and then there's no
observable distinction between these two in normal circumstances:
Bingo. The different between [[DefineOwnProperty]] and
On May 29, 2012, at 9:59 AM, Nicholas C. Zakas wrote:
var element = document.getElementById(myDiv);
element.{
innerHTML: Hello world!,
className: enabled
};
Great example. With my proposed operator, it would instead be:
var element = document.getElementById(myDiv);
element.{
On May 29, 2012, at 10:08 AM, Tab Atkins Jr. wrote:
Given that these two are identical to most devs, giving them distinct
syntaxes in the strawman is problematic. Further, and much more
importantly, [[DefineOwnProperty]] is *nearly never* the behavior that
a dev will actually want. Devs are
On May 29, 2012, at 10:56 AM, Allen Wirfs-Brock wrote:
On May 29, 2012, at 10:08 AM, Tab Atkins Jr. wrote:
If it's desperately important that we don't make obj.{foo:bar} do a
[[Put]], then it would be much better to simply not allow that syntax
*at all*. ...
Language design and extension
On May 30, 2012, at 2:48 PM, Herby Vojčík wrote:
You need (need in the sense having readable construct to perform) .{...}
with [[DefineOwnProperty]] not for foo:bar (yes, there [[Put]] should
happen), but for dynamically adding concise methods and/or getters/setters to
objects.
Using
On May 29, 2012, at 9:00 PM, Russell Leggett wrote:
On Tue, May 29, 2012 at 11:52 PM, John Tamplin j...@google.com wrote:
On Tue, May 29, 2012 at 11:50 PM, Yehuda Katz wyc...@gmail.com wrote:
I'm not sure if this makes sense, but something about breaking `call` and
`apply` doesn't sit right
On May 30, 2012, at 2:18 PM, Mark S. Miller wrote:
However, there might be some utility (at least for debugging) in having a
Function.prototype.isThisBound method. It would return true for arrow
functions and functions created via Function.prototype.bind
I agree that such a predicate
On May 30, 2012, at 3:16 PM, Herby Vojčík wrote:
I can read literal extension in the same way: this is a bunch of data, make
the receiver object contain that data in it.
OK, but that agrees with my point, which is that the : doesn't carry an
operational connotation. To be specific, if the
On May 30, 2012, at 3:23 PM, Mark S. Miller wrote:
Independent of name, I'm trying to test for might sense this.
OK, but that begs the question. The problem is that your might test is
neither sound (as Allen pointed out) nor complete (as I pointed out) for can.
What guarantee are you trying
301 - 400 of 654 matches
Mail list logo
