Re: Proposal: Forced Chaining Operator "!."

[Thomas Shinnick]

You are describing Perl's autovivification feature. Also possible (in that
syntax) for arrays and mixed object/array chains. I liked it, but many saw
it as a footgun. There was even a compile time module to turn off the
feature, if the coder wanted more caution. Having mentioned Perl I will
assume this is DOA?

On Fri, Apr 24, 2020, 14:36 Tobias Buschor  wrote:

> Since we now have the "Optional Chaninig Operator" , perhaps a "Forced
> Chaining Operator" would also be worth considering.
> I, personally, could use it:
>
> let table;
> table!.user!.id!.type = 'int'
>
> will evaluate to:
>
> let table;
> if ( ! ( table instanceOf Object) ) table = {};
> if ( ! ( table.user instanceOf Object) ) table.user = {};
> if ( ! ( table.user.id instanceOf Object) ) table.user.id = {};
> table.user.id.type = 'int';
>
> Also to be noted:
> Sometimes a fallback to `Object.create(null)` or something other might be
> desirable.
> But since `{}` is syntactical sugar for `Object.create(Object.prototype)`,
> this would be consistent.
>
> ___
> 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: Re: Add "???" Unimplemented

[Thomas Grainger]

const ɁɁɁ = () => { throw new Error('Method not defined'); };

Thomas Grainger

On 26 March 2018 at 06:26, Isiah Meadows <isiahmead...@gmail.com> wrote:

> Even in TypeScript, `never` (the type of functions that never return -
> throwing ≠ returning) is the subtype of *all* types, even primitives.
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> On Sun, Mar 25, 2018 at 7:45 PM, dante federici
> <c.dante.feder...@gmail.com> wrote:
> > Not a bad idea -- I agree that it really belongs here, but its value is
> much
> > higher in something like TypeScript, where you can keep the typing
> signature
> > but have a missing implementation.
> >
> >
> > On Sat, Mar 24, 2018 at 3:32 AM Isiah Meadows <isiahmead...@gmail.com>
> > wrote:
> >>
> >> I would suggest, if you have support in your editor, just making a
> >> `???` snippet expand to `throw new Error("unimplemented")`. I've been
> >> doing similar (mod the snippet) for a while, and it's worked pretty
> >> well.
> >> -
> >>
> >> Isiah Meadows
> >> m...@isiahmeadows.com
> >>
> >> Looking for web consulting? Or a new website?
> >> Send me an email and we can get started.
> >> www.isiahmeadows.com
> >>
> >>
> >> On Fri, Mar 23, 2018 at 11:16 AM, dante federici
> >> <c.dante.feder...@gmail.com> wrote:
> >> > Simple example (ts):
> >> > ```typescript
> >> > interface SearchFunc {
> >> > (source: string, subString: string): boolean;
> >> > }
> >> >
> >> > // Later
> >> > let mySearch: SearchFunc;
> >> > mySearch = function(source: string, subString: string) {  ??? }
> >> > ```
> >> >
> >> > Simple example (js):
> >> > ```js
> >> > class MyClass = {
> >> >   foo() { return "foo"; }
> >> >   bar() { return "bar"; }
> >> > }
> >> > class ExtendClass extends MyClass {
> >> > foo(){ ??? }
> >> > bar(){ return `extended bar`; }
> >> > }
> >> >
> >> > // Elsewhere
> >> > myRunner = (classInstance) => `${classInstance.foo()} ::
> >> > ${classInstance.bar()}`;
> >> >
> >> > myRunner(myClassInstance);
> >> > myRunner(extendedClassInstance);
> >> > ```
> >> >
> >> > Decorations would be good for classes, but don't work for regular
> >> > methods.
> >> >
> >> > I'm not sold we need new syntax for this -- I just find myself
> reaching
> >> > for
> >> > the `???` symbol. Especially in a typed language or in any instance
> that
> >> > we
> >> > have a class and extended paradigm, or when you have a prescribed
> >> > "object"
> >> > shape.
> >> >
> >> > ___
> >> > 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
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Improved syntax for observable mapping and subscribing

[Thomas Grainger]

You can convert an observable into an async iterator. You have to choose
between discarding or buffering uniterated items

On 23 Mar 2018 14:39, "Bob Myers"  wrote:

> Could someone jog my memory about proposals for better syntax for
> observable mapping and subscribing, if any?
>
> I'm getting really tired of writing
>
> ```
> foo$.pipe(map(bar => mapper(bar)))
> ```
>
> I would much prefer to write something along the lines of
>
> ```
> stream function fooMapper(foo$) {
>   while async (const bar = foo$()) {
> emit mapper(bar);
>   }
> }
> ```
>
> Yes, I'm aware of all the potential issues here and this is just an
> example, not an actual syntax proposal. I'm just wondering about any prior
> art.
>
> Bob
>
>
> ___
> 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: Proposal: if variable initialization

[Thomas Grainger]

Is this sarcastic?

On 21 Mar 2018 12:58, "kai zhu"  wrote:

> this is why let and const should *never* have been introduced.  if we had
> stuck with just var, none of these petty-arguments and bickering among
> team-members/shops on scoping-styles that ultimately have *zero*
> productivity or benefit to web-projects would be possible.
>
> and there's nothing wrong with pre-declaring all variables at the
> top-level of a function (which is an es5 best-practice that’s still valid
> today), regardless whether some are only used in conditional-blocks or not,
> like this real-world example [1]:
>
> ```
> local.validateBySwaggerSchema = function (options) {
> /*
>  * this function will validate data against schema
>  * http://json-schema.org/draft-04/json-schema-validation.
> html#rfc.section.5
>  */
> var $ref,
> circularList,
> data,
> dataReadonlyRemove2,
> ii,
> oneOf,
> schema,
> test,
> tmp;
> ...
> // dereference schema.$ref
> $ref = schema && schema.$ref;
> if (!$ref) {
> break;
> }
> ...
> tmp = typeof data;
> if (tmp === 'object' && Array.isArray(data)) {
> tmp = 'array';
> }
> ...
> if (schema === local.swaggerSchemaJson.definitions.jsonReference) {
> ...
> }
> ...
> };
> ```
>
> [1] https://github.com/kaizhu256/node-swgg/blob/2018.2.1/lib.swgg.js#L4076
>
> -kai
>
> On Mar 21, 2018, at 7:15 PM, Jordan Harband  wrote:
>
> ```
> if (someComplicatedCondition()) {
>   doSomeLogic();
>   doSomeOtherLogic(if.value, true);
> }
> ```
>
> On Wed, Mar 21, 2018 at 2:52 AM, Rodrigo  wrote:
>
>> Here are my gripes with `let` and `const` returning values:
>>
>> 1) declaration lists are hard to read:
>>
>> if ((let x = 10, y = 20) > 15) {
>> // true, but what's being compared here? 10 or 20? (answer: 20)
>> }
>>
>> Although right now this is allowed and the last element is compared:
>>
>> if ((x = 10, y = 20) > 15) {
>> // result is true, 20 > 15
>> }
>>
>> 2) Destructuring assignments are also confusing, what's being compared
>> here?
>>
>> if(let [x,y] = [1,2]) {
>> }
>>
>> Again, this is allowed as of today:
>>
>> if([x,y] = [1,2]) {
>> // true, as it returns [1,2]
>> }
>>
>> 3) Nesting `let/const` would be either expected everywhere (not only
>> in the `if`) or a possible side effect from the implementation.
>> Similar to languages such as Perl.
>>
>> let x = foo(let y = 100, z = 200);  // what's the scope of x and z?
>>
>> This leads to hard to read and very confusing code golf.
>>
>> That's why Golang went with something simple,
>> `if([declaration];[conditional])`, and avoided confusion over `:=`
>> assignments returning values anywhere in the code. `x:=( y:= 20 )` is
>> not allowed in Go.
>>
>> It expands on the 45-year tried-and-true structure of `for(;;)` to
>> create `if(;)` and keep the ES language simple and clear expanding on
>> its own concept of `for(;;)`.
>>
>> On Wed, Mar 21, 2018 at 7:57 AM, Naveen Chawla 
>> wrote:
>> > OK I neglected to read the original post fully. My last post example
>> would
>> > be based on allowing `const` and `let` declarations to expressions in of
>> > themselves (in the case of multi variables, returning the last one). So
>> let
>> > me ask, what exactly would be the problem with this?
>> >
>> > On Wed, 21 Mar 2018 at 12:20 Naveen Chawla 
>> wrote:
>> >>
>> >> What would `if.value` look like in an example?
>> >>
>> >> Wouldn't it be possible to have something like `if(const x = getX() &&
>> >> const y = getY())` to capture more than just the conditional if
>> required?
>> >> I'm guessing that would probably break something somewhere, but I'm
>> not sure
>> >> what.
>> >>
>> >> On Wed, 21 Mar 2018 at 04:35 Jordan Harband  wrote:
>> >>>
>> >>> Is the use case only ever to capture the thing that serves as the
>> >>> conditional?
>> >>>
>> >>> If so, would perhaps something like `if.value` work better? Since
>> it's a
>> >>> keyword, it could be made to only work in the `if` block, and you
>> wouldn't
>> >>> need any of that odd multi-statement stuff in the conditional parens.
>> >>>
>> >>> On Tue, Mar 20, 2018 at 12:57 PM, Rodrigo 
>> wrote:
>> 
>>  Proposal: inline let/const statements to declare and initialize
>>  variables within if statements, so that temporary variables exist
>> only
>>  within the if/else block scope.
>> 
>>  Reason: limits variable scope to the block where really needed, in
>>  similar fashion to variables defined in for(;;) statements. This
>>  improves readability while reducing unnecessary variables roaming
>>  outside their needed block.
>> 
>>  The syntax would be very similar to the for(;;) assignment/test pair:
>> 
>>  if (let x = 100; x > 50) 

Re: add reverse() method to strings

[Thomas Grainger]

String.prototype.reverse() might break web compatibility, how about
String.prototype.turnyRoundy()?

On 17 Mar 2018 18:47, "Claude Pache"  wrote:

>
>
> Le 17 mars 2018 à 19:29, Oriol _  a écrit :
>
> Be aware your code breaks pair surrogates, which might be undesirable:
>
> ```js
> var str = "a_\uD83D\uDE80_b";
> str.split("").reverse().join(""); // "b_\uDE80\uD83D_a" :(
> [...str].reverse().join("");  // "b_\uD83D\uDE80_a" :)
> ```
>
> —Oriol
>
>
> Well, but be aware that the corrected implementation still breaks
> graphemes composed by a sequence of code points, such as: n̈ ( LATIN SMALL
> LETTER N + COMBINING DIEARESIS), which might be undesirable...
>
> Anyway, what are the use cases?
>
> —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

Re: Feature Proposal - async variables (like thread local storage from C)

[Thomas Grainger]

I'm pretty sure this is Zones

On 11 Mar 2018 15:35, "Guy Margalit"  wrote:

> Hey
>
> It's my first attempt to contribute to ECMAScript so would love your
> feedback if I better off change how I go about it.
>
> The problem I want to highlight is that besides argument passing it is
> impossible to have any information associated with a flow of async code as
> any async code will create its own context and will only get the arguments
> passed to it from its caller.
>
> A simple use case for information that is not easy to pass as arguments is
> "transaction ID" where unique IDs are generated at the beginning of a
> transaction, and propagate that ID to any function that is being called as
> part of that transaction.
>
> However as a javascript codebase grows, it becomes hard to introduce new
> project-wide information such as transaction ID when the only mechanism to
> pass such information is function argument passing, and this becomes
> impossible as many times you are using other libraries of code inside the
> code stack, and one cannot change all the code just to add arguments.
>
> Few examples:
>
>- Identify HTTP requests and print that a request ID in every log
>print that was fan-out from that request.
>- Find how many database calls one async flow created.
>- Keep pools of resources (buffers / connections / tokens) per request.
>
> In C/C++ one can use thread local storage (https://en.wikipedia.org/wiki
> /Thread-local_storage) to keep information that automatically switches
> with the threads context switch.
>
> I imagine a similar mechanism, in the spirit of javascript - define a
> variable as `async`:
>
> ```
> async var name = ;
> ```
>
> Async variables will be saved and restored automatically when the context
> is resumed. It should probably have a more precise definition in ECMAScript
> terms.
>
> ```
> async var reqid = '';
>
> http_server.on('request', handler);
>
> async function handler(req, res) => {
>
>   // setting async variable concurrently be different requests
>   // will retain the generated value for the other calls made by this
> context (sync or async).
>   reqid = `REQ-${uuid()}`;
>
>   await load_data_from_db(req);
>   await send_analytics_info(req);
>   send_reply(res);
> });
>
> async function load_data_from_db(req) {
>   console.log(`${reqid} load_data_from_db`);
>   try {
>  ...
>   } catch (err) {
> ...
> if (err.code === 'ACCESS_DENIED') {
>   console.log(`${reqid} ACCESS_DENIED. this incident will be reported.
> `);
> }
>   }
> }
>
> async function send_analytics_info(req) {
>   console.log(`${reqid} send_analytics_info`);
>   ...
>   analytics.send(reqid, ...);
>   ...
> }
>
> function send_reply(res) {
>   console.log(`${reqid} send_analytics_info`);
>   ...
>   res.setHeader('reqid', reqid); // for supportability
>   res.send(...);
>   ...
> }
> ```
>
> Technically speaking, async variables should be replaced whenever there is
> a context switch - either when a sync stack returns to the top stack
> level, or when an async function returns from await.
>
> However, this means that every registration of a function for later, such
> as setTimeout(func), should also keep the async variables which sounds
> difficult.
>
> Would be great to hear if you think this is valuable and feasible, or
> maybe there's a way to design this with less overhead.
>
> Thanks,
> Guy Margalit
>
>
> ___
> 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: Cloning WeakSet/WeakMap

[Thomas Grainger]

I think this is referring to cloning a WeakSet into another WeakSet

Thomas Grainger

On 9 February 2018 at 15:01, David Bruant <bruan...@gmail.com> wrote:

> Hi,
>
> My understanding is that cloning a WeakSet into a Set would remove all its
> properties related to security and garbage collection.
>
> The properties related to security and garbage collection of WeakSet are
> based on the fact that its elements are not enumerable by someone who would
> only be holding a reference to the WeakSet. If you want to "clone" a
> WeakSet into a Set it means you have an expectation that the set of
> elements are deterministically enumerable.
>
> WeakSets and Sets, despite there close name and API, are used in different
> circumstances.
>
> David
>
>
> 2018-02-09 9:53 GMT-05:00 Michał Wadas <michalwa...@gmail.com>:
>
>> Hi.
>>
>> I was asked to include a way to clone WeakSet in Set builtins proposal.
>> Is there any consensus on security of such operation?
>>
>> Michał Wadas
>>
>> ___
>> 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

Suggestion: Infix operators/functions

[Thomas Grainger]

I'm porting this from the TypeScript issue tracker, original from:
https://github.com/Microsoft/TypeScript/issues/2319#issue-60851953

Since it's very unlikely that the extension methods will ever be
implemented [in a call-site-rewrite
manner](https://github.com/Microsoft/TypeScript/issues/9#
issuecomment-74302592),
please consider adding infix operators to enable writing in functional
style similarly to what can be done in Haskell:

Monoids

```js

function '+' (left, right) {
   return left.concat(right);
}

[1, 2, 3] '+' [4, 5]; // [1, 2, 3, 4, 5]

```

Monads

```js
function '>>=' (promise, bind) {
   return promise.then(bind);
}
$.get('/get') '>>=' x => $.post('/save', x + 1)
```

Functors

```js
function '.' (inner, outer) {
   return function(value: a) : c {
  return outer(inner(value))
   }
}

function f(x) { }
function g(y) { }
(f '.' g)(x); // z
```



Thomas Grainger
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: es7 proposal/polyfill?: base Map/WeakMap off Proxy + Weak References

[Thomas]

> Map's API could just go away and follow traditional Object assignment
> and existence checks:
> 
> map[key] = value;
> 
> // wish JS had a null-coalescing `?` operator like Coffeescript..
> if (map[key] !== undefined || map[key] !== null) { ... }
> 
> It's totally legal in non-Node JS to have Objects as keys in other
> Objects, right? (I forget)

Not sure where you got that idea, but aren't the objects just being converted 
to string property names?

> So that's my idea.  Toodles ~
> 
> PS: And build Set off of a Proxy + Array.  Just stop being weird. :P
> ___
> 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: JavaScript Language feature Idea

[Thomas]

Is this what you're thinking?

Array.prototype.nth = function (n){
  if(n < 0){
return this[this.length -n];
  } else {
return this[n];
  }
}

Thomas Foster

@thomasfoster96
Ph: +61477808008
http://thomasfoster.co/

> On 23 Jan 2016, at 4:40 PM, kdex <k...@kdex.de> wrote:
> 
> While John's solution doesn't run into conflicts with downward compatibility, 
> it still wouldn't solve the problem of getting the n-th last element of an 
> array. To solve this, it'd probably be a good idea to extend the prototype 
> and 
> specify a parameter, defaulting to 1.
> 
> `Array.prototype.last` doesn't show up a terrible lot on search engines, 
> either, so we might actually be lucky here. Other than that, I also found two 
> more threads[1][2] on the EcmaScript discussion archives that propose it.
> 
> They might be worth a read.
> 
> [1] https://esdiscuss.org/topic/array-prototype-last
> [2] https://esdiscuss.org/topic/proposal-array-prototype-last
> 
>> On Samstag, 23. Januar 2016 15:44:19 CET John Gardner wrote:
>> Using a well-known symbol to access an array's last element is probably
>> wiser than a typical method or property:
>> 
>> let a = [0, 1, 2, 3];
>> console.log(
>> a[Symbol.last] === 3
>> /* true */
>> );
>> 
>> There're obviously instances where authors have extended Array prototypes
>> with "last" methods or properties, but we can't guarantee they'd all work
>> the same. For instance, assume there are some implementations that skip
>> undefined values:
>> 
>> var a = [0, 1, 2, undefined, undefined];
>> Array.prototype.last = function(){
>> return this[this.length - 1];
>> };
>> /** One that skips undefined values */
>> Array.prototype.last = function(){
>> var offset = 1;
>> while(offset < this.length && undefined === this[this.length - offset])
>> ++offset;
>> return this[this.length - offset];
>> }
>> 
>> These discrepancies are subtle, but have the potential to break backwards
>> compatibility.
>> 
>> Using a well-known symbol eliminates the potential for conflict.
>> Furthermore, it also offers an opportunity to complement any iterable
>> object's ability to synthesise array-like behaviour. For instance, it
>> enables iterables to also return the last object in their list of values:
>> 
>> let pruebas = {
>> data: ["Probando", "la", "mierda", "esta", undefined],
>> 
>> [Symbol.iterator](){
>> /* Stuff with .data */
>> },
>> [Symbol.last](){
>> /** Stuff to skip undefined values or whatever */
>> let offset = 1;
>> let data   = this.data;
>> while(
>> offset < data.length &&
>> undefined === data[data.length - offset]
>> )
>> ++offset;
>> return data[data.length - offset];
>> }
>> }
>> 
>> O
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Syntax Sugar for protected state

[Thomas]

Could this be achieved with decorators? 

> On 19 Jan 2016, at 8:31 PM, 森建  wrote:
> 
> Dear ES discuss subscribers,
> 
> I'm Kenta Moriuchi,
> Department of Art and Information Design
> Kyushu University in Japan
> 
> I propose `Protected State`.
> 
> In ES2015:
> 
> ```js
> // utility
> function createProtectedStorage() {
>const wm = new WeakMap();
> 
>return (self, protectedClass) => {
>const map = wm.get(self);
> 
>if(protectedClass == null) {
>return map || wm.set(self, Object.create(null)).get(self);
>}
> 
>const p = new protectedClass(self);
>if(map) {
>Object.assign(p, map);
>}
>return wm.set(self, p).get(self);
>}
> }
> 
> const _ = createProtectedStorage();
> 
> 
> class Protected_A {
> 
>constructor(publicThis) {
>this.publicThis = publicThis;
>}
> 
>getName() {
>return `${this.publicThis.name} ${this.lastName}`;
>}
> }
> 
> class A {
> 
>constructor(name, lastName) {
>// protected this
>if(new.target === A)_(this, Protected_A);
> 
>// public property
>this.name = name;
> 
>// protected property
>_(this).lastName = lastName;
>}
> 
>callGetName() {
>// call protected method
>return _(this).getName();
>}
> }
> 
> // test
> const a = new A("foo", "bar");
> 
> // "foo bar"
> console.log(a.callGetName());
> 
> // "foo"
> console.log(a.name);
> 
> // undefined
> console.log(a.lastName);
> 
> 
> // extends
> class Protected_B extends Protected_A {
> 
>constructor(publicThis) {
>super(publicThis);
>}
> 
>getAge() {
>return this.age;
>}
> 
> }
> 
> class B extends A {
> 
>constructor(name, lastName, age) {
>super(name, lastName);
> 
>// protected this
>if(new.target === B)_(this, Protected_B);
> 
>// protected property
>_(this).age = age;
>}
> 
>callGetAge() {
>return _(this).getAge();
>}
> 
> }
> 
> // test
> const b = new B("foo", "bar", 18);
> 
> // "foo bar"
> console.log(b.callGetName());
> 
> // 18
> console.log(b.callGetAge());
> ```
> 
> As Syntax Suger (ES Next):
> 
> ```js
> class A {
> 
>protected lastName;
> 
>constructor(name, lastName) {
>// public property
>this.name = name;
> 
>// protected property
>protected.lastName = lastName;
>}
> 
>protected getName() {
>return `${this.name} ${protected.lastName}`;
>}
> 
>callGetName() {
>return protected.getName();
>}
> 
> }
> 
> class B extends A {
> 
>protected age;
> 
>constructor(name, lastName, age) {
>super(name, lastName);
>protected.age = age;
>}
> 
>protected getAge() {
>return protected.age;
>}
> 
>callGetAge() {
>return protected.getAge();
>}
> 
> }
> ```
> 
> Please discuss this proposal, thank you.
> ___
> 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: Propose simpler string constant

[Thomas]

IMHO it'd be a huge mistake to not use symbols for enums. 

In my head this:

const colours = enum {
  Red,
  Yellow,
  Green,
  Blue
}

should 'desugar' to something like this in ES6:

const colours = {
  Red: Symbol('Red'),
  Yellow: Symbol('Yellow'),
  Green: Symbol('Green'),
  Blue: Symbol('Blue')
}

Thomas 

> On 16 Dec 2015, at 10:02 PM, Andrea Giammarchi <andrea.giammar...@gmail.com> 
> wrote:
> 
> FWIW I think If an enum should hold a unique value either "symbol" or a new 
> "enum" type, otherwise I think "number" would be easier way to go.
> 
> Regards
> 
>> On Wed, Dec 16, 2015 at 12:20 AM, kdex <k...@kdex.de> wrote:
>> Honestly,
>> 
>> ```js
>> const ADD_ALL_THE_STUFF = "ADD_ALL_THE_STUFF";
>> ```
>> 
>> doesn't seem like a intended approach anyway, even if there was a shorter 
>> syntax. `Symbol()` seems to be the better choice if the objective is to 
>> manage references whose values indicates special semantics; I have yet to 
>> see a use case where a string turns out to be beneficial. Semantically, what 
>> should
>> 
>> ```js
>> typeof (enum {
>> APPLE,
>> ORANGE,
>> GRAPE
>> }).APPLE;
>> ```
>> 
>> evaluate to? A `"symbol"` called with its identifier, an identifier-valued 
>> `"string"`, an integer-valued `"number"`?
>> 
>> 
>>> On 16.12.2015 00:00, Jordan Harband wrote:
>>> Correct, when `const foo;` throws, my concern doesn't exist. The concern I 
>>> was talking about is if this initial suggestion went through, and `const 
>>> foo;` would become `const foo = 'foo';`, that a new refactoring hazard 
>>> would be created - which is the entire reason `const foo;` throws as-is.
>>> 
>>> Agreed that an `enum` construct would be very useful.
>>> 
>>> On Tue, Dec 15, 2015 at 11:56 AM, Andrea Giammarchi 
>>> <andrea.giammar...@gmail.com> wrote:
>>>> Jordan AFAIK you can't have undefined const declaration so your concern is 
>>>> unfounded.
>>>> 
>>>> However, I'm pretty sure what Brendan says **is** indeed what developers 
>>>> want so I'd +1 that without problems.
>>>> 
>>>> Regards
>>>> 
>>>>> On Tue, Dec 15, 2015 at 4:44 PM, Jordan Harband <ljh...@gmail.com> wrote:
>>>>> That seems hazardous - if someone is converting a "var" codebase to 
>>>>> "const" and "let", and they convert `var foo;` to `const foo;` expecting 
>>>>> it to be undefined, the current TDZ error will be much more helpful to 
>>>>> them than a silent change of meaning in their code to `const foo = 
>>>>> 'foo';`.
>>>>> 
>>>>> On Tue, Dec 15, 2015 at 8:35 AM, Kip Obenauf <mozi...@turtlebyte.com> 
>>>>> wrote:
>>>>>> A common pattern I see is this:
>>>>>> const ADD_ALL_THE_STUFF = 'ADD_ALL_THE_STUFF'
>>>>>> 
>>>>>> Would it be helpful to allow a shorter version of this to be:
>>>>>> const ADD_ALL_THE_STUFF
>>>>>> 
>>>>>> Rather than have that just be forever undefined, it could automatically 
>>>>>> refer to a string of the same name, i.e. 'ADD_ALL_THE_STUFF'.
>>>>>> 
>>>>>> ___
>>>>>> 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
> 
> ___
> 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: Propose simpler string constant

[Thomas]

Out of curiosity, is anyone working on a proposal for enum? Given the keyword 
has been reserved for so long, it seems a little strange for a proposal not to 
be floating around - unless I've missed something.

> On 16 Dec 2015, at 10:31 PM, Coroutines <corouti...@gmail.com> wrote:
> 
>> On Wed, Dec 16, 2015 at 3:20 AM, Thomas <thomasjamesfos...@bigpond.com> 
>> wrote:
>> IMHO it'd be a huge mistake to not use symbols for enums.
>> 
>> In my head this:
>> 
>> const colours = enum {
>>  Red,
>>  Yellow,
>>  Green,
>>  Blue
>> }
>> 
>> should 'desugar' to something like this in ES6:
>> 
>> const colours = {
>>  Red: Symbol('Red'),
>>  Yellow: Symbol('Yellow'),
>>  Green: Symbol('Green'),
>>  Blue: Symbol('Blue')
>> }
>> 
>> Thomas
> 
> This person gets it. +1  :-)
> ___
> 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

Calling toString on function proxy throws TypeError exception

[Thomas Greiner]

According to
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/toString
`Function.prototype.toString` is supposed to throw a `TypeError` exception
when used on a function proxy. That's also consistent with how it's defined
at
http://www.ecma-international.org/ecma-262/6.0/#sec-function.prototype.tostring
but presumably only because the Proxy scenario is not explicitly mentioned.

The problem I see with that is that it makes proxies distinguishable from
their targets even if they don't specify any traps. At least in cases where
the mere existence of a proxy needs to be kept secret, this introduces a
severe limitation.

That behavior also goes against the "transparent virtualization" principle
as outlined by Axel Rauschmayer (see
http://www.2ality.com/2014/12/es6-proxies.html#transparent_virtualization_and_handler_encapsulation
):

> Proxies are shielded in two ways:
>
> - It is impossible to determine whether an object is a proxy or not
(transparent virtualization).
> - You can’t access a handler via its proxy (handler encapsulation).

Thomas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Swift style syntax

[Thomas]

> Is it possible to extend JavaScript syntax to support Swift style block 
> syntax[1]?
> 
> In Swift it's possible to omit return keyword 
> ```
> reversed = names.sort( { s1, s2 in s1 > s2 } )
> ```

As you note below this is already possible in es6, and might I add, has much 
more intuitive syntax in Es6. The swift syntax looks like a list comprehension 
gone wrong.

> or omit argument declaration like this:
> 
> ```
> reversed = names.sort( { $0 > $1 } )
> ```

I for one think this is a bad idea - use rest arguments instead. It's pretty 
terrible as far as readability goes, although I'd like to see more examples of 
it being used in Swift code.

> or apply an operator to arguments of a function 
> 
> ```
> reversed = names.sort(>)
> ```

This might actually be possible - I can't think of any ambiguous situations for 
passing operators as if they were first class functions. If it is possible, I'd 
like to see this done.

> We have the first feature in ES2015 already:
> 
> ```
> let sorted = names.sort((a, b)=> a > b);
> ```
> 
> But for omitting argument declaration we need to find an alternative to $0, 
> $1... since those are valid variable names in JS. Maybe we can use #0, #1... 
> instead.
> 
> This is very useful for functional programming aspect of JS. For example in a 
> filter function:
> 
> ```
> let passed = objs.filter(#0.passed)
> ```
> 
> [1][https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Closures.html]
> ___
> 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: Reflect.getDefaultParameterValues

[Thomas]

My initial thoughts:

Perhaps exposing parameter names isn't a good idea - perhaps just return an 
array? You could easily pass an array to .bind, .call, etc.

I'm not sure the use cases for such a feature make it worth adding - isn't this 
a problem better solved by documentation? But if it did return an array, it 
might be useful. What are the typical use cases for this in other languages?

Also, should this just be a Reflect method or should it also be available on 
Function.prototype?

Thomas

> On 6 Oct 2015, at 1:04 AM, Benjamin Gruenbaum <benjami...@gmail.com> wrote:
> 
> Hey, other languages with default parameter values like Python, C#, Ruby and 
> PHP have a means to retrieve the default parameter values of a function.
> 
> From what I understand (correct me if I'm wrong) - there is no way to get the 
> default values of a parameter of a function in JavaScript. For example:
> 
> ```js
> function foo(x = 5){
> 
> }
> Reflect.getDefaultParameterValues(foo); // {x : 5}
> ```
> 
> This would be very nice to have in the language in my opinion. 
> 
> Now, doing this right sounds a bit challenging. since default parameters get 
> their value on every invocation of the function, it would have to return 
> getters (or functions) for values rather than values themselves. There is 
> also the issue of how `this` binding is handled by the said getters.
> 
> Is there interest in such an API? Is there any previous work or discussions 
> about it? 
> ___
> 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: Alternative to Promise

[Thomas]

>> There's only one variation that's standard, and every browser is or
>> will soon be implementing that one.
> 
> How can you said so? isn’t every Promise library pass A+ test considered 
> standard?

There is a specific variation of promises in the ECMAScript standard which is 
compatible with promises/a+. Passing the tests simply means your implementation 
of promises is compatible.

>> Continuations are a different concept, and don't address what we were
>> trying to solve when adopting promises.
> 
> Yes, they’re different, i would like to know what is promise solved but they 
> didn’t address ?
> 
>> Those languages often also have Promises, or Futures, or Tasks, or one
>> of the other closely-related names and concepts.
> 
> They have, but that’s totally different because they use lightweight thread. 
> Future in haskell is just a MVar.

If the filesystem API in node.js starts to use promises then it would be using 
a background thread, just as it is doing for callbacks at the moment.

>> On Oct 1, 2015, at 8:25 AM, Tab Atkins Jr.  wrote:
>> 
>>> On Wed, Sep 30, 2015 at 5:18 PM, 韩冬  wrote:
>>> Yes, i understand it’s too late to revise Promise design, my random thought 
>>> are:
>>> 
>>> 1. Why we put Promise into language?
>> 
>> Because it exposes useful functionality.  I recommend reading some of
>> the Promise explainers that exist for lots of examples.
>> 
>>> Promise are complex state machine, there can be so many variations, each 
>>> implementation have different performance characteristic, which one should 
>>> be built into language?
>> 
>> There's only one variation that's standard, and every browser is or
>> will soon be implementing that one.
>> 
>> The "state machine" isn't complex.  "unresolved" goes to either
>> "resolved to another promise", "fulfilled", or "rejected".  "resolved
>> to another promise" eventually turns into "fulfilled" or "rejected".
>> Or, of course, hangs, which "unresolved" can also do.
>> 
>>> 2. Why we don’t look for continuation based implementation at the first 
>>> place?
>> 
>> Continuations are a different concept, and don't address what we were
>> trying to solve when adopting promises.
>> 
>>> Lisp, haskell or even some transpiled to js language like elm use 
>>> continuation solve callbacks already, why didn’t port them?
>>> Now we invent a complex state machine based solution, a lot of people will 
>>> creating them everytime using an `async` without understand the cost.
>> 
>> Those languages often also have Promises, or Futures, or Tasks, or one
>> of the other closely-related names and concepts.
>> 
>> ~TJ
> ___
> 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: Template strings as a template language.

[Thomas]

> On 16 Sep 2015, at 12:39 AM, Claude Pache  wrote:
> 
> That doesn't make much sense, because regexpes are first-class objects, while 
> template literals are syntax.
> 
> The nearest equivalent of the string-to-regexp feature is the string-to-code 
> conversion facility provided by `eval` and `Function`.
> 
> I have the impression that people want to use features provided by `eval`, 
> `Function` or `with`, but without pronouncing these taboo words. 
> Just use them if you need to: at least you will be clear about what you are 
> really doing.

I would like to use a feature that today can only be achieved with `eval`, 
`with` or `Function`, but those three are hugely overpowered for the job 
(turning any old string into a template string). The 'taboo' about using eval, 
with and Function is  justified, and it'd be nice to not have to rely upon them.

> 
> —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

Re: Template strings as a template language.

[Thomas]

Doesn't the code in that gist create functions at runtime from strings? If so 
that's not any better than eval. 

> On 14 Sep 2015, at 8:50 PM, Andrea Giammarchi <andrea.giammar...@gmail.com> 
> wrote:
> 
> sorry, early send (I think it was a ctrl+return ? ) ... I was saying ..
> 
> without using eval and already discussed months ago:
> https://gist.github.com/WebReflection/8f227532143e63649804
> 
> it's based on the glorious `with` statement and it works like a charm
> 
> Regards
> 
> 
> 
> 
> 
> 
>> On Mon, Sep 14, 2015 at 11:49 AM, Andrea Giammarchi 
>> <andrea.giammar...@gmail.com> wrote:
>> without using eval, discussed already months ago
>> 
>> 
>>> On Mon, Sep 14, 2015 at 6:03 AM, Thomas <thomasjamesfos...@bigpond.com> 
>>> wrote:
>>> For those interested, this gist better shows what's being discussed: 
>>> https://gist.github.com/thomasfoster96/193e7c08aae499f810a1
>>> 
>>> Ron: Yes, that's already possible - but tagged template strings don't 
>>> really offer much of an advantage over a function as far as templating goes 
>>> (IMHO).
>>> 
>>> Thomas
>>> 
>>> On 14 Sep 2015, at 11:04 AM, Ron Buckton <ron.buck...@microsoft.com> wrote:
>>> 
>>>> This is theoretically possible:
>>>> 
>>>> ```
>>>> let t = $template`
>>>>   ${$item.permalink}
>>>>   ${$each($item.comments)`
>>>> ${$parent.permalink}
>>>> ${$if($item.title)`
>>>>   ${$parent.permalink}
>>>> `}
>>>>   `}
>>>> `;
>>>> let s = t(data);
>>>> ```
>>>> 
>>>> ...given an adequate implementation using proxies (to create bindings for 
>>>> e.g. `$item.permalink` for later evaluation) and tagged template 
>>>> functions. Whether or not this would make for a reasonable implementation 
>>>> is left to the reader.
>>>> 
>>>> Ron
>>>> From: Isiah Meadows
>>>> Sent: ‎9/‎13/‎2015 4:15 PM
>>>> To: Mark S. Miller
>>>> Cc: Bob Myers; es-discuss
>>>> Subject: Re: Template strings as a template language.
>>>> 
>>>> On Sun, Sep 13, 2015 at 7:09 PM, Mark S. Miller <erig...@google.com> wrote:
>>>> >
>>>> >
>>>> > On Sun, Sep 13, 2015 at 8:58 AM, Bob Myers <r...@gol.com> wrote:
>>>> >>
>>>> >> Templating languages typically "compile" templates into functions 
>>>> >> through
>>>> >> various lexical transformations.
>>>> >>
>>>> >> Consider a template file foo.tem:
>>>> >>
>>>> >> ```
>>>> >> My name is 
>>>> >> ${https://na01.safelinks.protection.outlook.com/?url=this.name=01%7c01%7cron.buckton%40microsoft.com%7ce705066eae3849ee21f008d2bc913033%7c72f988bf86f141af91ab2d7cd011db47%7c1=CY6YpX1n5jLScYGX2W1tIi2ndGlA7WI8ZTJUZjDL2Gw%3d}.
>>>> >> ```
>>>> >>
>>>> >> Lexically transform this into
>>>> >>
>>>> >> ```
>>>> >> function foo() {
>>>> >>   return `My name is ${this.name|}.`;
>>>> >> }
>>>> >>
>>>> >> Then invoke the template as eg
>>>> >>
>>>> >> ```
>>>> >> foo.call({name: 'Bob'})
>>>> >> ```
>>>> >>
>>>> >> Having said that, I doubt if ES6 template strings serve as a useful 
>>>> >> basis
>>>> >> for a full-fledged templating system. To take just one basic example, 
>>>> >> how
>>>> >> would one implement the equivalent of `{{#if}}`?
>>>> >
>>>> >
>>>> > What does `{{#if}}` mean?
>>>> >
>>>> 
>>>> An example from Handlebars' website (which is likely where he drew the
>>>> syntax from):
>>>> 
>>>> ```
>>>> {{permalink}}
>>>> {{#each comments}}
>>>>   {{../permalink}}
>>>> 
>>>>   {{#if title}}
>>>> {{../permalink}}
>>>>   {{/if}}
>>>> {{/each}}
>>>> ```
>>>> 
>>>> 
>>>> 
>>>> >>
>>>> >>
>>>> >> Bob
>>>> >>
>>>> >>
>>>> >> 

Re: Template strings as a template language.

[Thomas]

Sorry, I sent that before I saw your other explanation. 

On a second look that function does work pretty well. The use of Function still 
means strings are being evaluated at runtime, but I agree that it's 
safer/better than eval (though I'm not sure why CSP would still like it over 
eval).

Have you any plans to make the String.prototype.template function a proposal?

Thomas

> On 15 Sep 2015, at 1:52 AM, Andrea Giammarchi <andrea.giammar...@gmail.com> 
> wrote:
> 
> again, Function **is** better and different than eval, but I see this 
> conversation is bringing nothing so I'll just stop explaining.
> 
> Regards
> 
>> On Mon, Sep 14, 2015 at 3:47 PM, Thomas <thomasjamesfos...@bigpond.com> 
>> wrote:
>> Doesn't the code in that gist create functions at runtime from strings? If 
>> so that's not any better than eval. 
>> 
>>> On 14 Sep 2015, at 8:50 PM, Andrea Giammarchi <andrea.giammar...@gmail.com> 
>>> wrote:
>>> 
>>> sorry, early send (I think it was a ctrl+return ? ) ... I was saying ..
>>> 
>>> without using eval and already discussed months ago:
>>> https://gist.github.com/WebReflection/8f227532143e63649804
>>> 
>>> it's based on the glorious `with` statement and it works like a charm
>>> 
>>> Regards
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On Mon, Sep 14, 2015 at 11:49 AM, Andrea Giammarchi 
>>>> <andrea.giammar...@gmail.com> wrote:
>>>> without using eval, discussed already months ago
>>>> 
>>>> 
>>>>> On Mon, Sep 14, 2015 at 6:03 AM, Thomas <thomasjamesfos...@bigpond.com> 
>>>>> wrote:
>>>>> For those interested, this gist better shows what's being discussed: 
>>>>> https://gist.github.com/thomasfoster96/193e7c08aae499f810a1
>>>>> 
>>>>> Ron: Yes, that's already possible - but tagged template strings don't 
>>>>> really offer much of an advantage over a function as far as templating 
>>>>> goes (IMHO).
>>>>> 
>>>>> Thomas
>>>>> 
>>>>> On 14 Sep 2015, at 11:04 AM, Ron Buckton <ron.buck...@microsoft.com> 
>>>>> wrote:
>>>>> 
>>>>>> This is theoretically possible:
>>>>>> 
>>>>>> ```
>>>>>> let t = $template`
>>>>>>   ${$item.permalink}
>>>>>>   ${$each($item.comments)`
>>>>>> ${$parent.permalink}
>>>>>> ${$if($item.title)`
>>>>>>   ${$parent.permalink}
>>>>>> `}
>>>>>>   `}
>>>>>> `;
>>>>>> let s = t(data);
>>>>>> ```
>>>>>> 
>>>>>> ...given an adequate implementation using proxies (to create bindings 
>>>>>> for e.g. `$item.permalink` for later evaluation) and tagged template 
>>>>>> functions. Whether or not this would make for a reasonable 
>>>>>> implementation is left to the reader.
>>>>>> 
>>>>>> Ron
>>>>>> From: Isiah Meadows
>>>>>> Sent: ‎9/‎13/‎2015 4:15 PM
>>>>>> To: Mark S. Miller
>>>>>> Cc: Bob Myers; es-discuss
>>>>>> Subject: Re: Template strings as a template language.
>>>>>> 
>>>>>> On Sun, Sep 13, 2015 at 7:09 PM, Mark S. Miller <erig...@google.com> 
>>>>>> wrote:
>>>>>> >
>>>>>> >
>>>>>> > On Sun, Sep 13, 2015 at 8:58 AM, Bob Myers <r...@gol.com> wrote:
>>>>>> >>
>>>>>> >> Templating languages typically "compile" templates into functions 
>>>>>> >> through
>>>>>> >> various lexical transformations.
>>>>>> >>
>>>>>> >> Consider a template file foo.tem:
>>>>>> >>
>>>>>> >> ```
>>>>>> >> My name is 
>>>>>> >> ${https://na01.safelinks.protection.outlook.com/?url=this.name=01%7c01%7cron.buckton%40microsoft.com%7ce705066eae3849ee21f008d2bc913033%7c72f988bf86f141af91ab2d7cd011db47%7c1=CY6YpX1n5jLScYGX2W1tIi2ndGlA7WI8ZTJUZjDL2Gw%3d}.
>>>>>> >> ```
>>>>>> >>
>>>>>> >> Lexically transform this into
>>>>>> >>
>>>>>> >> ```
>

Re: Template strings as a template language.

[Thomas]

With all due respect to your solution (it works, and it works well), it's far 
from ideal to be relying upon `with` and Function. I guess what I'm trying to 
get at is - wouldn't it be better to think about having a built in version that 
didn't use with or eval (should be easy enough)? I sense that you're not 
confident about it being successful in that sense, but a built in function for 
this trumps with and Function any day of the week.

Thomas 

> On 15 Sep 2015, at 3:42 AM, Andrea Giammarchi <andrea.giammar...@gmail.com> 
> wrote:
> 
> nobody here raised the minimal interest in what I've achieved with those few 
> lines of code, I rather had people saying "with statement? ewww" or similar 
> reactions about Function like yours ... I don't think as proposal would ever 
> make it, it's too easy to polyfill so I'd expect many - 1
> 
> ¯\_(ツ)_/¯
> 
>> On Mon, Sep 14, 2015 at 5:23 PM, Thomas <thomasjamesfos...@bigpond.com> 
>> wrote:
>> Sorry, I sent that before I saw your other explanation. 
>> 
>> On a second look that function does work pretty well. The use of Function 
>> still means strings are being evaluated at runtime, but I agree that it's 
>> safer/better than eval (though I'm not sure why CSP would still like it over 
>> eval).
>> 
>> Have you any plans to make the String.prototype.template function a proposal?
>> 
>> Thomas
>> 
>>> On 15 Sep 2015, at 1:52 AM, Andrea Giammarchi <andrea.giammar...@gmail.com> 
>>> wrote:
>>> 
>>> again, Function **is** better and different than eval, but I see this 
>>> conversation is bringing nothing so I'll just stop explaining.
>>> 
>>> Regards
>>> 
>>>> On Mon, Sep 14, 2015 at 3:47 PM, Thomas <thomasjamesfos...@bigpond.com> 
>>>> wrote:
>>>> Doesn't the code in that gist create functions at runtime from strings? If 
>>>> so that's not any better than eval. 
>>>> 
>>>>> On 14 Sep 2015, at 8:50 PM, Andrea Giammarchi 
>>>>> <andrea.giammar...@gmail.com> wrote:
>>>>> 
>>>>> sorry, early send (I think it was a ctrl+return ? ) ... I was saying ..
>>>>> 
>>>>> without using eval and already discussed months ago:
>>>>> https://gist.github.com/WebReflection/8f227532143e63649804
>>>>> 
>>>>> it's based on the glorious `with` statement and it works like a charm
>>>>> 
>>>>> Regards
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Mon, Sep 14, 2015 at 11:49 AM, Andrea Giammarchi 
>>>>>> <andrea.giammar...@gmail.com> wrote:
>>>>>> without using eval, discussed already months ago
>>>>>> 
>>>>>> 
>>>>>>> On Mon, Sep 14, 2015 at 6:03 AM, Thomas <thomasjamesfos...@bigpond.com> 
>>>>>>> wrote:
>>>>>>> For those interested, this gist better shows what's being discussed: 
>>>>>>> https://gist.github.com/thomasfoster96/193e7c08aae499f810a1
>>>>>>> 
>>>>>>> Ron: Yes, that's already possible - but tagged template strings don't 
>>>>>>> really offer much of an advantage over a function as far as templating 
>>>>>>> goes (IMHO).
>>>>>>> 
>>>>>>> Thomas
>>>>>>> 
>>>>>>> On 14 Sep 2015, at 11:04 AM, Ron Buckton <ron.buck...@microsoft.com> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> This is theoretically possible:
>>>>>>>> 
>>>>>>>> ```
>>>>>>>> let t = $template`
>>>>>>>>   ${$item.permalink}
>>>>>>>>   ${$each($item.comments)`
>>>>>>>> ${$parent.permalink}
>>>>>>>> ${$if($item.title)`
>>>>>>>>   ${$parent.permalink}
>>>>>>>> `}
>>>>>>>>   `}
>>>>>>>> `;
>>>>>>>> let s = t(data);
>>>>>>>> ```
>>>>>>>> 
>>>>>>>> ...given an adequate implementation using proxies (to create bindings 
>>>>>>>> for e.g. `$item.permalink` for later evaluation) and tagged template 
>>>>>>>> functions. Whether or not this would make for a reasonable 
&g

Template strings as a template language.

[Thomas]

I'd really like to use Template strings as a templating language, but unless I 
include a lot of boilerplate code (export a template string wrapped in a 
function from a file) or use eval after loading a file as a string it's pretty 
much impossible.

Is there a simpler way to be doing this? Or any plans for a type of eval that 
only executes it's argument as a template string?




Sent from my iPhone
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Template strings as a template language.

[Thomas]

They would be whatever they are in the scope in which the template string is 
evaluated. 

Thomas

> On 14 Sep 2015, at 12:15 AM, Mark S. Miller <erig...@google.com> wrote:
> 
> 
> 
>> On Sun, Sep 13, 2015 at 7:08 AM, Thomas <thomasjamesfos...@bigpond.com> 
>> wrote:
>> What I've been doing:
>> 
>> export const template = ({title, content}) => `template string for ${title}`;
>> 
>> Or variations thereof. I then import that module wherever I need to use the 
>> template and call it as a function.
> 
> If you were not to call it as a function, where would it get its bindings for 
> title and content?
> 
>  
>> 
>> Using eval and having the template string as a normal string (so, read the 
>> template from file as a string, wrap it with back ticks, and then pass it to 
>> eval) at the moment is risky since it's possible for input to prematurely 
>> end the template string and do nasty stuff*. Ideally there would be a 
>> variant of eval where the string to be evaluated must be a template string 
>> expression.
>> 
>> Thomas
>> 
>> * I'm aware that someone could still put something inside a template string 
>> and do nasty stuff, but I'm not sure if that's a easily solved problem.
>> 
>>> On 13 Sep 2015, at 10:08 PM, Mark S. Miller <erig...@google.com> wrote:
>>> 
>>>> On Sun, Sep 13, 2015 at 2:42 AM, Thomas <thomasjamesfos...@bigpond.com> 
>>>> wrote:
>>>> I'd really like to use Template strings as a templating language, but 
>>>> unless I include a lot of boilerplate code (export a template string 
>>>> wrapped in a function from a file)
>>> 
>>> Hi Thomas, could you give a concrete example of the boilerplate you have in 
>>> mind and what it accomplishes?
>>> 
>>>  
>>>> or use eval after loading a file as a string it's pretty much impossible.
>>>> 
>>>> Is there a simpler way to be doing this? Or any plans for a type of eval 
>>>> that only executes it's argument as a template string?
>>> 
>>> I am unaware of any such plans. Could you give an example of what it looks 
>>> like and what it would accomplish? Thanks.
>>>  
>>> 
>>> -- 
>>> Cheers,
>>> --MarkM
> 
> 
> 
> -- 
> Cheers,
> --MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Template strings as a template language.

[Thomas]

What I've been doing:

export const template = ({title, content}) => `template string for ${title}`;

Or variations thereof. I then import that module wherever I need to use the 
template and call it as a function.

Using eval and having the template string as a normal string (so, read the 
template from file as a string, wrap it with back ticks, and then pass it to 
eval) at the moment is risky since it's possible for input to prematurely end 
the template string and do nasty stuff*. Ideally there would be a variant of 
eval where the string to be evaluated must be a template string expression.

Thomas

* I'm aware that someone could still put something inside a template string and 
do nasty stuff, but I'm not sure if that's a easily solved problem.

> On 13 Sep 2015, at 10:08 PM, Mark S. Miller <erig...@google.com> wrote:
> 
>> On Sun, Sep 13, 2015 at 2:42 AM, Thomas <thomasjamesfos...@bigpond.com> 
>> wrote:
>> I'd really like to use Template strings as a templating language, but unless 
>> I include a lot of boilerplate code (export a template string wrapped in a 
>> function from a file)
> 
> Hi Thomas, could you give a concrete example of the boilerplate you have in 
> mind and what it accomplishes?
> 
>  
>> or use eval after loading a file as a string it's pretty much impossible.
>> 
>> Is there a simpler way to be doing this? Or any plans for a type of eval 
>> that only executes it's argument as a template string?
> 
> I am unaware of any such plans. Could you give an example of what it looks 
> like and what it would accomplish? Thanks.
>  
> 
> -- 
> Cheers,
> --MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Template strings as a template language.

[Thomas]

Mark,

I'll put together a GitHub gist or repo and send it to you in the morning (I 
should be asleep) to make things clearer.

I'll try explaining it differently in the meantime:
What I'd like to do is use ES6 Template string as a templating language. For 
the sake of readability and maintainability, it would be nice to keep the 
templates separate from the code that uses them, and not have them inlined. 

The best solution for my use case would be to have a special eval function 
which would evaluate a normal string variable as if it was a template string, 
in the current scope. 

Thomas

> On 14 Sep 2015, at 1:10 AM, Mark S. Miller <erig...@google.com> wrote:
> 
> The great achievement of modern js module systems including the es6 std 
> module system is to end the greatest pain of prior js: linkage through side 
> effects to the shared global scope. Good riddance.
> 
> If you're talking about a scope other than the global one, how would a 
> template come to be evaluated in that scope? If the answer is that it is 
> textually nested in that scope, then isn't that what template strings already 
> do?
> 
> 
> 
> 
> 
>> On Sun, Sep 13, 2015 at 7:24 AM, Thomas <thomasjamesfos...@bigpond.com> 
>> wrote:
>> They would be whatever they are in the scope in which the template string is 
>> evaluated. 
>> 
>> Thomas
>> 
>>> On 14 Sep 2015, at 12:15 AM, Mark S. Miller <erig...@google.com> wrote:
>>> 
>>> 
>>> 
>>>> On Sun, Sep 13, 2015 at 7:08 AM, Thomas <thomasjamesfos...@bigpond.com> 
>>>> wrote:
>>>> What I've been doing:
>>>> 
>>>> export const template = ({title, content}) => `template string for 
>>>> ${title}`;
>>>> 
>>>> Or variations thereof. I then import that module wherever I need to use 
>>>> the template and call it as a function.
>>> 
>>> If you were not to call it as a function, where would it get its bindings 
>>> for title and content?
>>> 
>>>  
>>>> 
>>>> Using eval and having the template string as a normal string (so, read the 
>>>> template from file as a string, wrap it with back ticks, and then pass it 
>>>> to eval) at the moment is risky since it's possible for input to 
>>>> prematurely end the template string and do nasty stuff*. Ideally there 
>>>> would be a variant of eval where the string to be evaluated must be a 
>>>> template string expression.
>>>> 
>>>> Thomas
>>>> 
>>>> * I'm aware that someone could still put something inside a template 
>>>> string and do nasty stuff, but I'm not sure if that's a easily solved 
>>>> problem.
>>>> 
>>>>> On 13 Sep 2015, at 10:08 PM, Mark S. Miller <erig...@google.com> wrote:
>>>>> 
>>>>>> On Sun, Sep 13, 2015 at 2:42 AM, Thomas <thomasjamesfos...@bigpond.com> 
>>>>>> wrote:
>>>>>> I'd really like to use Template strings as a templating language, but 
>>>>>> unless I include a lot of boilerplate code (export a template string 
>>>>>> wrapped in a function from a file)
>>>>> 
>>>>> Hi Thomas, could you give a concrete example of the boilerplate you have 
>>>>> in mind and what it accomplishes?
>>>>> 
>>>>>  
>>>>>> or use eval after loading a file as a string it's pretty much impossible.
>>>>>> 
>>>>>> Is there a simpler way to be doing this? Or any plans for a type of eval 
>>>>>> that only executes it's argument as a template string?
>>>>> 
>>>>> I am unaware of any such plans. Could you give an example of what it 
>>>>> looks like and what it would accomplish? Thanks.
>>>>>  
>>>>> 
>>>>> -- 
>>>>> Cheers,
>>>>> --MarkM
>>> 
>>> 
>>> 
>>> -- 
>>> Cheers,
>>> --MarkM
> 
> 
> 
> -- 
> Cheers,
> --MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Template strings as a template language.

[Thomas]

> On 14 Sep 2015, at 1:38 AM, Alexander Jones  wrote:
> 
> Not exactly sure what you mean. But if you are you asking how
> 
> ```js
> let template = 'this ${foo} and that ${bar}';
> // later...
> let output = String.evalTemplate(template, {foo: "thing", bar: "other 
> thing"});
> ```
> is different to
> 
> ```js
> let template = ({foo, bar}) => `this ${foo} and that ${bar}`;
> // later...
> let output = template({foo: "thing", bar: "other thing"});
> ```
> 
> then I have a couple of answers off the top of my head:
>  * The value of `template` is a simple string and thus can be trivially 
> loaded from JSON or a file in the former case, but not the latter. Getting 
> the latter involves some kind of eval anyway.

Exactly - being able to not touch modules for something like this is important.

>  * The number of occurrences of each template parameter (e.g. `"foo"`) is 
> limited to once at the definition site, and once at the invocation site, 
> instead of twice at definition. `with` seems like a non-starter.

Minimising definitions is worth doing. Although, the good thing about arguments 
is that it's possible to specify default values...
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Template strings as a template language.

[Thomas]

For those interested, this gist better shows what's being discussed: 
https://gist.github.com/thomasfoster96/193e7c08aae499f810a1

Ron: Yes, that's already possible - but tagged template strings don't really 
offer much of an advantage over a function as far as templating goes (IMHO).

Thomas

> On 14 Sep 2015, at 11:04 AM, Ron Buckton <ron.buck...@microsoft.com> wrote:
> 
> This is theoretically possible:
> 
> ```
> let t = $template`
>   ${$item.permalink}
>   ${$each($item.comments)`
> ${$parent.permalink}
> ${$if($item.title)`
>   ${$parent.permalink}
> `}
>   `}
> `;
> let s = t(data);
> ```
> 
> ...given an adequate implementation using proxies (to create bindings for 
> e.g. `$item.permalink` for later evaluation) and tagged template functions. 
> Whether or not this would make for a reasonable implementation is left to the 
> reader.
> 
> Ron
> From: Isiah Meadows
> Sent: ‎9/‎13/‎2015 4:15 PM
> To: Mark S. Miller
> Cc: Bob Myers; es-discuss
> Subject: Re: Template strings as a template language.
> 
> On Sun, Sep 13, 2015 at 7:09 PM, Mark S. Miller <erig...@google.com> wrote:
> >
> >
> > On Sun, Sep 13, 2015 at 8:58 AM, Bob Myers <r...@gol.com> wrote:
> >>
> >> Templating languages typically "compile" templates into functions through
> >> various lexical transformations.
> >>
> >> Consider a template file foo.tem:
> >>
> >> ```
> >> My name is 
> >> ${https://na01.safelinks.protection.outlook.com/?url=this.name=01%7c01%7cron.buckton%40microsoft.com%7ce705066eae3849ee21f008d2bc913033%7c72f988bf86f141af91ab2d7cd011db47%7c1=CY6YpX1n5jLScYGX2W1tIi2ndGlA7WI8ZTJUZjDL2Gw%3d}.
> >> ```
> >>
> >> Lexically transform this into
> >>
> >> ```
> >> function foo() {
> >>   return `My name is ${this.name|}.`;
> >> }
> >>
> >> Then invoke the template as eg
> >>
> >> ```
> >> foo.call({name: 'Bob'})
> >> ```
> >>
> >> Having said that, I doubt if ES6 template strings serve as a useful basis
> >> for a full-fledged templating system. To take just one basic example, how
> >> would one implement the equivalent of `{{#if}}`?
> >
> >
> > What does `{{#if}}` mean?
> >
> 
> An example from Handlebars' website (which is likely where he drew the
> syntax from):
> 
> ```
> {{permalink}}
> {{#each comments}}
>   {{../permalink}}
> 
>   {{#if title}}
> {{../permalink}}
>   {{/if}}
> {{/each}}
> ```
> 
> 
> 
> >>
> >>
> >> Bob
> >>
> >>
> >> ___
> >> es-discuss mailing list
> >> es-discuss@mozilla.org
> >> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmail.mozilla.org%2flistinfo%2fes-discuss=01%7c01%7cron.buckton%40microsoft.com%7ce705066eae3849ee21f008d2bc913033%7c72f988bf86f141af91ab2d7cd011db47%7c1=Vk9C%2fonHktgLCsW%2f395PrpBWefRcs6XFqJk7HTVbunE%3d
> >>
> >
> >
> >
> > --
> > Cheers,
> > --MarkM
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmail.mozilla.org%2flistinfo%2fes-discuss=01%7c01%7cron.buckton%40microsoft.com%7ce705066eae3849ee21f008d2bc913033%7c72f988bf86f141af91ab2d7cd011db47%7c1=Vk9C%2fonHktgLCsW%2f395PrpBWefRcs6XFqJk7HTVbunE%3d
> >
> 
> 
> 
> -- 
> Isiah Meadows
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmail.mozilla.org%2flistinfo%2fes-discuss=01%7c01%7cron.buckton%40microsoft.com%7ce705066eae3849ee21f008d2bc913033%7c72f988bf86f141af91ab2d7cd011db47%7c1=Vk9C%2fonHktgLCsW%2f395PrpBWefRcs6XFqJk7HTVbunE%3d
> ___
> 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: es-discuss Digest, Vol 103, Issue 30

[Thomas]

Sent from my iPhone

> On 14 Sep 2015, at 2:59 PM, Mohsen Azimi <m...@azimi.me> wrote:
> 
> I actually used template strings as templateing in two of my projects. You 
> can take aa look here:
> 
> https://github.com/mohsen1/json-schema-view-js/blob/master/src/index.js#L59-L175

Will take a look.

> 
> Two main problems I had with this was:
> 
> * There is no `if` condition in template strings. I had to **hack** my way by 
> yet another template string function that returns empty string if the 
> condition is falsy: 
> https://github.com/mohsen1/json-schema-view-js/blob/master/src/helpers.js#L9-L21

Wouldn't you use the ternary operator? E.g.

condition ? iftrue : iffalse

> * The falsy stuff are not rendered as you expect (empty string):
> 
> ```js
> let o = undefined;
> console.log(`${o}`); // => 'undefined'
> ```

I think that behaviour is what I'd expect (and different toString behaviour in 
template strings would be confusing).

> 
>> On Sun, Sep 13, 2015 at 6:04 PM <es-discuss-requ...@mozilla.org> wrote:
>> Send es-discuss mailing list submissions to
>> es-discuss@mozilla.org
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://mail.mozilla.org/listinfo/es-discuss
>> or, via email, send a message with subject or body 'help' to
>> es-discuss-requ...@mozilla.org
>> 
>> You can reach the person managing the list at
>> es-discuss-ow...@mozilla.org
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of es-discuss digest..."
>> Today's Topics:
>> 
>>1. Re: Template strings as a template language. (Thomas)
>>2. Re: Template strings as a template language. (Bob Myers)
>>3. Re: Template strings as a template language. (Mark S. Miller)
>>    4. Re: Template strings as a template language. (Isiah Meadows)
>>5. RE: Template strings as a template language. (Ron Buckton)
>> 
>> 
>> 
>> -- Forwarded message --
>> From: Thomas <thomasjamesfos...@bigpond.com>
>> To: Alexander Jones <a...@weej.com>
>> Cc: "Mark S. Miller" <erig...@google.com>, es-discuss 
>> <es-discuss@mozilla.org>
>> Date: Mon, 14 Sep 2015 01:47:37 +1000
>> Subject: Re: Template strings as a template language.
>> 
>> 
>> > On 14 Sep 2015, at 1:38 AM, Alexander Jones <a...@weej.com> wrote:
>> >
>> > Not exactly sure what you mean. But if you are you asking how
>> >
>> > ```js
>> > let template = 'this ${foo} and that ${bar}';
>> > // later...
>> > let output = String.evalTemplate(template, {foo: "thing", bar: "other 
>> > thing"});
>> > ```
>> > is different to
>> >
>> > ```js
>> > let template = ({foo, bar}) => `this ${foo} and that ${bar}`;
>> > // later...
>> > let output = template({foo: "thing", bar: "other thing"});
>> > ```
>> >
>> > then I have a couple of answers off the top of my head:
>> >  * The value of `template` is a simple string and thus can be trivially 
>> > loaded from JSON or a file in the former case, but not the latter. Getting 
>> > the latter involves some kind of eval anyway.
>> 
>> Exactly - being able to not touch modules for something like this is 
>> important.
>> 
>> >  * The number of occurrences of each template parameter (e.g. `"foo"`) is 
>> > limited to once at the definition site, and once at the invocation site, 
>> > instead of twice at definition. `with` seems like a non-starter.
>> 
>> Minimising definitions is worth doing. Although, the good thing about 
>> arguments is that it's possible to specify default values...
>> 
>> 
>> 
>> -- Forwarded message --
>> From: Bob Myers <r...@gol.com>
>> To: es-discuss@mozilla.org
>> Cc: 
>> Date: Sun, 13 Sep 2015 21:28:04 +0530
>> Subject: Re: Template strings as a template language.
>> Templating languages typically "compile" templates into functions through 
>> various lexical transformations.
>> 
>> Consider a template file foo.tem:
>> 
>> ```
>> My name is ${this.name}.
>> ```
>> 
>> Lexically transform this into
>> 
>> ```
>> function foo() {
>>   return `My name is ${this.name|}.`;
>> }
>> 
>> Then invoke the template as eg
>> 
>> ```
>> foo.call({name: 'Bob'})
>> ```
>> 
>>

Re: Exponentiation operator precedence

[Thomas]

There's still the issue of exponentiation being right-associative. Unless ** 
becomes an operator which behaves differently as to how it would in a high 
school maths class, we're at an impasse.

That said, ^ is usually the operator used for exponentiation outside 
programming languages when you need to express an equation in text. It could be 
made explicit that ** is a variant on 'exponentiation', but then maybe things 
are deviating from being useful.

Thomas

 On 27 Aug 2015, at 3:28 AM, Brendan Eich bren...@mozilla.org wrote:
 
 Yehuda Katz cited an acronym taught when he was a wee lad learning algebra: 
 PEMDAS (Parentheses, Exponentiation, Multiplication/Dviistion, 
 Addition/Subtraction). Who else learned this?
 
 There's nothing sacrosanct about binary precedence being generally lower than 
 unary. Consider the property access operators in JS. But the precedent to 
 which all cited languages bow is Math and that's what programmers (mostly) 
 study. I think you are making too much out of the local -x ** y case in light 
 of this global argument.
 
 /be
 
 Mark S. Miller wrote:
 I don't get it. The conflict between
 
 * the history of ** in other languages,
 * the general pattern that unary binds tighter than binary
 
 seems unresolvable. By the first bullet, -2 ** 2 would be -4. By the second, 
 it would be 4. Either answer will surprise too many programmers. By 
 contrast, no one is confused by either -Math.pow(2, 2) or Math.pow(-2, 2).
 ___
 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: Exponentiation operator precedence

[Thomas]

This may be of some relevance: 
https://en.wikipedia.org/wiki/Order_of_operations#Special_cases

Exponentiation is clearly exponentially more complicated in terms of order of 
operations and precedence than other operators if the desire is to follow 
'standard maths'. Otherwise, making Exponentiation behave differently in 
JavaScript to how it does elsewhere is going to be a constant source of bugs 
and needing parentheses just to get the desire behaviour negates the whole 
point of making it an operator vs a function.

Thomas

 On 26 Aug 2015, at 1:49 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
 
 
 On Aug 25, 2015, at 8:11 AM, Mark S. Miller wrote:
 
 I think we should drop the feature. Given the conflict between
 
 * the history of ** in other languages, 
 * the general pattern that unary binds tighter than binary
 
 any solution at this point will confuse many people. These confusions will 
 not result in a confusing static rejection but in runtime behavior that 
 *sometimes* violates expectations. I was all for adding ** to the language 
 when it did not have these problems. But it does. The minor convenience it 
 adds is not worth these costs. By contrast, no one is confused about the 
 parsing of calls to Math.pow.
 
 When in doubt, leave it out.
 
 I've had the same reaction to this recent thread.  It seems like the 
 functional form (Math.pow) is a much less confusing formulation for  use in 
 JS expressions.
 
 It's interesting to note that while early algebraic  languages such as 
 FORTRAN, Algol 60, BASIC, PL/I all had exponentiation operators the next 
 couple generations of similar languages including Pascal, C, C++, Java, and 
 C# do not. Each of those languages could have had an exponentiation operator 
 but choose to exclude it.
 
 The utility of an  exponentiation operation may simply not be worth the 
 complexity and potential for confusion it introduces into a language with a 
 rich set of operators. 
 
 Allen
 ___
 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

NativeError Introductory Text Error?

[Thomas Wood]

Hi all,

I believe there to be an error in the introductory text for ES6 19.5.6:
NativeError Object Structure, it was also present in the text for ES5.1
and I believe it is a hang-over from ES3.

19.5.6 reads:
 [...] Each of these objects has the structure described below,
 differing only in the name used as the constructor name instead of
 NativeError, in the name property of the prototype object, and in the
 implementation-defined message property of the prototype object.
 [...]

The statement that the message property of the _prototype_ object is
inconsistent with the later definition of that property in 19.5.6.3.2:
 The initial value of the message property of the prototype for a
 givenNativeError constructor is the empty String.

Looking back to ES3, the definition of NativeError.prototype.message
(15.11.7.10) was:
 The initial value of the message property of the prototype for a
 givenNativeError constructor is an implementation-defined string.


Examination of this issue came about as a result of discussion as to
whether instances of NativeErrors are defined to have
implmentation-dependent messages, which I believe is the intent of this
portion of the introductory text?

I'll also note here that the name property is typeset in the wrong font.

I'd have put this directly into the bugzilla instance, but I'm not
receiving the confirmation email when requesting a new account.

Regards,
Thomas Wood
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

re: should we rename the Program grammar production?

[Russ Thomas]

list-noob here - I hope this gets threaded ok.

 One of the pieces of awkward ES specification terminology has been the use of 
 the word Program as the name for a global top-level StatementList.

This, I think is what (the noun) program should be reserved for.

 A ES Program is commonly only a single fragment of what most of us commonly 
 think of as a program.

And these sub-components are lesser nouns, script -s

 This terminology mismatch is going to get ever worse as we integrate modules.

All of which are scripts to become a part of the global top-level
StatementList = Program.

Said another way, we don't directly write programs, we compose scripts
which are marshalled/assembled into the Program by the
runtime/compiler, which is, if I've understood Allen (heck, even
myself!) correctly, the opposite of what Allen is suggesting :

 I proposed that we replace Program in this context with Script.  This is 
 much less confusing and matches the most common manifestation of an ES 
 Program as an HTML script block.

And of course, script is only *one* mechanism by which scripts are
placed in the Program/global top-level StatementList (modules, node
et al).

$0.02
Russ / @codacoder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

ES5 question: Error object property 'message' - enumerable or not?

[Thomas L. Shinnick]

An issue popped up where V8 recently made everything in Error objects 
non-enumerable.  This was surprising to some apps.  More surprising 
is the insistence that this is required by the ES5 spec.


As a simplistic reader, when own property is mentioned here

15.11.2.1 new Error (message)

If the argument message is not undefined, the message own property
of the newly constructed object is set to ToString(message).

I just naturally think this property it is not supposed to be 
mysteriously unseen.  Yet other general statements in the spec have 
people think everything not explicitly labeled enumerable _can't_ be.


  http://code.google.com/p/v8/issues/detail?id=1215But the spec 
is the spec
  http://code.google.com/p/v8/issues/detail?id=1595...this 
consequence may have been unintended.


Does the ES5 spec intend for 'message' property of Error objects to 
be non-enumerable?


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.indexOf typo

[Thomas L. Shinnick]

At 09:53 AM 4/8/2009, James Graham wrote:
Unless I am mistaken k is the current array index and n is the 
initial array index, so the step Repeat while k  n is a noop. I 
presume it should say Repeat while k  length


Yes, this was changed after the last errata.

15.4.4.14Array.prototype.indexOf p.124
  9.   Repeat, while kn
--
  9.   Repeat, while klen

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss