Re: ES6 doesn't need opt-in
> Right. Maybe the operator should have a different name. "isDefined"? "has a > value" expressed as an operator name? > > isDefined x > > would be syntactic sugar for > > typeof x !== "undefined" && x !== null > > The expression would not throw an exception if x hasn’t been declared. > > > What about adding CoffeeScript's existential operator? It behaves in the > exact same way - `x?` desugars into `typeof x !== "undefined" && x !== null`. > Could be nice to have that as part of ES.next. > > One more important reason to add this (whether as `x?` or as a regular > operator) is that it can't be implemented in user-land code (calling it with > a non-existing variable would cause a ReferenceError). +1 ?? has been suggested by Crockford (if you include Eich’s suggestion to check for null, as well). http://wiki.ecmascript.org/doku.php?id=strawman:default_operator ?? would work better than ? in JavaScript, because it wouldn’t clash with the conditional operator in JavaScript (which CoffeeScript doesn’t need, due to its functional if statement). Then the thing to add to the proposal would be ?? used as a unary postfix operator: if (x??) ... Prefix might work, too. -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
On Jan 1, 2012, at 5:12 AM, David Bruant wrote: > Moreover, the concept of static scoping and "just look at the code to see if > a variable is declared" is not that obvious for newcomers to the language or > newcomers to programming. It's not obvious if the static scope is built up from element to successive
Re: ES6 doesn't need opt-in
[Dave has been traveling, hope it's ok for me to jump in. /be]
On Jan 2, 2012, at 6:07 AM, Andreas Rossberg wrote:
> In other words, I think the main points of your proposal can
> essentially be rephrased to:
>
> 1) Rename "use version 6" to "use module".
> 2) Allow module declarations in classic mode.
[Replying to (1) and (2) here:]
Not just module declarations -- all new syntax that is not
backwards-incompatible: destructuring, rest/spread, for/of ,generators,
comprehensions, generator expresions, quasiliterals, more.
> 3) Make every module body start with an implicit "use module".
That's not right: use module; in a pragma turns the enclosing block or body
into a module {...}, in a macro-like way. Then if the module {...} is illegal
in the given context (i.e., not nested immediately in another module's body),
you get the same error you'd get trying to write, e.g.,
if (cond) { module { /* stuff */ } }
> 4) Keep the semantics of the top-level scope unaltered, even in
> presence of a top-level "use module".
No, see above: that turns the verbatim top level into the ... part of module
{...}.
> I'm fine with (1) to (3), but (4) seems to be a separate design choice.
With what I wrote above in mind, what do you think now?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
>>({ define: typeof define === "function"
>>? define // browser
>>: function(F) { F(require,exports,module) } }). // Node.js
>>define(function (require, exports, module) {
>>// Node.js module code goes here
>>});
> Sure, but in that case the test
> typeof define === 'function'
> tests the value that the variable 'define' references. It does not test if
> "define' has been declared.
I’m not completely sure I understand what you mean.
typeof define === "function"
- Node.js: variable "define" has not been declared. Because of that, typeof
define is "undefined" and the expression is false.
- Browser + RequireJS: There is a global variable "define" whose value is a
function. Hence typeof define is "function" and the expression is true.
> The exists operator would work as follows (slightly edited from a previous
> email):
>
> console.log(exists globalUnknown); // false
>
> // undefined and null in several variations
>
> var myvar;
> console.log(exists myvar); // false
>
> Well myvar is declared so how can exists be false?
Right. Maybe the operator should have a different name. "isDefined"? "has a
value" expressed as an operator name?
isDefined x
would be syntactic sugar for
typeof x !== "undefined" && x !== null
The expression would not throw an exception if x hasn’t been declared.
The two most important use cases for typeof probably are:
- isDefined
- Helping to implement getTypeName() whose results are
- "null", "undefined", "boolean", "number", "string" for primitive values
- [[Class]] for objects ("String", "Date", etc.)
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Suggestion: Array.prototype.repeat
On Mon, Jan 2, 2012 at 5:55 PM, Adam Shannon wrote: > Another thing to think about is that .repeat (both on String and > Array) will be used a lot in production. So it would make sense for > each solution to be optimized for their specific case. It doesn't make > sense to slow down something as trivial as .repeat() > Creating a 1 item array by repeating a 1000 item array 10 times, the difference is negligible when compared the implementation that I wrote, not the one given above http://jsperf.com/array-repeat/2 Also, note that I had to "make up" my own Array.repeat() because the Array.generate shown above did not create the same return as the initial Array.prototype.repeat(), but I stuck to the concepts laid out - no new array is initialized (except that Array.prototype.slice _does_ initialize a new Array() ). Rick > > On Mon, Jan 2, 2012 at 16:51, Michael A. Smith > wrote: > > On Mon, Jan 2, 2012 at 3:56 PM, Mariusz Nowak > > wrote: > > > >> I like it, it indeed looks very logical, however it's a bit > controversial > >> that we need to create temporary array object to get one that we want. > >> Function (not method) that returns generated array may make more sense… > > > > Is the difference in overhead between instantiating a new array and > > using Array.prototype.slice.call on arguments really worth sacrificing > > consistency with the proposed string.prototype.repeat and the very > > clean syntax of someArray.repeat(n)? > > > > Michael A. Smith > > Web Developer > > True Action Network (an eBay company) > > ___ > > es-discuss mailing list > > es-discuss@mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > > > > -- > Adam Shannon > Web Developer > University of Northern Iowa > Sophomore -- Computer Science B.S. & Mathematics > http://ashannon.us > ___ > 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: Suggestion: Array.prototype.repeat
On Mon, Jan 2, 2012 at 3:56 PM, Mariusz Nowak <
medikoo+mozilla@medikoo.com> wrote:
>
> I like it, it indeed looks very logical, however it's a bit controversial
> that we need to create temporary array object to get one that we want.
>
Is the controversy editorial or fact, because the following methods are all
specified to use a temporary, newly initialized Array internally:
Array.prototype.concat
Array.prototype.filter
Array.prototype.map
Array.prototype.slice
Array.prototype.splice
String.prototype.match
String.prototype.split
RegExp.prototype.exec
Object.getOwnPropertyNames
Object.keys
> Function (not method) that returns generated array may make more sense,
> currently I'm using something like that:
>
> var slice = Array.prototype.slice;
>
> Array.generate = function (length, fill) {
>var arr, l;
>length = length >>> 0;
>if (arguments.length < 2) {
>throw new TypeError("Cannot generarte an array without
> provided fill.");
>}
>arr = slice.call(arguments, 1, 1 + length);
>while ((l = arr.length) < length) {
>arr = arr.concat(arr.slice(0, length - l));
>}
>return arr;
> };
>
This doesn't produce the same as Array.prototype.repeat..
// regular
console.log( Array.generate( 3, [1,2,3] ) );
// sparse
console.log( Array.generate( 3, [1,2,,3] ) );
[ [ 1, 2, 3 ], [ 1, 2, 3 ], [ 1, 2, 3 ] ]
[ [ 1, 2, , 3 ], [ 1, 2, , 3 ], [ 1, 2, , 3 ] ]
>
> ( https://github.com/medikoo/es5-ext/blob/master/lib/Array/generate.js )
>
> --
> Mariusz Nowak
> https://github.com/medikoo/
>
>
> rauschma wrote:
> >
> > Array.prototype.repeat seems like a logical dual to
> > String.prototype.repeat:
> >
> http://wiki.ecmascript.org/doku.php?id=harmony:string.prototype.repeat
> >
> > Implementation:
> >
> > Array.prototype.repeat = function (times) {
> > var result = [];
> > var len = this.length;
> > var resultLen = len * times;
> > for(var i = 0; i < resultLen; i++) {
> > result.push(this[i % len]);
> > }
> > return result;
> > }
> >
> > In use:
> >
> > $ [1,2,3].repeat(3)
> > [ 1, 2, 3, 1, 2, 3, 1, 2, 3 ]
> >
> > --
> > Dr. Axel Rauschmayer
> > a...@rauschma.de
> >
> > home: rauschma.de
> > twitter: twitter.com/rauschma
> > blog: 2ality.com
> >
> >
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
>
>
> -
> Mariusz Nowak
>
> https://github.com/medikoo
> --
> View this message in context:
> http://old.nabble.com/Suggestion%3A-Array.prototype.repeat-tp33067649p33068241.html
> Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
> Nabble.com.
>
> ___
> 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: ES6 doesn't need opt-in
Hey Dave,
I'm definitely in favour of removing the opt-in (or at least commonly removing
the need to opt-in), and support the goal of one JS. Since most of the new
syntax only relies on reserved words and, as Brendon stated, yield is only
valid in function* constructs, the only problem so far as new syntax is
concerned would seem to be `let`? Given how fundamental `var` is to writing a
program in JS, if we intend `let` to be the new `var` then it would be a huge
loss if this was the one new piece of syntax that wasn't available to all code.
Other than an ASI issue, which we can fix with a no-LineTerminator-here (as for
module), I think we can just treat `let` as a contextual keyword in classic
code, and it should be completely backwards compatible? I don't believe any
statement beginning with:
`let` Identifier
or
`let` {
could have been valid ES5 syntax anyway. The situation for:
`let` [
is a little more tricky, since this could be a property access expression,
however looking at the rules for ArrayBindingPattern it seems that this must
always either be empty, end with a comma, or end with a BindingRestElement? If
so, I don't think there is any pattern that will parse as both an
ArrayBindingPattern and an Expression.
(Am I reading ArrayBindingPattern correctly, and is this the intention? – the
rules for ArrayBindingPattern is a little confusing, since it allows:
[ BindingElementList `,` Elision BindingRestElement ]
which appears to be a slightly verbose way of saying:
[ BindingElementList Elision BindingRestElement ]
and there is also similar language in BindingElementList).
One issue with allowing let statements in classic code is that classic code
also allows with statements, both constructs make use of the LexicalEnviroment,
and as I read it the current runtime semantics could give rise to some, um,
interesting behaviour! - but I wouldn't see this as a major concern.
If all new syntax is backwards compatible and enabled in all code then it
raises the question, how exactly would the language change inside of a module?
1) Would we implicitly enable ES5-strict mode inside modules?
2) Do we change the behaviour of typeof inside modules?
3) Do we change static scoping / access to the global object inside modules?
(Does this cover everything?)
It seems likely that there will be users of the language who will take existing
ES5 code, wrap it in module syntax, and expect this to work. If users do so,
it seems to me that:
* It would seem most desirable for existing ES5 code were to just work.
* Next best would be if certain constructs were to generate an early error,
making it impossible for a user to miss the compatibility issue.
* Less desirable would be for code moved into module to run without generating
early errors, but to potentially be able to generate new runtime errors.
* Least desirable would be for code moved into a module to continue to function
without throwing, but with subtly different runtime semantics.
> # But then what about static scoping?
>
> Compile-time checking of variables is a really important goal, and we don't
> have to abandon it. We just do the checking only within module code, relative
> to the current contents of the global object. This means it's still
> technically possible for globals to disappear at runtime (and consequently
> throw errors).
If I'm interpreting your proposal correctly then this would only result in new
early errors, which I think makes this a very transparent and understandable
change for developers – this seems like pure win.
The large majority of changes introduced by strict mode are new syntax errors,
so implicitly enabling strict mode seems reasonable, but I have some concern
about this – there are new runtime errors (albeit some would probably be
covered by your stricter static scoping semantics), and there is the change in
runtime behaviour for the handling of the this value.
Brendan's objection withstanding, I'm inclined to agree with you that we should
not change the semantics of typeof.
So my answers to my three questions above would be a hesitant yes, no, and yes
(per your static scoping proposal).
cheers,
G.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Suggestion: Array.prototype.repeat
Another thing to think about is that .repeat (both on String and Array) will be used a lot in production. So it would make sense for each solution to be optimized for their specific case. It doesn't make sense to slow down something as trivial as .repeat() On Mon, Jan 2, 2012 at 16:51, Michael A. Smith wrote: > On Mon, Jan 2, 2012 at 3:56 PM, Mariusz Nowak > wrote: > >> I like it, it indeed looks very logical, however it's a bit controversial >> that we need to create temporary array object to get one that we want. >> Function (not method) that returns generated array may make more sense… > > Is the difference in overhead between instantiating a new array and > using Array.prototype.slice.call on arguments really worth sacrificing > consistency with the proposed string.prototype.repeat and the very > clean syntax of someArray.repeat(n)? > > Michael A. Smith > Web Developer > True Action Network (an eBay company) > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss -- Adam Shannon Web Developer University of Northern Iowa Sophomore -- Computer Science B.S. & Mathematics http://ashannon.us ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Suggestion: Array.prototype.repeat
On Mon, Jan 2, 2012 at 3:56 PM, Mariusz Nowak wrote: > I like it, it indeed looks very logical, however it's a bit controversial > that we need to create temporary array object to get one that we want. > Function (not method) that returns generated array may make more sense… Is the difference in overhead between instantiating a new array and using Array.prototype.slice.call on arguments really worth sacrificing consistency with the proposed string.prototype.repeat and the very clean syntax of someArray.repeat(n)? Michael A. Smith Web Developer True Action Network (an eBay company) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Suggestion: Array.prototype.repeat
I like it, it indeed looks very logical, however it's a bit controversial
that we need to create temporary array object to get one that we want.
Function (not method) that returns generated array may make more sense,
currently I'm using something like that:
var slice = Array.prototype.slice;
Array.generate = function (length, fill) {
var arr, l;
length = length >>> 0;
if (arguments.length < 2) {
throw new TypeError("Cannot generarte an array without provided
fill.");
}
arr = slice.call(arguments, 1, 1 + length);
while ((l = arr.length) < length) {
arr = arr.concat(arr.slice(0, length - l));
}
return arr;
};
( https://github.com/medikoo/es5-ext/blob/master/lib/Array/generate.js )
--
Mariusz Nowak
https://github.com/medikoo/
rauschma wrote:
>
> Array.prototype.repeat seems like a logical dual to
> String.prototype.repeat:
> http://wiki.ecmascript.org/doku.php?id=harmony:string.prototype.repeat
>
> Implementation:
>
> Array.prototype.repeat = function (times) {
> var result = [];
> var len = this.length;
> var resultLen = len * times;
> for(var i = 0; i < resultLen; i++) {
> result.push(this[i % len]);
> }
> return result;
> }
>
> In use:
>
> $ [1,2,3].repeat(3)
> [ 1, 2, 3, 1, 2, 3, 1, 2, 3 ]
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
>
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-
Mariusz Nowak
https://github.com/medikoo
--
View this message in context:
http://old.nabble.com/Suggestion%3A-Array.prototype.repeat-tp33067649p33068241.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Suggestion: Array.prototype.repeat
Array.prototype.repeat seems like a logical dual to String.prototype.repeat:
http://wiki.ecmascript.org/doku.php?id=harmony:string.prototype.repeat
Implementation:
Array.prototype.repeat = function (times) {
var result = [];
var len = this.length;
var resultLen = len * times;
for(var i = 0; i < resultLen; i++) {
result.push(this[i % len]);
}
return result;
}
In use:
$ [1,2,3].repeat(3)
[ 1, 2, 3, 1, 2, 3, 1, 2, 3 ]
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: String.prototype.until
> /^(.*?)needle.*$/.exec("foobar_needle")[1]
'foobar_'
On Jan 2, 2012, at 19:04 , Adam Shannon wrote:
> Alex, I'm confused as to what regular expressions would help with in
> this case. (Over .indexOf) The idea of .util() would be to return a
> new string which is just a substring, but provided as an "ease of use"
> to the developer.
>
> The case where I wrote .util() was in parsing out two comma separated
> values. I only needed the first, as could also be seen with trying to
> pull the first name (assuming just a first and last name), you could
> easily call name.until(' ') and get that back.
>
> On Mon, Jan 2, 2012 at 11:55, Axel Rauschmayer wrote:
>> Isn’t that usually better handled via a regular expression?
>>
>> One of the use cases for quasis [1][2] is to make it easy to insert literal
>> text into a regular expression. That seems pertinent here. Example:
>>
>>re`\d+(${localeSpecificDecimalPoint}\d+)?`
>>
>> The text in the variable localeSpecificDecimalPoint is matched literally by
>> the regular expression produced by re``.
>>
>> [1] http://wiki.ecmascript.org/doku.php?id=harmony:quasis
>> [2] http://www.2ality.com/2011/09/quasi-literals.html
>>
>>
>> On Jan 2, 2012, at 18:03 , Adam Shannon wrote:
>>
>>> Hello all,
>>>
>>> I recently ran into a situation where I would like to obtain a
>>> substring from the beginning until the first encounter with another
>>> substring. This promoted me to write a simple function, called until
>>> and I wondered if it would be something to add with the other string
>>> extras for ES.next.
>>>
>>> It could be defined as acting the same way as the following code:
>>>
>>> String.prototype.until = function (needle) {
>>> return this.substr(0, this.indexOf(needle));
>>> }
>>
>> --
>> Dr. Axel Rauschmayer
>> a...@rauschma.de
>>
>> home: rauschma.de
>> twitter: twitter.com/rauschma
>> blog: 2ality.com
>>
>>
>>
>
>
>
> --
> Adam Shannon
> Web Developer
> University of Northern Iowa
> Sophomore -- Computer Science B.S. & Mathematics
> http://ashannon.us
>
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: String.prototype.until
Alex, I'm confused as to what regular expressions would help with in
this case. (Over .indexOf) The idea of .util() would be to return a
new string which is just a substring, but provided as an "ease of use"
to the developer.
The case where I wrote .util() was in parsing out two comma separated
values. I only needed the first, as could also be seen with trying to
pull the first name (assuming just a first and last name), you could
easily call name.until(' ') and get that back.
On Mon, Jan 2, 2012 at 11:55, Axel Rauschmayer wrote:
> Isn’t that usually better handled via a regular expression?
>
> One of the use cases for quasis [1][2] is to make it easy to insert literal
> text into a regular expression. That seems pertinent here. Example:
>
> re`\d+(${localeSpecificDecimalPoint}\d+)?`
>
> The text in the variable localeSpecificDecimalPoint is matched literally by
> the regular expression produced by re``.
>
> [1] http://wiki.ecmascript.org/doku.php?id=harmony:quasis
> [2] http://www.2ality.com/2011/09/quasi-literals.html
>
>
> On Jan 2, 2012, at 18:03 , Adam Shannon wrote:
>
>> Hello all,
>>
>> I recently ran into a situation where I would like to obtain a
>> substring from the beginning until the first encounter with another
>> substring. This promoted me to write a simple function, called until
>> and I wondered if it would be something to add with the other string
>> extras for ES.next.
>>
>> It could be defined as acting the same way as the following code:
>>
>> String.prototype.until = function (needle) {
>> return this.substr(0, this.indexOf(needle));
>> }
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
>
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
>
>
>
--
Adam Shannon
Web Developer
University of Northern Iowa
Sophomore -- Computer Science B.S. & Mathematics
http://ashannon.us
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: String.prototype.until
Yes, I see the use for returning the entire string if the needle isn't
found. I was also thinking about a dynamic start position, which is
why I'd favor something like this.
String.prototype.until = function (needle, start) {
start ?? 0;
return this.substr(start, this.indexOf(needle)) || this
}
It seems weird to call something like str.until("bc", 2), but the
other option would be to check if arguments[0] is a number, and if so
to set start = arguments[0] and needle arguments[1].
On Mon, Jan 2, 2012 at 11:48, Michael A. Smith wrote:
> Semantically, calling it "until" makes me think that if the "needle"
> isn't found, it should return the entire haystack. Your example
> implementation would return an empty string in that case. Also, to
> keep consistency with other string methods like substr, shouldn't we
> allow the developer to decide the starting index?
>
> String.prototype.until = function (start, needle) {
> return "" + (this.substr(start, this.indexOf(needle)) || this);
> }
>
> (The ["" +] part is probably not necessary, but it makes it easier to
> see the implementation work in the console.)
>
> Michael A. Smith
> Web Developer
> True Action Network (an eBay Company)
>
> On Mon, Jan 2, 2012 at 12:03 PM, Adam Shannon wrote:
>> Hello all,
>>
>> I recently ran into a situation where I would like to obtain a
>> substring from the beginning until the first encounter with another
>> substring. This promoted me to write a simple function, called until
>> and I wondered if it would be something to add with the other string
>> extras for ES.next.
>>
>> It could be defined as acting the same way as the following code:
>>
>> String.prototype.until = function (needle) {
>> return this.substr(0, this.indexOf(needle));
>> }
>>
>> --
>> Adam Shannon
>> Web Developer
>> University of Northern Iowa
>> Sophomore -- Computer Science B.S. & Mathematics
>> http://ashannon.us
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
--
Adam Shannon
Web Developer
University of Northern Iowa
Sophomore -- Computer Science B.S. & Mathematics
http://ashannon.us
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: String.prototype.until
Isn’t that usually better handled via a regular expression?
One of the use cases for quasis [1][2] is to make it easy to insert literal
text into a regular expression. That seems pertinent here. Example:
re`\d+(${localeSpecificDecimalPoint}\d+)?`
The text in the variable localeSpecificDecimalPoint is matched literally by the
regular expression produced by re``.
[1] http://wiki.ecmascript.org/doku.php?id=harmony:quasis
[2] http://www.2ality.com/2011/09/quasi-literals.html
On Jan 2, 2012, at 18:03 , Adam Shannon wrote:
> Hello all,
>
> I recently ran into a situation where I would like to obtain a
> substring from the beginning until the first encounter with another
> substring. This promoted me to write a simple function, called until
> and I wondered if it would be something to add with the other string
> extras for ES.next.
>
> It could be defined as acting the same way as the following code:
>
> String.prototype.until = function (needle) {
> return this.substr(0, this.indexOf(needle));
> }
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: String.prototype.until
Semantically, calling it "until" makes me think that if the "needle"
isn't found, it should return the entire haystack. Your example
implementation would return an empty string in that case. Also, to
keep consistency with other string methods like substr, shouldn't we
allow the developer to decide the starting index?
String.prototype.until = function (start, needle) {
return "" + (this.substr(start, this.indexOf(needle)) || this);
}
(The ["" +] part is probably not necessary, but it makes it easier to
see the implementation work in the console.)
Michael A. Smith
Web Developer
True Action Network (an eBay Company)
On Mon, Jan 2, 2012 at 12:03 PM, Adam Shannon wrote:
> Hello all,
>
> I recently ran into a situation where I would like to obtain a
> substring from the beginning until the first encounter with another
> substring. This promoted me to write a simple function, called until
> and I wondered if it would be something to add with the other string
> extras for ES.next.
>
> It could be defined as acting the same way as the following code:
>
> String.prototype.until = function (needle) {
> return this.substr(0, this.indexOf(needle));
> }
>
> --
> Adam Shannon
> Web Developer
> University of Northern Iowa
> Sophomore -- Computer Science B.S. & Mathematics
> http://ashannon.us
> ___
> 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: Object Model Reformation – elementIn?
>> Currently, there one can override the built-in operators via elementGet
>> (getting via []), elementSet (setting via []) and elementDelete (`delete`
>> operator). Wouldn’t it make sense to also provide elementIn (`in` operator)?
>
> Probably. It may depend upon how strongly you feel about obsoleting for-in
> in favor of for-of.
That would be some kind of iteration protocol(?) I’d be perfectly happy with
not supporting for-in at all.
I was thinking about the relational operator `in`:
if (key in myMap) {
...
}
if (element in mySet) {
...
}
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object Model Reformation – elementIn?
On Jan 1, 2012, at 5:54 AM, Axel Rauschmayer wrote: > http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation > > Currently, there one can override the built-in operators via elementGet > (getting via []), elementSet (setting via []) and elementDelete (`delete` > operator). Wouldn’t it make sense to also provide elementIn (`in` operator)? Probably. It may depend upon how strongly you feel about obsoleting for-in in favor of for-of. Allen > > -- > Dr. Axel Rauschmayer > a...@rauschma.de > > home: rauschma.de > twitter: twitter.com/rauschma > blog: 2ality.com > > > > ___ > 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
String.prototype.until
Hello all,
I recently ran into a situation where I would like to obtain a
substring from the beginning until the first encounter with another
substring. This promoted me to write a simple function, called until
and I wondered if it would be something to add with the other string
extras for ES.next.
It could be defined as acting the same way as the following code:
String.prototype.until = function (needle) {
return this.substr(0, this.indexOf(needle));
}
--
Adam Shannon
Web Developer
University of Northern Iowa
Sophomore -- Computer Science B.S. & Mathematics
http://ashannon.us
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 doesn't need opt-in
It sure would be nice to put away with additional language modes. However: Pragmatically, I don't see how wrapping your program into a module is more convenient then putting a `use' directive on top. And your additional proposal for "use module" is kind of admitting that it's actually worse, isn't it? If I ever want to use `let' or `const' in my main program (which I expect to be the common case for most users), then I'm back to square one. And technically, there is no actual difference between a scoped "mode" and a dependence on syntactic context. The former is just a specific way to provide the latter. Neither is simpler. (In fact, one could argue that piggy-backing modules as a syntactic context for allowing ES6-specific features is both limiting and conflating features.) And of course, giving up on the top-level and proper static scoping is a big price IMHO. Should we really do that so soon? In other words, I think the main points of your proposal can essentially be rephrased to: 1) Rename "use version 6" to "use module". 2) Allow module declarations in classic mode. 3) Make every module body start with an implicit "use module". 4) Keep the semantics of the top-level scope unaltered, even in presence of a top-level "use module". I'm fine with (1) to (3), but (4) seems to be a separate design choice. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why we need to clean up __proto__
On 30 December 2011 00:00, Mark S. Miller wrote:
> {__proto__:...} having a magic meaning is per code, and so can and should be
> conditioned on mode. I think it should only be allowed to be magic in
> non-strict mode.
What about {["__proto__"]: ...} then?
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Simple maps/sets: parameterize the comparator?
On 29 December 2011 18:48, Allen Wirfs-Brock wrote: > The existence of WeakMap/Map implies the > existence of an internal object identify hash value. Why? AFAICT, there is nothing currently requiring these collections to be implemented as hash tables in particular. And there may perhaps be reasons for an implementation not to (hash tables tend to be vastly overused anyway). I would prefer not to hard-code that as a requirement. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maps and WeakMaps interoperability
On 27 December 2011 16:15, David Bruant wrote:
> -
> var m = new Map();
> var key = {};
> m.set(key, 37);
>
> WeakMap.prototype.get.call(m, key); // ?
> -
>
> Currently Chrome canary says "illegal access".
That is a bug. It should throw TypeError.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ECMAScript.next features in Firefox?
On 25 December 2011 13:26, Axel Rauschmayer wrote: > Paul Irish did a code search for that: > > http://www.google.com/codesearch#W9JxUuHYyMg/trunk/src/flag-definitions.h&q=harmony%20package:http://v8\.googlecode\.com&l=109 To elaborate, the --harmony flag currently activates the following experimental features for V8: - block scoping, let, const, block functions (http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings, etc) - proxies, though not direct proxies yet (i.e., http://wiki.ecmascript.org/doku.php?id=harmony:proxies) - maps and sets (http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets) - weak maps (http://wiki.ecmascript.org/doku.php?id=harmony:weak_maps) - typeof null reform (http://wiki.ecmascript.org/doku.php?id=harmony:typeof_null) On the browser side, that should become functional in Chrome 17 (some of it is in 16 already, but incomplete/buggy) by setting --js-flags="--harmony". If you are on the Chrome dev channel, you should also see it show up on chrome://flags soon. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
