Re: Is anyone able to reach wiki.ecmascript.org ?

[Russell Leggett]

Down for me too
On Sat, Oct 10, 2015 at 10:27 AM Calvin Metcalf 
wrote:

> Not just you
> http://downforeveryoneorjustme.com/wiki.ecmascript.org
>
> On Sat, Oct 10, 2015, 9:52 AM Mark S. Miller  wrote:
>
>> Seems to be down. Not answering pings.
>>
>> --
>> Cheers,
>> --MarkM
>> ___
>> 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: Move es-discuss to discuss.webplatform.org?

[Russell Leggett]

>
>
> If not, does Discourse support email as a first-class subscription
> mechanism? That (plus mute) might help.


I haven't used discourse a ton, but according to the features page:

http://www.discourse.org/about/

They support email notifications and replies, as well as an opt in "mailing
list" mode:

Opt into a special mode where all messages are sent to you via email,
> exactly like a mailing list. Start new topics via email.


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

Re: Move es-discuss to discuss.webplatform.org?

[Russell Leggett]

On Fri, Jun 19, 2015 at 5:21 PM, // ravi  wrote:

> On Jun 19, 2015, at 5:12 PM, C. Scott Ananian 
> wrote:
> >
> > No, thank you.​
> > Email clients are the ultimate forum aggregators.
>
>
> +1 on “No, thank you". Email works, email has are full-featured clients,
> do not force browser use, etc, etc.
>
>
I have to admit, I find this attitude somewhat ironic. The standards group
for a major component of the browser avoiding browsers. I understand trying
to avoid the replication of email. These days, there are a lot of
communication platforms that don't interoperate, and so it may seem like
email is still a universal client, and therefore who needs anything else -
but seriously, are you all so cynical that the additional value gained
means nothing? As long as discourse supports email notifications/responses,
then I don't really see the compelling reason not to make the switch. The
advantages of switching are numerous: better search, easier participations,
easier organization/categorization of threads, better formatting/code
highlighting, etc.

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

Re: classes and enumerability

[Russell Leggett]

On Wednesday, December 24, 2014, Kevin Smith  wrote:

> The question is: what should ES6 classes choose as the default? What's the
>> most useful default, independent of various backward-looking consistencies?
>> What, if the future is bigger than the past, would be best?
>>
>
> Framed that way, then non-enumerability.
>
> If we want to preserve any kind of conceptual integrity for enumerability,
> then enumerability must indicate that the property is a data element within
> a data structure.
>
> Whether enumerability is worth preserving, I don't know.
>
> I'll just throw out mixins as a possible reason to keep enumerability.

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

Re: arrow functions and dart

[Russell Leggett]

> We already have two (three? not sure about JSC) engines which implement
> arrow functions, plus Traceur. It seems silly to talk about changing the
> syntax at this point when people have shown they’re already happy with the
> arrow.
>

Agreed. This is basically bikeshedding after the bike shed has been built.
Surely there are other areas you could give your attention/feedback to.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Bundling vs sending serialized dependency graph

[Russell Leggett]

Not sure if my real world use case would be super helpful here, but just in
case, here it is. The app I work on is a very large single page app - over
150,000 lines of JS across more than 2000 files. Uncompressed, unminified,
and concatenated together, it weighs in at close to 10MB. We've been using
an in-house module solution (written before most modern tools), and it does
smart bundling using a dependency graph. We use import statements (in
comments) that are read using a build tool which builds the graph. The full
graph is broken into a hierarchy of code bundles that rely on load order
expectations. The hierarchy can go many levels deep if needed. Common
dependencies are moved up to the closest shared ancestor bundle, so there
is no code in multiple code bundles.

Right now, this solution works pretty well for us, but is certainly not
ideal. One nice thing is that there is a relatively small number (~40) of
independent bundles and they can all be created upfront and served from a
CDN with far future expiration. The downside is that there are definitely
common dependencies that are bundled into ancestors higher up than they
ideally should be.

With the current spec of modules and loaders, there is no way that we could
switch and rely on the behavior of ES6 modules for the reasons specified
here. If I have some new code loading point, I want all of the required
code to start loading at once. I can't wait for the dependency graph to be
figured out as files are getting loaded. The proposal for being able to
preload a dependency graph upfront would be tremendously useful for making
the switch. My preference would be some kind of json format through a
JavaScript API and not some weird script tag thing.

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

Re: WeakMap not the weak needed for zombie views

[Russell Leggett]

Sorry to take this on a tangent from the topic of WeakRefs, but the way
I've solved the OP's problem in my own code is by tying anything that needs
cleanup to element ids. Any time I need to update the HTML, I go through a
central method that crawl that part of the dom and purges it using the ids
as keys in maps of bindings/widgets. Has worked very well for me.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[Russell Leggett]

On Fri, Jun 27, 2014 at 10:11 AM, Kevin Smith  wrote:

>
>>
>> var mkdirp = require('mkdirp');
>>
>
> Exactly.  In ES, you would see this:
>
> import { mkdrip } from "mkdirp";
>
> Python has a somewhat similar module system, and import-renaming is the
> exception, not the rule.  Also, I've never heard anyone complain about
> having to know the name of a module member.  In fact, specifying the
> exported name is essential for tracing out a code base that you're
> unfamiliar with.
>
>
Haha, yes, you and I seem to be sharing a brain on this, I sent early and
you wrote most of what I wrote. I still like curly-free, but that's
bikeshedding to me. The important point is removing default exports.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[Russell Leggett]

>
>
> Ok, so can I just ask a serious question. I looked at the mkdirp library,
> and in their own documentation, they use:
>
> var mkdirp = require('mkdirp');
> So let's say in the new world order, no default exports, this is a named
> export mkdirp. Is it *really* that bad a thing to just use the name they
> chose for their API? I mean what about all of the likely cases of exporting
> a class. Would you advocate for those classes to be aliased before use?
> What about methods? Those are typically unchanged. The argument has been
> made that without default exports, library users would then have to known
> the name of the exported member. Is that really a serious complaint? You
> *have* to know what everything else is called, what parameters are
> expected, etc. I would go as far as to say that either 1 of 2 things is
> happening.
>
>
>
Ok, accidentally sent...  either 1 of 2 things is happening

1) The imported function is always called the same thing when imported. Its
a de facto standard.
2) There is no de facto standard, and people call it a variety of things.

I would argue that 1 is easy to transition, just export with that name, and
2 is not really a good thing. Its much harder to read or grep your code. It
is an anti-pattern that should not be given so much sugar. Aliasing is
still possible, but more awkward.

I know Kevin and I both said this, but IMO the reason this pattern became
so popular was to avoid:

var mkdirp = require("mkdirp").mkdirp;

In my proposal (no curlies), that's simply:

import mkdirp from "mkdirp";

The big thing missing is just ease of aliasing, and I don't really see that
as a problem. I'd love to hear an argument for why I'm wrong.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[Russell Leggett]

On Fri, Jun 27, 2014 at 3:52 AM, Michał Gołębiowski 
wrote:

> On Fri, Jun 27, 2014 at 9:44 AM, Russell Leggett <
> russell.legg...@gmail.com> wrote:
>>
>> No, that example would be:
>>
>> import "mkdirp" as mkdir;
>>
>> Its actually shorter than node.
>>
>
> But in current proposal the module object cannot be a function from what I
> understand. So you'd have to create a named export and import it as I wrote.
>
>
Ok, so can I just ask a serious question. I looked at the mkdirp library,
and in their own documentation, they use:

var mkdirp = require('mkdirp');
So let's say in the new world order, no default exports, this is a named
export mkdirp. Is it *really* that bad a thing to just use the name they
chose for their API? I mean what about all of the likely cases of exporting
a class. Would you advocate for those classes to be aliased before use?
What about methods? Those are typically unchanged. The argument has been
made that without default exports, library users would then have to known
the name of the exported member. Is that really a serious complaint? You
*have* to know what everything else is called, what parameters are
expected, etc. I would go as far as to say that either 1 of 2 things is
happening.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[Russell Leggett]

On Fri, Jun 27, 2014 at 3:41 AM, Michał Gołębiowski 
wrote:

> On Thu, Jun 26, 2014 at 4:50 PM, Russell Leggett <
> russell.legg...@gmail.com> wrote:
>>
>>
>> //import a single named export
>> import foo from "bar";
>>
>> //import multiple named exports
>> import foo, baz from "bar";
>>
>> //alias an imported named export
>> import foo as fooAlias from "bar";
>>
>> //import the module
>> import "bar" as bar;
>>
>
> That would put a lot of Node modules exporting a single object/function at
> a disadvantage. Compare:
> ```js
> var mkdr = require('mkdirp');
> ```
> to:
> ```js
> import mkdirp as mkdr from mkdirp;
> ```
>
> I like that the most common module usage can be done simpler.
>
>
No, that example would be:

import "mkdirp" as mkdir;

Its actually shorter than node.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[Russell Leggett]

> I like the fact that this doesn't look like destructuring, since variable
> binding is different from destructuring assignment.  Could
> ```
> import foo, baz from "bar" as bar;
> ```
> allowed simultanous import of named exports and the module itself?  If so,
> the grammar gains a pleasing regularity.
>

You know, I hadn't even thought of that, but yes, I think that could work
and be useful.


>
> OTOH, I think this syntax reorganization is orthogonal to some of the
> other issues discussed.  In particular, your latter proposal still allows
> for user confusion between:
> ```
> import _ from "underscore";
> import "underscore" as _;
> ```
> The various proposals seem to try to address this by making these
> semantically identical (or near-identical, with some cooperation from the
> module author).
>
>
Default exports are confusing. No way around it. No other system that I
have seen really does it. If you look at the way node does default exports,
its really so much a default export as a module replacement. As in, instead
of giving you a module when you import, the system gives you that one
exported thing. I tried to mirror those same semantics, as I think that is
the only real argument for default exports. There is existing code in place
that uses those semantics heavily. If we are trying to pull from
experience, keep it consistent. The way to do that is to make default
exports get imported using the same syntax as module imports.

```
import _ from "underscore"; //looks like getting a member from the
underscore module
import "underscore" as _; //looks like importing the whole module and
naming it
```

I don't think most developers will really understand the clear difference
between a module and a regular object and therefore won't seem weird if a
module is a function. They key point is - are you importing the whole thing
or a member of the thing.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[Russell Leggett]

> Now the author can choose to export more things later without making
>> breaking changes to the module. The only downside to this is the
>> (apparently mandatory) curly braces around the imported object. If single
>> export/import becomes the convention with ES6 modules then users will be
>> forced to type an extra pair of {} several times in most of their files. Is
>> the two extra characters something we can live with?
>>
>
>
> I have a good bit of experience coding ES modules, and I was worried about
> that at first.  But hasn't been a problem for me.  Then again, I'm just one
> person - it would be good to get more data from developers actually coding
> with ES modules.
>
> This syntax would make things completely obvious and simple though:  if
> there's curly braces, then you're reaching into the bag and pulling out
> things, and if there's no curly braces, you're getting the bag itself.
>  There's even a visual analogy at play here:  the curly braces themselves
> resemble the sides of a bag.
>
>
To me, though, that goes back to the destructuring/not destructuring
aspect. Maybe this has floated by during the bikeshedding, but why not
something like:

//import a single named export
import foo from "bar";

//import multiple named exports
import foo, baz from "bar";

//alias an imported named export
import foo as fooAlias from "bar";

//import the module
import "bar" as bar;

So basically, just get rid of the {} for importing named exports, and move
the whole module import after the as. It reads better to me and I think is
more intuitive. As for default exports - I think they only make sense if
done the way it works in node. A single default export that effectively
replaces the module. Let's remember how it gets used in node:

var _ = require("underscore");

In node, if they didn't do it as a single export, then you would have to do:

var _ = require("underscore")._;

Given that underscore (and jquery and several others) are only a single
export, it would be annoying and error prone to do that all over the place.
The value added was for the importer - *not the exporter*. With the new
syntax I'm proposing, importing underscore would be exactly the same as
what the current proposal is for default export imports.

import _ from "underscore";

Its just that underscore would have to have the named export _. As I said,
though, that's not really a burden, and the argument for default exports
was never really for the module writer.

There is one small case I'm missing, which is that default export imports
let you name the import whatever you want without writing extra code for
the alias. I don't really find that as a drawback, but then again, I do
write a lot of Java in addition to JavaScript. I don't really see any other
languages that operate this way either, and I would come back again to the
distinct history and constraints that JS/node has had up until now. If keep
that flexibility/matching semantics for smoothest continuity, I would
propose that default exports have to be a *single* default export, and that
it would replace module importing instead of export importing.

import "underscore" as _;

Where there is a single default export in the underscore module. This would
mean that the normal module import semantics don't work in this case, but
that is the tradeoff decided by the module author. I personally don't think
its worth adding this feature, but if it were added, I would expect it to
work this way.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Bytecode

[Russell Leggett]

>
>
> Regarding the original topic of this thread: I think there have been many
> many prior discussions of a standardised bytecode on es-discuss, and people
> should really be reading those before bringing this up again.  It’s not
> going to happen as no one has ever demonstrated an actual benefit over
> simply using JS.
>
>
I don't think anybody on this thread was trying to debate it. Axel was just
hoping to find some definitive explanations for those bringing up the
topic. It comes up a lot from various people on the internet, so its nice
to have something to point to for those people.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: module exports

[Russell Leggett]

>
>
>> I don't understand this claim, any legal AssignmentExpression form is
>> allowed.
>>
>>
>>> I've said this before, but without the equals it looks too much like a
>>> declaration:
>>>
>>> export default class C {}
>>> var c = new C(); // No C defined, WTF?
>>>
>>
>> Why is this surprising?
>>
>
> It is surprising because it looks like it should work like
>   export class C {}
> The keyword 'default' looks like a modifier like 'const'.
>

I completely agree with this. It looks like a modifier. In addition to not
having an = or some other reason to think it will be evaluated as an
expression, "default" *is* a reserved word *and* has special significance
here. Yes, it is grammatically unambiguous and can be learned, but this is
a question of intuition. The meaning here goes very strongly against my
intuition.


>
>
>
>>
>> If a developer knows how named function expression bindings work today,
>> this won't be a big surprise.
>>
>
> I know how named function expressions work and it's still surprising.
>

Same here.

If anything, I would say that it makes more sense to go ahead and run with
the intuition we seem to be feeling with is that it seems like a modifier
of the export. So maybe like:

export default class C {}
var c = new C(); //works

export default function f(){}
f(); //works

export default let obj = {a:1,b:2};
var a = obj.a; //works
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Protocol library as alternative to refinements (Russell Leggett)

[Russell Leggett]

On Wed, Oct 23, 2013 at 2:57 PM, Benjamin (Inglor) Gruenbaum <
ing...@gmail.com> wrote:

> Yes, this looks solid and definitely like something I'll use. I'll try to
> go through use cases and find problems during the weekend.
>
> What do you think would be the fastest way to get a prototype something
> working to play with?
>
>
Well the library itself could be implemented now, but without "::" you
wouldn't get the nice syntax. I've been looking into Traceur a bit to see
how hard it would be to add "::" - its some fairly simple syntax sugar.

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

Re: Protocol library as alternative to refinements (Russell Leggett)

[Russell Leggett]

On Tue, Oct 22, 2013 at 4:50 PM, Dean Landolt  wrote:

>
>
>
> On Tue, Oct 22, 2013 at 4:07 PM, Russell Leggett <
> russell.legg...@gmail.com> wrote:
>
>> On Tue, Oct 22, 2013 at 2:34 PM, Benjamin (Inglor) Gruenbaum <
>> ing...@gmail.com> wrote:
>>
>>> On Tue, Oct 22, 2013 at 8:10 PM, Russell Leggett <
>>> russell.legg...@gmail.com> wrote:
>>>
>>>> > Revised algorithm:
>>> > 1. If receiver has protocol method symbol as a property, use that as
>>> override.
>>> > 2. Try to use protocol methods - start by checking receiver type
>>> mapping, then check up type hierarchy for any matches, and finally if no
>>> matches, use the default if defined.
>>> > 3. Finally, if no matches and no default, check prototype for method
>>> of same name.
>>> > Does that sound better?
>>>
>>> Much :)
>>>
>>
>> Actually, let me revise 3:
>> 3. Finally, if no matches and no default, attempt to call a method of the
>> same name (not affected by variable name or aliasing) on the receiver.
>>
>> Something like this:
>>
>> const P = new Protocol("foo");
>>
>> // naive, non-native implementation of P.methods.foo would be
>> something like
>> function foo(...args){
>> if(P.symbols.foo in this){
>> //P.symbols holds a symbol for each method
>> return this[P.symbol.foo](...args);
>>
>> }else if(P.contains(Object.getPrototypeOf(this))){
>> //contains and lookup might be backed by a weakmap or
>> something,
>> //but it would also need to go up the type chain
>> let myFoo = P.lookup(Object.getPrototypeOf(this)).foo;
>> return this::myFoo(...args);
>>
>> }else if(P.getDefaults().hasOwnProperty("foo")){
>> let defaultFoo = P.getDefaults().foo;
>> return this::defaultFoo(...args);
>>
>> }else{
>> this.foo(...args);
>> }
>> }
>>
>> If this seems acceptable, I'll update the gist.
>>
>
>  This seems sensible, though it's a bit more flexibility than I'd prefer.
> What's not completely clear to me is whether this dispatching is defined by
> the protocol method implementation or whether it's something that's
> standardized? If the latter, I'd be concerned by all this flexibility. If
> it's the former (and you can just grab a dispatch implementation from some
> module) I guess it doesn't matter.
>
> So *if *the implementation controls the dispatching, the point I was
> trying to make about the "default" method not really being default is just
> that it could just as well be inlined. Sure, it'd be nicer if it was
> defined separately so they can be extracted and used independently, but
> assuming custom dispatch then defaults are really up to your dispatch
> algorithm, right? Do I have this about right?
>

I'm afraid that I'm a little lost by your confusion, so I'll just do the
best I can to answer your questions. First, the foo function I wrote out
was simply a bit of code to specify the algorithm I was thinking of in more
concrete terms. And again, its pretty naive - I was shooting for simpler
semantics rather than most efficient. So, to try and clarify a little
further:

const P = new Protocol("foo");

I picture the protocol constructor taking a variable number of string
arguments, or possibly an object similar to Object.create - I went with
strings for now because I couldn't think of what else you would need other
than names. The resulting object would be an instance of Protocol. For each
string argument you provided the constructor, the protocol would generate a
special protocol method, and also an associated symbol. When you are
calling the foo method in this case, it has to call an actual method first
(unless there's native support) and that method has to do the dispatch to
your supplied protocol method, the default method, or attempt to call the
method on the instance. I was expecting the protocol library to completely
handle this dispatch, so that foo function I created above would basically
be internal to the protocol, not something written by the user of the
library. Not sure if that clears anything up.

To answer your question more directly, the dispatching would be internal to
protocols. If protocols were done as a library, it would be dictated by the
library author, if it was native, then it would follow a spec and be
implemented by the browser.

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

Re: Protocol library as alternative to refinements (Russell Leggett)

[Russell Leggett]

On Tue, Oct 22, 2013 at 2:34 PM, Benjamin (Inglor) Gruenbaum <
ing...@gmail.com> wrote:

> On Tue, Oct 22, 2013 at 8:10 PM, Russell Leggett <
> russell.legg...@gmail.com> wrote:
>
>> > Revised algorithm:
> > 1. If receiver has protocol method symbol as a property, use that as
> override.
> > 2. Try to use protocol methods - start by checking receiver type
> mapping, then check up type hierarchy for any matches, and finally if no
> matches, use the default if defined.
> > 3. Finally, if no matches and no default, check prototype for method of
> same name.
> > Does that sound better?
>
> Much :)
>

Actually, let me revise 3:
3. Finally, if no matches and no default, attempt to call a method of the
same name (not affected by variable name or aliasing) on the receiver.

Something like this:

const P = new Protocol("foo");

// naive, non-native implementation of P.methods.foo would be something
like
function foo(...args){
if(P.symbols.foo in this){
//P.symbols holds a symbol for each method
return this[P.symbol.foo](...args);

}else if(P.contains(Object.getPrototypeOf(this))){
//contains and lookup might be backed by a weakmap or something,
//but it would also need to go up the type chain
let myFoo = P.lookup(Object.getPrototypeOf(this)).foo;
return this::myFoo(...args);

}else if(P.getDefaults().hasOwnProperty("foo")){
let defaultFoo = P.getDefaults().foo;
return this::defaultFoo(...args);

}else{
this.foo(...args);
}
}

If this seems acceptable, I'll update the gist.

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

Re: Protocol library as alternative to refinements (Russell Leggett)

[Russell Leggett]

On Tue, Oct 22, 2013 at 12:53 PM, Dean Landolt  wrote:

>
>
>
> On Tue, Oct 22, 2013 at 12:44 PM, Russell Leggett <
> russell.legg...@gmail.com> wrote:
>
>>
>> Say you have an object for which you want to implement the Cowboy and
>>> Canvas protocols (to borrow /be's favorite example). Both implement a
>>> "draw" method, but when you try to import from both protocols you'll
>>> naturally have to rename one or both. Now say you want to override Cowboy's
>>> `draw` method on an instance? You'll end up clobbering the Canvas
>>> protocol's draw method with the obviously wrong function. Not cool. This
>>> can be easily corrected with Symbols.
>>>
>>>
>>
>> Yes, I'm liking this idea. Protocol always first - override through a
>> symbol. Honestly, the more I think about it, the more I think overriding
>> won't happen much and therefore isn't a huge problem, making it more
>> specific through a symbol is not a bad idea.
>>
>> Last question - what about the priority of the defaults? Are they still
>> prioritized over prototype? I was worried at first about unintentional
>> clobbering the other way, but then realized that its easy to check for the
>> method in the default if you want to prioritize the prototype over the
>> default.
>>
>> Cowboy.defaults({
>> draw(){
>> if(typeof this.draw === "function"){
>> this.draw();
>> }else{
>> //something here
>> }
>> }
>> });
>>
>
>
> This is an interesting point -- the implementation could choose whether or
> not to dispatch to an instance, and how. At this point I wouldn't call them
> "defaults" since they'd always be run, and would be responsible for their
> own dispatching. I still think dispatching on strings would defeat one of
> the biggest advantages of protocols, but this approach is flexible enough
> to allow that. Also, it doesn't try to intercede between own and prototype
> lookup, which is much nicer.
>
>
The reason they are called defaults is because they are a fallback for when
the protocol isn't specified for a specific type. If I have two types A and
B. And I have a protocol P. P has a method "foo".

P.defaults({
foo:function(){
console.log("default foo");
}
});
P.extends(A,{
foo:function(){
console.log("A's foo");
}
})
let a = new A();
a::foo(); //outputs 'A's foo'
let b = new B(); //outputs 'default foo'

Basically, the default is useful for:

   - generic methods that only depend on other protocol methods
   - methods that want to do introspection on the object manually instead
   of dispatching on type
   - cases with a sensible backup

Just to be clear, default implementations are totally optional. A protocol
can have zero or more of them. I had originally been thinking that the
default should be last, allowing for a prototype to go first, but if the
default goes first, then it has the opportunity to defer to the prototype
*or* ignore the prototype.

Revised algorithm:

   1. If receiver has protocol method symbol as a property, use that as
   override.
   2. Try to use protocol methods - start by checking receiver type
   mapping, then check up type hierarchy for any matches, and finally if no
   matches, use the default if defined.
   3. Finally, if no matches and no default, check prototype for method of
   same name.


Does that sound better?

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

Re: Protocol library as alternative to refinements (Russell Leggett)

[Russell Leggett]

> Say you have an object for which you want to implement the Cowboy and
> Canvas protocols (to borrow /be's favorite example). Both implement a
> "draw" method, but when you try to import from both protocols you'll
> naturally have to rename one or both. Now say you want to override Cowboy's
> `draw` method on an instance? You'll end up clobbering the Canvas
> protocol's draw method with the obviously wrong function. Not cool. This
> can be easily corrected with Symbols.
>
>

Yes, I'm liking this idea. Protocol always first - override through a
symbol. Honestly, the more I think about it, the more I think overriding
won't happen much and therefore isn't a huge problem, making it more
specific through a symbol is not a bad idea.

Last question - what about the priority of the defaults? Are they still
prioritized over prototype? I was worried at first about unintentional
clobbering the other way, but then realized that its easy to check for the
method in the default if you want to prioritize the prototype over the
default.

Cowboy.defaults({
draw(){
if(typeof this.draw === "function"){
this.draw();
}else{
//something here
}
}
});

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

Re: Protocol library as alternative to refinements (Russell Leggett)

[Russell Leggett]

>
>
> > I can see most of your examples involve the interaction between the
> protocol method and a method supplied on the object itself... They
> definitely complicate things... I guess I would say that I would have this
> throw an error. ... Skipping foo on the object because its not a function
> seems too magical.
>
> Skipping `foo` on the object because it is not a function is too magical
> in my opinion too. Working out how instance methods work in this scenario
> seems like quite the task to me. The step of putting the protocol _between_
> the object and the prototype sounds pretty hard to get right in particular.
> I don't like thinking of reading from the prototype (as in the case of
> fetching a method) any differently from reading from the own object. After
> all sharing functionality is at the very core of prototypical inheritance.
>

Yeah, I'm not exactly married to it, but I liked the idea of being able to
override at the instance level, therefore giving own properties highest
priority.


>
>

> >>  Case 3:
> > Ah, yes, I had thought about this a bit, but it had never made it into
> my gist at all. Let me revise my algorithm:
> > 4. true - use Bar.foo
>
> This makes some sense. About scope resolution more generally I just want
> to make a note that in C# extension methods, the extension method is always
> the _last_ candidate. It would check anywhere in the inheritance chain
> _before_ attempting to evaluate the extension method. For example:
>
>```
> public class Bar
> {
> public int GetFive() { return 5;}
> }
> public class Foo : Bar{}
>
> public static class FooExt
> {
> static int GetFive(this Foo bar)
> {
> return ;
> }
> static string ToString(this Foo bar)
> {
> return "Hi";
> }
> }
>  static void Main(string[] args)
> {
> Console.WriteLine((new Foo()).GetFive()); // this prints 5
> Console.WriteLine(new Foo())); // Uses the implementation of
> Object.ToString .
> }
> ```
>
> This is a major difference between this proposal and C# extension methods.
> However, I'm not sure it's bad. Would you mind making an argumnt for
> prioritizing the protocol method over an object method?
>

Well I would start by pointing out that the two really are different
mechanisms with different strengths and weaknesses. Protocols are more than
a means of extension - they are also polymorphic and can really take
advantage of the equivalent of interfaces across data types in addition to
their extension. In a way, they are more similar to Haskell typeclasses
than extension methods. There is also the obvious difference that protocols
can be efficiently implemented in a dynamic language where extension
methods cannot :)

So anyway, the reason why prioritizing protocols is because there is
potential value in the protocol itself. The protocol *is* an interface - a
contract which can be polymorphic over different types. The same way that
two protocols can have methods with the same name but different semantics,
it would make sense that a protocol could be defined, and need to be
applied to a type that already has the method. There is value for the
protocol version to override the type's built in version. Because there is
no ambiguity in the intent of using the protocol instead of the prototype,
I think protocol should win. C# uses uniform syntax so the intent cannot be
known if the extension method was intended vs the type's method. Even
interfaces in the Java/C# worlds can't handle that type of clashing. If two
interfaces have methods with the same name and signature, you can only have
a single implementation. In those languages it is rarely a problem because
of the ability for overloading, but with JavaScript its just one name, one
method.

I'm not opposed to simplifying the algorithm, and perhaps protocol methods
should always take a backseat similar to C#, but that just doesn't seem
right to me. If I create a protocol with a map method and I define it for
Array, I would expect that to take priority, no? You're directly calling
arr::map not arr.map - maybe its a ParallelCollection protocol and you want
to override map to be parallel with web workers or something.

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

Re: Protocol library as alternative to refinements (Russell Leggett)

[Russell Leggett]

I'll preface this by saying that I haven't made a formal proposal and this
isn't an actual library. You're doing a good job of spotting some undefined
behavior which would probably be better defined by trying it out. I'll give
my opinions on them, but it could all use a good test drive before coming
down on these.

To help the discussion I'll paste the basic algorithm I outlined:

1. if the receiver has an own property of the same name, use that
2. if the receiver's type matches an extension of the protocol, use the
protocol method
3. if the receiver has a method of the same name somewhere up the prototype
chain, use that
4. use the default if available


> - Case 1:
>
> I have an object O of type Foo. A protocol P.
>
>  - O has the structure {x:5,foo:7};
>  - The protocol implements `foo` but does not specifically for Foo (via
> .defaults).
>
> What happens? Does `P.foo` get invoked, or do we get an error because
> `O.foo` is not a function?
>

I can see most of your examples involve the interaction between the
protocol method and a method supplied on the object itself. Clojure
protocols don't have this type of interaction. I tossed them in because
they seemed like they would work well with some of the examples brought up
in the other thread. They definitely complicate things... I guess I would
say that I would have this throw an error. Logically to me, either the an
error should be thrown because it would try to invoke foo on the object, or
we should give up on the idea of falling back on the object. Skipping foo
on the object because its not a function seems too magical.

So here, O has an own property, so #1 and blows up


>
>  Case 2:
>
> I have an object O of type Foo, Foo.prototype = new Bar. A protocol P.
>
>  - O has the structure {x:5,foo:7};
>  - The protocol implements `foo` for Bar specifically (but not for Foo)
>
> What happens?  (Similar to case above?)
>

Same as above - error (or drop the feature)


>
>  Case 3:
>
> I have an object O of type Foo, Foo.prototype = new Bar. A protocol P.
>
>  - O has the structure {x:5,y:7};
>  - Bar has a method foo
>  - The protocol implements `foo` for Bar specifically (but not for Foo)
>
> What happens? Does it invoke Bar.foo or P.foo?
>

Ah, yes, I had thought about this a bit, but it had never made it into my
gist at all. Let me revise my algorithm:
4. Check up type chain for match
5. If method defined on protocol default, use that
6. Otherwise error

1. false, continue
2. false, continue
3. false, continue
4. true - use Bar.foo


>
>  Case 4:
>
> I have an object O of type Foo, Foo.prototype = new Bar. A protocol P.
>
>  - O has the structure {x:5,y:7};
>  - Bar has a method foo
>  - The protocol implements `foo` for Bar specifically (but not for Foo)
>
> What happens? Does it invoke Bar.foo or P.foo ?
>

This looks the same as 3 to me, so Bar.foo


>
>  Case 5:
>
> I have an object O of type Foo, I import two `Protocol`s that implement a
> method `Foo` at the same specificity level - what happens?
>

This is an easy one and comes down to the benefits of making use of normal
variables and lexical scoping. Remember that protocols don't affect the
types at all, and the protocols exist completely independently of each
other. If you imported two protocols A and B that each have a method 'foo'
defined for type Foo, the only thing you would have to be careful of is
redefining your variables accidentally.

import {foo} from 'A';
import {foo} from 'B';

This is going to be a problem no matter what you're doing. You are
importing two things with the same name, trying to introduce to variables
with the same name. There's no magic for protocols here, you can just alias
your imports to avoid name clashes.

import {foo as fooA} from 'A';
import {foo as fooB} from 'B';

o::fooA();
o::fooB();

Alternatively, if the have the protocol itself, you can access the methods
directly and do:

o::A.methods.foo();
o::B.methods.foo();

Which isn't as nice, but is an option.

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

Re: Protocol library as alternative to refinements (Russell Leggett)

[Russell Leggett]

On Mon, Oct 21, 2013 at 3:17 PM, Benjamin (Inglor) Gruenbaum <
ing...@gmail.com> wrote:

> Russell Leggett  wrote:
> > https://gist.github.com/genericallyloud/7086380
>
> Very interesting.
>
> >  // 4. use the default if available
>
> what's "the default" in #4? The protocol's default? What's the behavior if
> no matching method is found?
>

The default is something I go into in a little bit of detail further down:

Collections.defaults({
each(iterator, context){
if (this.length === +this.length) {
  for (var i = 0, length = this.length; i < length; i++) {
//notice we also get to use :: for a simple call replacement
if (context::iterator(this[i], i, this) === breaker) return;
  }
} else {
  var keys = this.keys();
  for (var i = 0, length = keys.length; i < length; i++) {
if (context::iterator(this[keys[i]], this[i], this)
=== breaker) return;
  }
}
},

This is defining a sort of default implementation of the method for the
protocol, meaning that other types do not have to implement it in their own
type specific implementation of the protocol.


> Also, can anyone explain why this solves the performance problem scoped
> object extensions have? It still seems like it would have to check the
> environment for protocols and then check the methods on all available
> protocols and do type matching to the type of the method.
>
> `Collections.extend(Array)` seems awfully similar to an array extensions,
> how does the `::` operator resolve the need for expensive lookup, can you
> explain that to me?
>

Yes, the reason is because no new scopes or environments have been created.
The protocol and its methods are simply variables - objects like anything
else. Getting a protocol's method is not really any different from:

import {map} from 'UnderscOOre';
//basically the same as
let {map} = Array.prototype;

//this is effectively the same whether you got it from the protocol or
the function
//pulled off of Array.prototype
arr::map( x => x+2);

The magic is what happens one of these protocol methods. The simplest to
understand/naive approach to this would basically be that inside of a
protocol, for each protocol method, you hold all the methods in a map going
from type to implementation. The actual method used would inspect the
|this| and follow the algorithm and use the maps to figure out which
implementation to use. This would have a penalty - but it would be limited
to the protocol method calls. Scoped extension would apply a penalty to
*all* function calls everywhere. If protocols were natively supported, or
at least some kind of hook for single dispatch on type, I'm pretty sure you
could get function calls that were *at least* as fast as normal prototype
based methods. Even if you didn't get native support, I have a feeling that
something more clever than the naive approach could be used to hit the
sweet spot and get some polymorphic inline caching, but maybe not.

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

Protocol library as alternative to refinements

[Russell Leggett]

This thread is based on conversations in the "Scoped binding of a method to
an object" discussion. I suggested using the proposed bind operator "::" as
an alternative, and hinted at way of doing so polymorphically. Given that
the other discussion on refinements just popped up, I figured I might as
well toss of the gist I had been working on.

https://gist.github.com/genericallyloud/7086380

I wouldn't necessarily call this a proposal, although I think something
like it *could* be a great addition to the language. Given that it could be
polyfilled, I'm guessing that it may do better as a library first to get
the kinks out, but who knows - if there is enough positive response, maybe
something will come of it - at least some hooks to make single dispatch on
type more efficient, perhaps? Anyway, enjoy!

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

Re: Scoped binding of a method to an object

[Russell Leggett]

On Tue, Oct 15, 2013 at 4:28 PM, Benjamin (Inglor) Gruenbaum <
ing...@gmail.com> wrote:

> Wait, I think maybe I did not understand what you meant before.
>
> Are we talking about using `::` for infixing the first parameter of the
> function? As in `func(a,b,c)` being the same as `a::func(b,c)` ?
>

Not exactly. See the proposal
http://wiki.ecmascript.org/doku.php?id=strawman:bind_operator
"Essentially, e1::e2 is equivalent to do { let obj=e1; e2.bind(obj) }"

Or, in the case of an immediate call, it skips the bind and just does a
Function.prototype.call. In other words,

obj::fun(a,b) is not the same as fun(obj,a,b). Its fun.call(obj,a,b).

The important distinction is that the function being called is expecting a
|this| as opposed to an extra first argument. This is reason I called it
"underscore2" - Brendan picked up on that calling it OO underscore.
Functional purists can argue with the approach, but it would let you write
functions exactly as though they were extension methods - using |this|
where appropriate.

The following is a somewhat silly example based on the SOE proposal

module Collections {
  export {
where: Array.prototype.filter,
select: Array.prototype.map
  }
}

module LolCatzDotCom {
  // imports Array.prototype extensions where and select into this
module
  import {where,select} from Collections;

  var allCatz = someArrayValue;
  // Array extensions are in scope
  var cuteCatNames = allCatz::where(cat => cat.isCute)::select(cat =>
cat.name);
}

If you still don't get it, give me an example, and I can probably show the
:: equivalent. What is your ideal SOE form? Because my guess is that I can
get it darn close with ::

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

Re: Scoped binding of a method to an object

[Russell Leggett]

> Using your proposed "underscore2" (OO-underscore?) with :: is no more
> verbose than underscore.js (underscore1), and it has the chaining not
> inside-out-composing win some may prefer.
>

I'm glad you noticed the 2. Perhaps oonderscore? :)


>
> We should not argue only about taste, and bind (::) has a champion and
> good rationale as an addition to the language.
>
> What I think we should argue about is whether SOE that solves either or
> both problems (P1 and P2) I identified is even possible. Andreas's
> static-only resolution requirement is good. Anyone want to work on that
> angle?


If we do assume static-only resolution, isn't that trivial to show its
impossible? Wouldn't it require complete type inference? And even then,
what about expressions that evaluate to more than one type?

Btw, another thing I noticed, thinking about using the binding operator
this way, is that it's also a perfect fit for array-likes and array methods.

import {hide} from "jQuoory";
let {filter, forEach} = Array.prototype;
document.getElementsByClassName('hello')
::filter(e => e.tagName === "span")
::forEach(e => e::hide());

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

Re: Scoped binding of a method to an object

[Russell Leggett]

>
>
>> The big issue I see here is chaining.
>>  `_.reduce(_.map(_.filter([1,2,3,4,5],x=>x%2 === 0),x=>2*x),(x,y)=>x+y)`
>> Is a lot less readable than
>>  `[1,2,3,4,5].filter(x=>x%2===0).map(x=>2*x).reduce((x,y)=>x+y))`
>>
>
>
P.S. This really doesn't look too shabby to me:

import {reduce,map,filter} from "underscore2";
[1,2,3,4,5]::filter(x=>x%2===0)::map(x=>2*x)::reduce((x,y)=>x+y))
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Scoped binding of a method to an object

[Russell Leggett]

>
>
> > If we didn't have :: (which we don't now), I think people will continue
> to simply use functions like what underscore does. Personally, I'm ok with
> that
>
> I think using stuff like _.shuffle([1,2,3,4,5]) is not as nice and worse
> than [1,2,3,4,5].shuffle() . Especially in a more functional interface that
> does not return the original array (we can even have a generator here).
>

I prefer it too, which is why I suggested :: - its not as nice in terms of
needing to understand a new operator, but it does allow you to think about
it in a more OO way, and it allows for forward chaining without wrappers.


>
>
> Let's say I have an array [1,2,3,4,5], I want to filter the odd ones,
> double the remaining elements and then sum the result. (This is obviously
> not a real use case, but I think we both know there are such use cases)
>
> The big issue I see here is chaining.
>  `_.reduce(_.map(_.filter([1,2,3,4,5],x=>x%2 === 0),x=>2*x),(x,y)=>x+y)`
> Is a lot less readable than
>  `[1,2,3,4,5].filter(x=>x%2===0).map(x=>2*x).reduce((x,y)=>x+y))`
>

Speaking of wrappers - underscore does have the chain method which wraps
and allows for chaining. Not ideal, but better, and people are comfortable
with it - I mean look at jQuery.


> Having another invocation syntax like `::` sounds like a __huge__ overhead
> to me.
>
> Its not an invocation syntax, its fairly trivial binding sugar which can
be used to apply functions to objects as the receiver without modifying the
object, which is precisely what you want to be able to do with SOE even if
you don't like the syntax.

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

Re: Scoped binding of a method to an object

[Russell Leggett]

On Tue, Oct 15, 2013 at 11:59 AM, Allen Wirfs-Brock
wrote:

>
> On Oct 15, 2013, at 7:22 AM, Russell Leggett wrote:
>
> >
> > If we didn't have :: (which we don't now), I think people will continue
> to simply use functions like what underscore does. Personally, I'm ok with
> that. If I want to have unscoped extensions and live with the consequences
> - I will be happy to use symbols. If I want to make a polyfill, I'll just
> do it the same way we've been doing it. But, as much as Allen seems to
> accuse me of being an FP guy, I still want to have a thing which feels like
> a method to be on the right so I find that using :: (if it existed) would
> be a nice compromise.
>
> Hey, it was a general rant and not specifically directed at you or anybody
> else.
>
>
Sure, no offense taken, I just don't put myself in that camp. Even the use
of |this| I think is justified as not an FP abuse, I just haven't gotten a
chance to flesh out my reasoning yet. Without elaborating too much, (sorry,
no time right now), I basically envision the blend of clojure protocols and
javascript as basically external mixins. Not just a single function, but
potentially a set, and using the |this| for single dispatch the way clojure
protocols use the first arg.

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

Re: Scoped binding of a method to an object

[Russell Leggett]

On Tue, Oct 15, 2013 at 3:45 AM, Benjamin (Inglor) Gruenbaum <
ing...@gmail.com> wrote:

> Brendan Eich  wrote:
> > We already have good motivation for :: anyway, as sugar for bind. This
> gives relief to the OO side of the expression problem trade-off by allowing
> lexical bindings to be composed with method calls -- beautiful. No third
> scope axis / lookup parameter!
>
> Yeah, but this doesn't solve the original problem nearly as well IMO since
> it's suddenly different from a normal method call. Having a different call
> operator for scoped extension methods or method invocation seems very
> confusing and counter intuitive for developers.
>
> If I have to remember different invocation mechanics I kind of lost
> already and I don't have the polymorphism I wanted. I completely agree with
> Allen here.
>

I don't think that the scoped extensions you want are going to happen. I
used to like the idea of something like that, but I think it will cause a
lot more confusion than its worth. My suggestion for the :: binding
operator was basically just trying to leverage an operator that might be
coming anyway and giving it more purpose. I mean, heck, you know JavaScript
programmers, if :: got added to the language, you *know* people will use it
to make nicer looking (subjectively) APIs in the way I'm describing.

In regards to polymorphism - its not a polymorphic solution out of the box,
or at least - it doesn't provide any affordances for doing polymorphism,
but saying that function calls cannot be polymorphic isn't true, we're
simply flipping around where the polymorphism happens. Yes, I know this
probably sounds like a FP rant, but I think that you can't ignore the FP
side of this (invoking the expression problem again here). OO is good at
adding new cases to the datatype. Functional is good at adding new
functions over the datatype (which is what we're doing here). Trying to get
the best of both worlds likely means playing in the middle. I mean, this
feels like a "you got chocolate in my peanut butter" "you got peanut butter
in may chocolate" moment. You say, "This operator makes my method calls
unintuitive because its not a dot. Method calls should consistently use
dots." I say, "Variables (including function variables) already have well
understood scoping and lookup behavior. The dot operator should have
consistent lookup behavior." Is there a way to marry the functional and OO
to solve this problem?

If we didn't have :: (which we don't now), I think people will continue to
simply use functions like what underscore does. Personally, I'm ok with
that. If I want to have unscoped extensions and live with the consequences
- I will be happy to use symbols. If I want to make a polyfill, I'll just
do it the same way we've been doing it. But, as much as Allen seems to
accuse me of being an FP guy, I still want to have a thing which feels like
a method to be on the right so I find that using :: (if it existed) would
be a nice compromise.

Maybe I'll think about what clojure style protocols would look like to
answer some of the polymorphism questions.

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

Re: Generic Bundling

[Russell Leggett]

On Mon, Oct 14, 2013 at 5:35 PM, Jorge Chamorro wrote:

> On 14/10/2013, at 23:32, Russell Leggett wrote:
>
> > This is probably the wrong place to ask the question, but I was just
> thinking about the whole HTTP 2 server push thing. In a way, it surely wins
> in the # of requests camp if it works as described - you request index.html
> and the server intelligently starts pushing you not only index.html, but
> also everything index.html needs. Even in the case of bundling, you at
> least need to wait for index.html to come back before you can ask for the
> bundle. And even better, because it sends everything in original granular
> form, surely the caching story must be better, you won't wind up
> overbundling or having overlapping bundles. Then I realized a major
> (potential) flaw. If the server always pushes the dependencies for
> index.html without being asked - doesn't that completely wreck the browser
> cache? Browser caching relies on knowing when - and when *not* to ask. If
> server push starts sending things without being asked, isn't that
> potentially sending down a lot of unnecessary data?
>
> I think I've read somewhere that it sends the resources in separate
> 'streams' that can be cancelled if not needed.
>
>
Ah, ok, that makes sense. I would hate to think anyone would have
overlooked that aspect.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generic Bundling

[Russell Leggett]

This is probably the wrong place to ask the question, but I was just
thinking about the whole HTTP 2 server push thing. In a way, it surely wins
in the # of requests camp if it works as described - you request index.html
and the server intelligently starts pushing you not only index.html, but
also everything index.html needs. Even in the case of bundling, you at
least need to wait for index.html to come back before you can ask for the
bundle. And even better, because it sends everything in original granular
form, surely the caching story must be better, you won't wind up
overbundling or having overlapping bundles. Then I realized a major
(potential) flaw. If the server always pushes the dependencies for
index.html without being asked - doesn't that completely wreck the browser
cache? Browser caching relies on knowing when - and when *not* to ask. If
server push starts sending things without being asked, isn't that
potentially sending down a lot of unnecessary data?

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

Re: Scoped binding of a method to an object

[Russell Leggett]

On Mon, Oct 14, 2013 at 4:05 PM, Brendan Eich  wrote:

> Russell Leggett <mailto:russell.leggett@gmail.**com
>> >
>> October 14, 2013 12:51 PM
>>
>> I get that this isn't really the same, but I think one really viable
>> solution for the scoped method problem (which is really just the expression
>> problem, right?)
>>
>
> The expression problem 
> (http://en.wikipedia.org/wiki/**Expression_problem<http://en.wikipedia.org/wiki/Expression_problem>)
> is about the cross-cutting nature of extension, and how FP and OOP seem to
> trade off against one another.
>
> So "scoped object extensions" is not "just the expression problem", but I
> think it is related as follows:
>

Sorry, I was a bit glib - what I meant was that the ability to add new
methods to existing types without modification of the original type and
without recompilation is the OO side of it, and that's really what we're
talking about here. I brushed with broad strokes, but you clearly see what
I mean in your examples. I guess I was trying to invoke all the ideas that
have come before in the name of fixing the expression problem and how they
would relate to this. I don't actually think SOE is a good fit for
p(r)olyfills, which is a different case than what I would really call the
expression problem.


>
> If we used only functions (possibly with richer dispatch mechanisms, e.g.
> multimethods), then lexical scope might be enough to extend without
> collisions. One just rebinds/renames/shadows to compose functions. Or so I
> think -- CS gurus should school us here.
>
> However, JS has an OO flavor, especially in its built-ins (including the
> DOM). So users want extensions on the right of dot (and after colon in
> object literals).
>

This is the real trick to why I proposed using the bind operator. The
extension methods would take advantage of dynamically bound "this". The
methods themselves would be lexically bound - they would simply be
variables - however they got there (import, let, destructuring) but the
syntactic sugar of :: would allow binding and then calling with a syntax
that looks very similar to .

To be clear, underscore methods as written would not work correctly here.
Those expect the collection as the first argument. What I was proposing to
do with the bind operator would still use "this" to point to the collection
(or whatever the intended target), and thus keep the OO feel, it just
wouldn't use the dot operator, and wouldn't actually modify the prototype
or mess with the lookup chain.


>
>  is the proposed bind operator http://wiki.ecmascript.org/**
>> doku.php?id=strawman:bind_**operator<http://wiki.ecmascript.org/doku.php?id=strawman:bind_operator>
>>
>> It doesn't use dots, so it won't mask the difference between the normal
>> prototype chain with some additional scoped binding (for good or ill), but
>> along with it comes the clarity and comfort of lexical binding and also the
>> potential use of the module system.
>>
>> import {shuffle,each,filter} from "underscore2";
>> myArray::shuffle();
>>
>
> Not bad, and exactly the kind of design I pointed to in the last post or
> three: new special forms to confine the complexity that killed the SOE
> strawman.
>
>>
>> And if that isn't enough because you need more polymorphic behavior, I
>> think something like Clojure's protocols <http://clojure.org/protocols>
>> could be implemented as a library to be used in conjunction.
>>
>
> Clojure wants multimethods too. Some excitement based on my proposal for
> value object operators.
>
>
Yes, although protocols are able to stick with simple single-dispatch based
on the datatype extending the protocol. I think this could potentially work
with the trademarks
proposal<http://wiki.ecmascript.org/doku.php?id=strawman:trademarks>
if
that ever happened. But I guess that's probably a different thread.

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

Re: Scoped binding of a method to an object

[Russell Leggett]

I get that this isn't really the same, but I think one really viable
solution for the scoped method problem (which is really just the expression
problem, right?) is the proposed bind operator
http://wiki.ecmascript.org/doku.php?id=strawman:bind_operator

It doesn't use dots, so it won't mask the difference between the normal
prototype chain with some additional scoped binding (for good or ill), but
along with it comes the clarity and comfort of lexical binding and also the
potential use of the module system.

import {shuffle,each,filter} from "underscore2";

myArray::shuffle();

And if that isn't enough because you need more polymorphic behavior, I
think something like Clojure's protocols
could be implemented as a library to be
used in conjunction.

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

Re: Generic Bundling

[Russell Leggett]

On Fri, Oct 11, 2013 at 10:19 AM, Jeremy Darling
wrote:

> Oh, and server side support for asset bundling could be eased if your in
> any language with an HTML pre-processor readily available.  Simply scan all
> your script and link tags, add a ref tag to each, and spit out a zip in the
> appropriate location.  Course it could also be part of your build tools if
> your using them.
>
>
> On Fri, Oct 11, 2013 at 9:17 AM, Jeremy Darling 
> wrote:
>
>> The way I read the proposal (and I could be wrong here), you would have
>> copies on your server in the appropriate locations.  So I may have a /js/
>> folder with all my core JS inside it, and a /vendor/*/ with each vendor
>> package inside of it.  I could have multiple asset package's (one for my
>> core, one for each vendor code, or maybe one for all vendor code), or I
>> could simply have a single asset package referenced.  If the browser knows
>> what to do with it all it will pull down the package files, extract it/them
>> and use the code from the package.  If not it would call back to the server
>> for each file that it needed on the page.
>>
>> Basically, here is my understanding in pseudo code (there may be typos
>> below);
>>
>> 
>>   
>> > ref="/pkg/jquery.zip">
>> > href="/vendor/skeleton/css/base.css" ref="/pkg/skeleton.zip" />
>> > href="/vendor/skeleton/css/skeleton.css" ref="/pkg/skeleton.zip" />
>> > href="/vendor/skeleton/css/layout.css" ref="/pkg/skeleton.zip" />
>>   
>>   
>> > ref="/pkg/app.zip">
>> > ref="/pkg/app.zip">
>> > ref="/pkg/app.zip">
>>   
>> 
>>
>> My thoughts, after reading, are that there would be three requests or
>> pushes back for /pkg/jquery.zip, /pgk/skeleton.zip, and /pkg/app.zip when
>> the browser supported packaging.  If the browser didn't then you would see
>> 7 requests to get the assets.
>>
>> Course, I could be wrong :)
>>
>>
Ah, ok, a little different than the way I read it, but I think you're
right. I've got to be honest. I wouldn't use this. The fallback case on a
large app would be such a tremendous http request fail (assuming HTTP 2.0
not in place). For it to be something I would really want to use, I guess I
would probably want to load two different sets of files - one for browsers
with module/bundling support and one for everyone else (fallback). The
fallback would have to be ES5 compatible code and would probably use
concatenation or an ES5 compatible loader.

So I guess, thinking about it, I think the major flaw with HTTP 2.0 server
push for me is not the technology itself, but how hard it would be to use
it with an *acceptable* fallback. Right now the code I write has a ton of
smaller files that uses a smart build to make a dependency graph and
smartly concat into optimal chunks, an ideal case for ES6 modules as its
already basically divided that way and already has fake import statements.
I could change the build so that it used server push instead, but the
fallback case would go horribly awry. I don't know, I guess I'll just have
to think about a way to make that work. There's probably a relatively easy
strategy.

Out of curiosity - does anyone have a good solution in regards to fallbacks
for modules? Using traceur and serving ES5/ES6 versions is what immediately
comes to mind.

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

Re: Generic Bundling

[Russell Leggett]

On Fri, Oct 11, 2013 at 9:57 AM, Jeremy Darling wrote:

> HTTP 2.0 will require changes to servers for it to work properly, it will
> also require that developers learn a bit more about the pipeline or rely on
> some vendor to implement the "smarts" for them.
>
> Asset Bundling on the other hand will provide a quick and easy transition
> for most development communities.  Compress everything, update your ref's
> and wait for the browsers to catch up, or for your server dev team to work
> out push.
>
> You could still push your asset bundle with HTTP 2.0 and achieve basically
> the same results as if you bundled all the assets and sent them down the
> pipe with HTTP 2.0.
>
> I don't see them as foe's or alternatives to one another.  Quite to the
> opposite, they seem to compliment each other quite well.
>
>
Well, just so I understand - let's say you have 100 JavaScript files you
want in your bundle. Can you explain to me the strategy for handling the
fallback unsupported case? Does the bundle contain module based code
assuming es6 and the fallback is all es5 code using traceur or something?
Just trying to get a vision for this.

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

Re: Generic Bundling

[Russell Leggett]

> > As you can see the resource packages attempt got dropped. Perhaps this
> proposal will go through because it is tied to the module loader?
>
> It's sad. What happened? Why was it ditched? Was it, perhaps, too ahead of
> its time?
>
> Let's try again :-)
>

As you can see, it basically fell to the same conclusion as you are trying
to fight right now - SPDY and html pipelining. The idea that this can be
transparently handled better with http rather than a bundling approach.

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

Re: Generic Bundling

[Russell Leggett]

>  Not sure if this changes anything, carry on.
>
> Server push is happening as part of HTTP 2.0. Do you have a use case in
> which it's insufficient?
>
>
Not sure if this was directed at me or Jorge, but in case it was directed
at me, I wasn't actually advocating for this anymore, simply acting as a
historian. I have a solution that works fine for me right now, and I'm
content to wait HTTP 2.0 or whatever the next step is.

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

Re: Generic Bundling

[Russell Leggett]

Just wanted to point out a couple of previous attempts at something similar
to generic bundling and the reactions it got, because so far it hasn't
panned out.

Way back in 2008, it was my one and only real contribution to the whatwg
list before getting a little frustrated and moving on:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-July/015411.html

Then a year later, Alex Limi independently came up with a very similar
proposal: http://limi.net/articles/resource-packages/
and actually got a version of it working in some branch of firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=529208
And here's a couple of discussions on that proposal:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/MXeSYsawUgU
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027582.html

As you can see the resource packages attempt got dropped. Perhaps this
proposal will go through because it is tied to the module loader?

Not sure if this changes anything, carry on.

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

Re: The Paradox of Partial Parametricity

[Russell Leggett]

>
> I'm not arguing 'chain' be removed. I'm convinced at this point its worth
>> including, I'm just debating the method name here. Sorry if it's just
>> bikeshedding at this point, but on the face of it, the two methods seem
>> hard to distinguish, and while 'chain' might be a better name for some
>> hypothetical monadic style, why not leave it up to some library to give the
>> method a facelift. The same way that the promise API is being kept light,
>> and will likely still be wrapped by things like the Q library for
>> additional functionality, I expect some monadic focused library will be
>> used if using promises in the monadic style. Worst case scenario, you just
>> add an alias on the Promise prototype.
>>
>
>
> I agree with Russell that `chain` is a little ambiguous when juxtaposed
> with `then. Around the time this conversation first kicked up I'd proposed
> this API and referred to what Tab calls `chain` as the "one-step resolver
> function". I still think `resolve` would be a pretty good, reasonably
> self-documenting name -- especially compared to `chain`. You can describe
> `then` as a recursive `resolve` and the difference should be obvious.
>

Yes, I had suggested the name "resolveOnce" as I think it really helps
describe what it does in relation to 'then'. As someone learning for the
first time, I would likely read that and think, "Only once. That means
something else resolves more than once." Reading the docs for 'then' and
seeing the examples, would make it pretty clear to me that 'then' *just
works* while resolveOnce is more of a low level method.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The Paradox of Partial Parametricity

[Russell Leggett]

On Tue, May 28, 2013 at 9:55 AM, Tab Atkins Jr. wrote:

> On Mon, May 27, 2013 at 9:53 AM, Russell Leggett
>  wrote:
> > On Mon, May 27, 2013 at 11:04 AM, Tab Atkins Jr. 
> > wrote:
> >> On Mon, May 27, 2013 at 7:29 AM, Russell Leggett
> >>  wrote:
> >> > I'm just going to go ahead and play stupid here. Why is it called
> chain?
> >> > I
> >> > agree one more method doesn't break anyone's brain, but I think the
> >> > confusion comes when it is not clear what a method is for and when
> they
> >> > should use it. Can anyone just try to write a really quick API doc for
> >> > chain
> >> > so that someone without knowledge of monads could read it? It should
> >> > hopefully be fairly obvious after reading the doc why the method is
> >> > called
> >> > chain.
> >>
> >> Yeah, it's pretty easy - the chain() method lets you "chain" one
> >> promise into another - you start with a promise, take a function that
> >> returns a promise, and return a promise from that.
> >>
> >> (Naming abstract operations is hard, but I think chain() is better
> >> than bind().  This is probably why Haskell spells it ">>=". ^_^)
> >
> > Technically speaking, though, doesn't "then" also meet that definition
> (plus
> > additional functionality)? I agree that naming abstract operations is
> hard,
> > but this just screams to me of a method that would get improperly
> > used/confused by developers. It would work like then in some cases, but
> > break unexpectedly, etc. Brendan says no name mangling, and sure it
> probably
> > shouldn't be too bad, but I think it should be on the burden of chain to
> > distinguish itself from then, and not the other way around. ES is already
> > filled with names like getOwnPropertyDescriptor. For the amount of use it
> > will get, I'm not sure it's worth a shorter, more cryptic name.
>
> "then" works equally well for promises, but I don't think it works for
> arbitrary containers - I think I'd understand "array.chain(cb)" better
> than "array.then(cb)".
>

I wan't suggesting using then for other containers or replacing chain with
then, I was suggesting that the definition for chain on promises is a
little ambiguous with the existence of 'then'. 'chain' chains promises
together. "then" also chains promises together, but with some extra stuff.
It puts developers in the position of wondering, "so when should I use
'then'? Why should I use it instead of 'chain'?" Given that 'then' is what
they'll likely want in 99.9% (sorry for my made up statistic) of
situations, I think that in the case of promises, it should be on the
burden of the 'chain' method to distinguish itself from 'then'–to define
itself in relation to 'then'. I think its rather similar to the discussion
on arrow functions. => is what someone wants so much more often that -> was
left out. It was still possible, after all, its just normal functions, but
it was decided that to aid comprehension, we would encourage the happy path.

I'm not arguing 'chain' be removed. I'm convinced at this point its worth
including, I'm just debating the method name here. Sorry if it's just
bikeshedding at this point, but on the face of it, the two methods seem
hard to distinguish, and while 'chain' might be a better name for some
hypothetical monadic style, why not leave it up to some library to give the
method a facelift. The same way that the promise API is being kept light,
and will likely still be wrapped by things like the Q library for
additional functionality, I expect some monadic focused library will be
used if using promises in the monadic style. Worst case scenario, you just
add an alias on the Promise prototype.

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

Re: The Paradox of Partial Parametricity

[Russell Leggett]

On Sun, May 26, 2013 at 1:38 PM, Brendan Eich  wrote:

> Russell Leggett wrote:
>
>> I'm sorry if I have just missed it trying to keep up to date, but what
>> are the compelling use cases.
>>
>
> AsyncTable with promises as values.
>
> No name mangling. I prefer then and chain. One more method doesn't break
> anyone's brain, in view of the acknowledged {value: x}
> manual-wrapping/unwrapping alternative.


I'm just going to go ahead and play stupid here. Why is it called chain? I
agree one more method doesn't break anyone's brain, but I think the
confusion comes when it is not clear what a method is for and when they
should use it. Can anyone just try to write a really quick API doc for
chain so that someone without knowledge of monads could read it? It should
hopefully be fairly obvious after reading the doc why the method is called
chain.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The Paradox of Partial Parametricity

[Russell Leggett]

On Sat, May 25, 2013 at 6:00 PM, Brendan Eich  wrote:

> Tab Atkins Jr. wrote:
>
>> AP2 from Mark's slides:
>>> >
>>> >  AP2 (Based on Tab’s latest)
>>> >  • Q.fulfill // lifting
>>> >  • Q() // autolifting, resolve
>>> >  • p.then // deep flattening
>>> >  • p.flatMap // “chain”
>>>
>>
>> Apologies for being a broken record, but just to make sure the detail
>> isn't lost in the noise...
>>
>> AP2 is*almost*  right.  If .then() only flattens on the read side,
>> it's perfect.
>>
>
> With you all the way on this one.
>
> Who proposes flattening the return value ("write side", right)?



Just one more from the peanut gallery. I'm a big fan of the Q library. I
use it in production code. I like the auto-unwrapping and feel like it
works in a way that I expect. I like E and greatly respect Mark's work and
opinion as well. I can't really think of any situations where I would need
nested promises. Still, in this debate I find myself coming around to Tab's
proposal, including his details about flattening on the read side. I
strongly come down on the path of using thens and recursive unwrapping as
the happy path that everyone should really use unless they know what
they're doing. Still, the additional method does not come at a high cost in
my opinion. If there is going to be a standard "hacky workaround", then the
additional method seems pretty straightforward and elegant.

On the other hand, if *nobody* is going to actually need the method, then I
guess it may very well be dead weight. I'm sorry if I have just missed it
trying to keep up to date, but what are the compelling use cases. I mostly
understand the monad thing, I can recognize them when I see them - I've
used haskell. Is the only reason so that a monadic style can be used, with
promises included? Perhaps that's enough, but I guess I'd really like to
hear something more direct. Also, I'd like to know how many people are
really using monadic JavaScript in production or if its mostly just a
hypothetical scenario.

Finally, if we wish to add the method and we worry about the burden on
developers who have no interest in monads, perhaps a method name that
really comes from *their* perspective, or one that feels more *experts
only* would seem less burdening. Something like "resolveOnce" or
"forceInvokeNext" or "resolveNonGreedy" or even "monadicThen". Some of
those are probably more acceptable than others, but I think that "chain"
will too likely seem useful to people who won't want to use it. JavaScript
developers, I think have expectations about what chain means. For most
people, they with just think of wrapping something for method chaining.

- Russ


>
>
> /be
>
> __**_
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6,ES7,ES8 and beyond. A Proposed Roadmap.

[Russell Leggett]

> Persistent immutable data structures would be a big usability improvement
> in their own right. In a world where it's just as cheap and convenient to
> use immutable structures as it is to depend on side-effects, code that does
> this (including your own) would be a whole lot easier to reason about and
> would have objectively better security properties. I'd think this alone
> would justify their consideration -- but as Mark suggested, they could also
> have real performance advantages given RiverTrail or workers.
>
> But I'll double down on that and suggest there are perf wins to be had for
> regulation js code w/o any concurrency or parallelism primitives. For
> instance, a persistent immutable array primitive backed by something like a
> fingertree would have some really interesting characteristics compared to a
> standard js array -- efficient splicing, binary search, deque operations,
> constant-time reverse, to name a few. And I won't even start on the
> amazingly cool things that could be done if you could provide group
> calculations for caching in the branches of your tree (except to say that
> js devs should be shouting about monoids, not monads!). And of course this
> kind of group-theoretical approach could extend naturally to RiverTrail
> code as well...
>
> I bring this up because I think these kinds of optimizations and
> performance-specific features would be interesting and useful to explore,
> but having said all that, I believe the utility of persistent data
> structures stands on it's own, regardless of possible perf wins (parallel,
> concurrent or otherwise). I would love to see this discussed along with
> value types for es7.
>

+1000 I would love to see persistent immutable data structures part of ES7.
I think they would be a fantastic fit for both concurrent and
non-concurrent js code.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A case for removing the seal/freeze/isSealed/isFrozen traps

[Russell Leggett]

On Fri, Feb 15, 2013 at 9:24 AM, Erik Arvidsson wrote:

> ... and security sensitive code could just ban/alter the reflection
> methods.
> On Feb 15, 2013 8:29 AM, "Brandon Benvie"  wrote:
>
>> I definitely agree that something like "preventAccidentalExtensions"
>> (disallows new properties through [[Put]] but not [[DefineOwnProperty]])
>> has more common uses cases than preventExtensions, and for the precise
>> reasons that David said. The security is against bugs usually, not
>> attackers. PreventExtensions is a clumsy tool for managing capabilities
>> because it leaves no room for giving *some* code permission while
>> preventing other code, which is exactly what we want when the clueful *me*
>> of now is writing code to manage the clueless *I* of the future.
>>
>
I think this would fit a really common use case, but I would say that the
current attempted way to solve this problem is private names. Last I
checked, private names (or the weak map variant) would not be frozen after
an Object.freeze, but only trusted parties (like methods,getters/setters,
and potentially those with the shared name) could modify it.

The pattern I would like to see optimized for using Object.freeze is the
functional approach. I think the tools are there. Object.freeze makes
immutable objects, and using Object.create to use frozen objects as
prototypes, and store just the differences in the child object could
potentially be an elegant way of doing persistent data structures. I
haven't really tested the performance of it now, but I wonder how optimized
it could get. The prototype chains could get very deep, but seeing as they
would all be frozen all the way up, I wonder if it could be made more
efficient.

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

Re: Minimal Module System Proposal

[Russell Leggett]

On Thu, Feb 7, 2013 at 9:25 PM, Kevin Smith  wrote:

>
> Thanks, but let's not jump to any conclusions. I'm the champion of modules
>> and wasn't even able to be a part of the discussion for family reasons. We
>> can't make any judgment about the status of modules, or plans for reacting
>> to the status of modules, before I've had a chance to be a part of the
>> conversation.
>>
>>
>  +1 and congrats (I'm slinging a babe right now ; )
>
> I'm confident that modules will make it - in my mind ES6 will fail if not.
>  They are certainly more important than proxies and private names, and the
> sooner we coalesce around the syntax, the better everyone will feel.  IMO,
> your previous proposal was almost right on.  e.g.
>
> http://wiki.ecmascript.org/doku.php?id=harmony:modules&rev=1332511079
> https://gist.github.com/khs4473/4382710
>
> I think we need to have a knock-down-drag-out discussion about URL and
> loader semantics.  ; )
>

In the home brewed module system that I've been using for the past 4 years
or so, I started by basically stealing from Java - in a comment at the top
of a file I do sort of java style imports:


/*
 * #import com.foo.bar.SomeClass
 */

It had the usual sort of Java style semantics (we're a Java shop, so this
works for us). Along the way, I added support for importing java classes -
this would basically do some java -> javascript model building magic and
exposing services, etc. The notation for it looks mostly the same except
for:

/*
 * #import remote com.foo.bar.JavaClass
 */

The sort of import modifier "remote" in there is the difference. Its just a
bit of meta-data, but it helped with resolution of the dependency. Along
the way, I've also added "lazy" as a modifier, which helps know how to
break apart the application when I do concatenation during the build.

I'm not suggesting this syntax or semantics, but it occurred to me that
perhaps if we could work some metadata into an import statement it could be
a way of giving additional information to the loader. Perhaps it could be
used for url resolution. For example, the "cdn" flag would let the loader
know to resolve the url to a cdn, etc.

- Russ


> { Kevin }
>
> ___
> 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: Refutable pattern

[Russell Leggett]

>
>
>  I think prefix ? is easier from a reading point of view, but I'm not
>> really married to either.
>>
>
> Agreed, and I posted mainly to try to get to consensus. Prefix-? looks
> like it is in the lead.


I think for the case of a long pattern with the ? outside the {}s, a prefix
? is easier to read. However, I think the reason why coffeescript and
typescript have gone with a suffix is because it is more common and natural
with the way ? is already used. To me it *screams* optional from regular
expression languages, but then is also the obvious placement for english
and many other written languages for the uninitiated.

The regular expression notation is probably the most compelling reason to
me for suffix-?. It is widely used across different regular expression
implementations, including ecmascript's. The regular expression roots have
also made it used in other related ways. For example, many different schema
notations use it like DTDs



Or relax ng compact syntax

element note { text }?

The precedence is more than just coffeescript.

- Russ


>
>
> /be
>
> __**_
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Ducks, Rabbits, and Privacy

[Russell Leggett]

>
> Perhaps I should have included a link:
>
> http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/plugin/domado.js?spec=svn5223&r=5223#359
>
> The idea is that 'Confidence' introduces a 'class with private fields' as
> if in Java: each object which has a private state record is considered to
> be an instance. The private record is used identically to Kevin Smith's
> examples, but my analogue of getPrivate on a new object fails hard rather
> than creating one — analogous to a ClassCastException.
>

I apologize for being lazy, but you provide an example of this being used
and not just the implementation?

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

Re: Security Demands Simplicity (was: Private Slots)

[Russell Leggett]

I've been stewing on this some more, and I realized something potentially
very interesting. If we use weakmaps in the manner specified by Kevin (with
Mark's help), I think we've very nearly added nominal typing to classes.
Assuming this privacy behavior was tied to classes, and assuming only
members of the class could be added to the weakmap, and assuming that *all*
members of the class belonged to the weakmap, the weakmap would quite
literally be the set of all members of that class (type). If there was an
easy way of asking the weakmap if an object belonged to the it, it would
the same as asking if the object was an instance of that class in a very
strong, nominal way. I guess I think this could be a plus, because it
allows for nominal types to be tied to classes, and yet do it in a very
javascripty feeling way.

Thoughts?

- Russ

On Fri, Jan 18, 2013 at 4:25 AM, Brendan Eich  wrote:

> Domenic Denicola wrote:
>
>>
>> If we’re making up new syntax, I think this would be much nicer if
>> “private.x” were spelled “this.@x” and “private(x)” were spelled “x.@”
>>
>>
> +1 and this is not a minor point.
>
>
>  Also, I don’t see why constructors need to use the “private.x” syntax
>> whereas other methods get to use the free variable?
>>
>>
> +2 -- Same here, only moreso!
>
> This thread goes over ground well-trod in 2011:
>
> https://mail.mozilla.org/**pipermail/es-discuss/2011-**July/015787.html
>
> and others -- search for "private data record" 2011 es-discuss site:
> mail.mozilla.org.
>
>
>  With these in mind I give the following fork: https://gist.github.com/**
>> 4562796 
>>
>>
> Kevin, could you do an alterna-gist as Domenic proposes? Of course there's
> much more at stake than syntax, but it would help.
>
> /be
>
>>
>> *From:*es-discuss-bounces@**mozilla.org 
>> [mailto:
>> es-discuss-bounces@**mozilla.org ] *On
>> Behalf Of *Kevin Smith
>> *Sent:* Thursday, January 17, 2013 21:40
>> *To:* Mark S. Miller
>> *Cc:* Brendan Eich; es-discuss
>> *Subject:* Re: Security Demands Simplicity (was: Private Slots)
>>
>>
>> It seems as if this approach to private class members also allows us to
>> describe private methods in a convenient way.  Private methods can be
>> attached to the _prototype_ of the private field object, thus avoiding
>> per-instance allocation.  Of course, the correct "this" value has to be
>> used in the expansion when calling the private method, but this approach
>> appears to be compatible with mixins (whereas private symbols are not).
>>
>> https://gist.github.com/**4561871 
>>
>> Thoughts?
>>
>> { Kevin }
>>
>>  __**_
> 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: Security Demands Simplicity (was: Private Slots)

[Russell Leggett]

On Thu, Jan 17, 2013 at 9:40 PM, Kevin Smith  wrote:

> It seems as if this approach to private class members also allows us to
> describe private methods in a convenient way.  Private methods can be
> attached to the _prototype_ of the private field object, thus avoiding
> per-instance allocation.  Of course, the correct "this" value has to be
> used in the expansion when calling the private method, but this approach
> appears to be compatible with mixins (whereas private symbols are not).
>
> https://gist.github.com/4561871
>
> Thoughts?
>

I've been on the fence with the debate, but I'll admit that this proposal
is really winning me over. I don't know if it's too late to get this syntax
in, but it would be a major win for me. I like this a lot more than private
symbols. It actually feels a lot like deconstructing an abstract data type
or pattern matching a case class in scala. There is something nice about
keeping all that extra stuff off the actual object. I'm not sure if I'd
still like it as much without the syntax, but maybe I would now.

I have do have a few questions on this, though:

1. How does this interact with proxies? I'm guessing that a proxy will not
map correctly and therefore make it inaccessible. Personally, I'm ok with
that.

2. Can I use private as a normal variable? Can it be bound to a new
variable, passed as an argument, or returned from a function?
constructor(balance = 0) {
let p = private;
p.checkNum(amount);
p.balance = balance;
}
I would understand not going this route, but it definitely restricts access
very tightly where private member or manually using a weakmap would allow
it. Perhaps that edge case can just be handled by falling back to manually
using a weakmap. I admit its a pretty narrow case, and perhaps is best to
not be easy to do. If it *were* to be allowed to be passed around, the
shorthand accessor syntax wouldn't work unless you captured the "this" as
part of the assignment. Definitely possible, though.

3. Can private() be used to add arbitrary object to the map even if they
don't belong to the class?
let obj = {};
private(obj).balance = 10;
I'm guessing not, as it translates to a get right now, but curious if this
was a consideration.

- Russ



>
> { Kevin }
>
> ___
> 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: Private Slots

[Russell Leggett]

On Wed, Jan 16, 2013 at 3:48 PM, Brendan Eich  wrote:

> Mark S. Miller wrote:
>
>> My position on private symbols.
>>
>> My position on classes is and has always been that classes are worth
>> introducing into the language*only*  if they give us, or can be used
>>
>> with, an affordable means for true object encapsulation. Assuming
>> Allen is right about what actual implementors will do (which I find
>> plausible) then WeakMaps are not that means. Given other discussions,
>> I am confident that the objects-as-closures pattern will not become
>> efficient either -- it is likely to continue to cost an allocation per
>> method per instance as its semantics naively suggests. So of the
>> options practically on the table, I think private symbols are the only
>> workable choice. If this is correct, then I consider private symbols
>> to be a requirement. Am I missing anything?
>>
>
> I agree, but David Bruant is arguing for weakmap-with-hint still, and
> Kevin is arguing (my summary) "YAGNI" to high-integrity privacy, not
> exclusively but for most developers -- and for the SES minority, weakmaps
> are enough.


I think Kevin's argument is pretty strong. SES is definitely not everyone,
and unique is pretty powerful, especially if you make the slot
non-enumerable. The when in doubt... argument has been made. ES6 is pretty
stuffed as it is. Thinking about ES7, though, I thought of a possibly
interesting place that might be more fitting for private style slots.

I've thought about the tradmark(
http://wiki.ecmascript.org/doku.php?id=strawman:trademarks) proposal a lot,
because I keep hearing the notion of a brand being used as a reason for a
private symbol. Perhaps branding could be implemented with private
symbols... *or* perhaps high-integrity privacy could be related with brand.
A brand could open the door to ADT/typeclass/protocol style abstractions,
and perhaps that is a better location for privacy.

- Russ


>
>
> /be
>
> __**_
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Private Slots

[Russell Leggett]

> I have suggested before that it would be good to put control
> over object iteration into the hands of the object authors, by
> enabling them to override the slot iteration method.
> One would need to find a way of doing so without exposing private names,
> but it should allow object authors to handle your a-c, as well as define
> what cloning/mixing should do in
> the presence of private state (however encoded, although
> private slots might make this easier/more explicit).


I might be missing something, but isn't this basically covered with the
enumerable flag? And that brings us back around - if we only had unique
symbols and we defined the property using the symbol, and made it
enumerable false, would it still be private? Am I missing something obvious
(I probably am)? I know this is more work, but it would be more orthogonal.
Sugar could be added to class to make this better.

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

Re: fail-fast object destructuring (don't add more slop to sloppy mode)

[Russell Leggett]

On Wed, Jan 2, 2013 at 1:13 PM, Brendan Eich  wrote:

>
> Here I part company only on syntax:
>
> r = o?.p.q   {p?: {q: r}} = o
> P=o.p; Q=o?.q{p: P, q?: Q} = o
>
> And of course, the short-hand works:
>
> p=o.p; q=o?.q{p, q?} = o
>

I love this. +1000.

As I've said previously, I think pattern matching would pair exceptionally
well with EcmaScript, and refutable destructuring is a great first step
towards that. After a little bit of use, I expect the community to demand
it, even if they aren't familiar with it in other languages.

"I want to destructure here, but I have a couple of possible options. If
only there was some kind of switch case with pattern matching..."

No chance of getting pattern matching in for ES6 by any chance, is there? ;)

- Russ


>
> /be
>
> __**_
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: excluding features from sloppy mode

[Russell Leggett]

On Fri, Dec 28, 2012 at 9:53 AM, Kevin Smith  wrote:

>
> Sorry, I should have expanded further - that was my point. Node is a case
>> where I can see classes being used without modules. I imagine native class
>> support will hit v8 soon enough, and I could see people start using them
>> without trying to switch to ES6 modules.
>>
>
> Ah - true.  They can put a "use strict" at the top if they want that.
>  Honestly, though, won't Node users be the first to start coding in ES6
> modules?
>

I guess we'll see soon enough, but I think there's still going to be a big
battle between ES6 modules and node modules and amd/requireJS. Any early
adopter types have already probably invested in something, and because the
porting isn't always straightforward, I think many will stick with what
they've got for a while. I'd honestly really like to start using ES6
modules soon, but I'm still racking my brain for the right way to do it,
because there are a lot of features I've built that are not compatible.

- Russ

>
> { Kevin }
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: excluding features from sloppy mode

[Russell Leggett]

On Fri, Dec 28, 2012 at 6:06 AM, Kevin Smith  wrote:

>
>
>> What about node code?
>>
>
> Well, node modules are not ES6 modules.  They are functions with an
> implicit head and braces.  So implicit strict mode, applied to ES6 modules,
> would not apply to them.
>

Sorry, I should have expanded further - that was my point. Node is a case
where I can see classes being used without modules. I imagine native class
support will hit v8 soon enough, and I could see people start using them
without trying to switch to ES6 modules.


>
> { Kevin }
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: excluding features from sloppy mode

[Russell Leggett]

On Dec 27, 2012, at 8:54 AM, Kevin Smith  wrote:

> 
>>> Since any new code will likely be written as a module (even in the 
>>> near-term, transpiled back to ES5), this would be the ideal scenario.
>> 
>> Which "this" do you mean? modules (in or out of line) implying strict mode 
>> can target ES5 strict, no problem.
> 
> "This" meaning all module code (in or out-of-line) is implicitly strict.  If 
> that's the case, then implicit rules for anything else essentially becomes 
> moot:  module code will dominate by far.  Even in the near term, many 
> developers will start writing in ES6 modules, and transpiling back to ES5.  
> If all modules are strict, then the transpiler will insert the required "use 
> strict" directive, and all is good.
> 
> To put another spin on it, how often will we see a class that is outside of 
> *any* module?
What about node code?

- Russ
> 
> { Kevin }
> 
> ___
> 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: A Variation on ES Modules

[Russell Leggett]

I will admit - this seems very readable to me, and I don't feel like I have
a lot of questions about edge cases. I would be pretty satisfied with it.

This might be a bit of a tangent, but there is something else that's been
bugging me. It's almost 2013 now, and we're fill in the gaps for ES to be
ready for large projects etc. The modules syntax/functionality seems
fine... but I wonder if its just playing catch up or if its actually taking
the opportunity to be the best it can be. Specifically, I'm wondering about
the modularity question. I understand that with ES being so dynamic it's a
lot easier to create mocks for testings, etc. but with static modules,
don't we run the risk of having the same problems as Java and needing some
kind of dependency injection? Maybe I'm just worried for no reason, just
thought I would throw it out there.

- Russ


On Wed, Dec 19, 2012 at 10:24 AM, Kevin Smith  wrote:

> I've worked up a concrete variation on the modules syntax:
>
> https://gist.github.com/4337062
>
> I believe that it presents a clean, simple model and coding experience.
>  Comments welcome!
>
> - Kevin
>
> ___
> 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: Module Comments

[Russell Leggett]

On Thu, Dec 6, 2012 at 1:46 PM, Brendan Eich  wrote:

> David Herman wrote:
>
>> >  Cool, definitely want the plain identifier form, it's part of the
>>> binding (and destructuring) pattern language.
>>>
>>
>> Well, the thing is it isn't consistent with the destructuring meaning:
>> dropping the curlies here means extracting a single export (aka property),
>> which is not what it means in destructuring assignment/binding anywhere
>> else.
>>
>
> You are so right. Therefore I think Yehuda et al. (as Andreas affirmed)
> are spot-on in advocating
>
> import foo from "foo"; // import the singleton export = thing from "foo"
> import {bar} from "foo"; // import the bar export from "foo"
>
> and we don't have a RTL problem.


+1

For some reason I thought this is actually how it was working at some
point, but I haven't been following as closely as I should.


>
>
> /be
>
> __**_
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why are non-method properties in a prototype an anti-pattern?

[Russell Leggett]

On Wed, Nov 7, 2012 at 12:27 PM, Kevin Smith  wrote:

>
>> Any other reasons for why they are discouraged?
>>
>
> This footgun:
>
> function MyClass() {
>
>   this.value = 1;  // OK
>   this.list.push(0);  // Modifying the list for every instance -
> probably not intended.
> }
>
> MyClass.prototype.value = 0;
> MyClass.prototype.list = [];
>

+1 beat me to it.


>
> - Kevin
>
> ___
> 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: `free` operator

[Russell Leggett]

> Yehuda's "action at a distance" complaint is definitely a valid
> concern.  However, note that an object can't be freed unless you have
> a reference to the object.  Thus, any code that would set my reference
> to undefined could only do so if it was also capable of mutating the
> object in any other way (adding/removing properties, etc.)
>
> So, we already have this:
>
> function () {
> // acquire a ref from some external code
> // no way of knowing what else is sharing this object
> var x = func()
> x.foo = 'bar'
> // other code...
> doAnotherThing()
> // not guaranteed!
> assert(x.foo === 'bar')
> }
>
> Whenever you have a reference to an object that is shared with some
> other code, there's the potential for action at a distance.  The
> proposal here is to make that action a bit more powerful.


JavaScript is mutable enough. I wouldn't want this anywhere near my code or
any library I ever used. It completely removes control from someone writing
code. Yes, mutation is possible now, but numbers, boolean, and strings are
not, and you can freeze and object if you want to. You said yourself that
the problem is with the code that is doing the leaking. Better tools to fix
your code is a nice addition, but adding an operator like this has the
potential to add weird bugs all over. If you're only working on your own
code base, maybe a tool like this is fine, shoot yourself in the foot, but
in an eco-system of sharing packages and libraries, etc. this is just more
ammunition to bad practice. If you are skilled enough to know the right
time to use an operator like this, you're skilled enough to fix your code.
If its hard to fix, tools could surely assist.

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

Re: Avoiding overloading the term “prototype”

[Russell Leggett]

>
> By the way, let deprecate (that is, recommend not to use) __proto__ and
> introduce @parent (or other term) instead, while both having the same
> behaviour.
>
>
I'm not sure what to call it, but I think this would be much nicer than
__proto__ and consistent with the new way of doing things. Here are some
ideas:

   - @proto
   - @extends
   - @parent
   - @prototype
   - @prototypeOf

@prototypeOf seems a little silly as a property name, but it would work
well with getPrototypeOf()

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

Re: Modules, Concatenation, and Better Solutions

[Russell Leggett]

On Wed, Oct 17, 2012 at 1:59 PM, Kevin Smith  wrote:

>
> So any reference to A (not necessarily dotted)  in the outer module
>> triggers hoisted initialization of A? And if  no such reference exists
>> module A is essentially deal code?
>>
>
> So side-effects would be allowed by the language, but would be incredibly
> confounding.  Hmmm
>

I'm not sure if I like how this is turning out. I think modules should
either not allow side effects, or should be evaluated immediately like an
IIFE. While I appreciate lazy evaluation when it is really utilized like
Haskell, I think it would be very surprising here. If we need to make it
easier for concatenation, maybe what we really want is an easy way to
effectively prime the module loader with a sort of cache so that it only
"loads" the module when needed, in the same way it would work as multiple
http requests, but it never needs to go to the server.

// a.js
import b from "b.js";
console.log("a");
export let a = "a";

// b.js
console.log("b");
export let b = "b";

// main.js
import a from "a.js";
console.log("main");

becomes

//lib.js
module "a.js" {
import b from "b.js";
console.log("a");
export let a = "a";
}
module "b.js" {
console.log("b");
export let b = "b";
}

//main.js
import a from "a.js";
console.log("main");

The idea here, is to allow a new bit of syntax where the module identifier
is a string literal. If that is the case, it assumes the module is loaded
in place of a file, where the url for the file is the value of the string
literal. Just to be clear, though, it doesn't actually execute the module
at all - it just caches it in the loader.

Of course, the content in main.js could still just go in lib.js, but I
wanted to point out something important, namely that the import of "a.js"
can be retained *as is* which is another potential problem with module
concat.

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

Re: Feed back and proposal for modules: allow importing ES5 files

[Russell Leggett]

On Tue, Sep 25, 2012 at 12:08 AM, 程劭非  wrote:

> Thanks, Claus and Alex,
>
> I've looked at the Loader but it seems to be async?
>
> I know there are many ways to load multiple files together(iframe, XHR,
> script element and datauri for browser host) but what I'm suggesting is to
> make es6 module more friendly to es5 libraries.
>
> I mean currently the es6 module grammar is using
>
> export var a;
> var b;
> var c;
>
> But why not export all top-level scope variables and let developers use
> IFFE to hide variables?
>
> var a; // export a automatically
> void function(){
> var b;
> var c;
> }();
>
> This will make libraries like old versions of jQuery work with es6 module
> without any code change. These libraries might be on CDN and changing their
> code will be a big cost in some scenarios.
>
>
Why not simply the proposal a little. It would be nice to be able to export
top level etc. but I think there is a clear danger there. What if instead
of trying to make arbitrary scripts into modules, we just did the loading,
making sure the script was loaded before running the code that depended on
it. ES5 relies on global scope, and so would this. Instead of allowing:

import "jQuery1.3.2.js","MyModule.js" as MyModule;

Maybe just allow something like:

import "jQuery1.3.2.js"
import "MyModule.js"

$(..).attr(..)

Those scripts would still be executed in the global scope, and so this
module would be able to access $. It would be extremely easy to wrap this
way as well. Otherwise, you'd still need to worry about actually loading
the dependency, no?

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

Re: Save modification made by a ecmascript on svg file

[Russell Leggett]

This mailing list is for discussion about the ecmascript language design
itself. I actually think stackoverflow.com is your best bet for your type
of question. To give you my own very brief take on it - browser save always
just saves the original document it downloaded, whether html or svg. If you
want to save the updated version, you would have to use JS to get it out of
the DOM, and either send it to a server, or use the HMTL5 file apis.

- Russ

On Tue, Sep 11, 2012 at 12:51 PM, Rick Waldron wrote:

> I think the SVG2 working groups are a more appropriate venue for this
> question, the mail list is here: www-...@w3.org
>
> http://www.w3.org/TR/SVG2/
>
> Rick
>
>
>
> On Tue, Sep 11, 2012 at 12:46 PM, Mister Vanhalen <
> mistervanha...@gmail.com> wrote:
>
>> Hello everyone,
>>
>> I created a small program in an svg file.
>> I can color some parts of my svg file thank to a ecmascript script.
>> But when I save my svg after changing color in a navigator, I didn't get
>> a modified svg.
>>
>> My svg is the same as the initial.
>> In my ecmascript I use x.setAttribute("fill", "blue") and some other
>> function to change the visual.
>>
>> I would like to save when I modify color in a navigator (like an
>> usual program).
>>
>> - I open my svg in a navigator
>> - I change the color (through the ecmascript)
>> - I save the svg in my navigator with the modifications
>>
>> How can I manage the question?
>>
>> Thank you for your help,
>>
>> Mr
>>
>>
>> ___
>> 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: Hash style comments

[Russell Leggett]

Not to keep being down on this post, but as long as YAML adds JS style
comments, wouldn't JSON still be a strict subset?

On Wed, Aug 8, 2012 at 12:57 PM, Jussi Kalliokoski <
jussi.kallioko...@gmail.com> wrote:

> And even if it wasn't, it wouldn't make much sense to use the only
> punctuation symbol we have left for comments where we already have two
> syntaxes. :)
>
> Cheers,
> Jussi
>
>
> On Wed, Aug 8, 2012 at 7:38 PM, Rick Waldron wrote:
>
>>
>>
>> On Wed, Aug 8, 2012 at 11:58 AM, Trans  wrote:
>>
>>> Hi. First time posting to the list, so please forgive if I am not
>>> following proper approach.
>>>
>>> I'd like to make one proposal for future of EMCAScript. I would like
>>> to see support for `#` comment notation.
>>>
>>
>> The # is already on hold for several potential syntax additions:
>>
>> - sealed object initializers
>> http://wiki.ecmascript.org/doku.php?id=strawman:obj_initialiser_methods
>> - Tuples http://wiki.ecmascript.org/doku.php?id=strawman:tuples
>> - Records http://wiki.ecmascript.org/doku.php?id=strawman:records
>>
>> Rick
>>
>>
>>
>>
>>>
>>> The reasons for this are more interesting than one might think.
>>>
>>> First, of course, is the simple fact that `#` is a very common
>>> notation among programming languages. It is used by Shell scripts,
>>> Ruby, Python, even Coffeescript, and many others.
>>>
>>> Secondly, `#` is preferable to `//` in that it is only one character
>>> instead of two, and albeit subjective (IMHO) it just seems a little
>>> bit more aesthetic.
>>>
>>> But another reason, that few will at first consider, is the
>>> relationship between JSON and YAML. Their respective development teams
>>> made an effort to ensure JSON was a perfect subset of YAML. Now there
>>> is consideration of JSON5 (https://github.com/aseemk/json5). JSON5
>>> adds support for comments, however it is Javascript style comments,
>>> where as YAML supports `#` style comments. This causes the
>>> superset-subset relationship to break. To help remedy this going
>>> forward, it would be very helpful if EMCAScript also supported `#`
>>> comments. The YAML spec could in turn add support for `//` style
>>> comments.
>>>
>>> To be clear, I am not suggesting that `//` be deprecated. That would
>>> simply break far too much old code for no good reason! I am just
>>> seeking for `#` to be supported too.
>>>
>>> Thanks for consideration,
>>> trans
>>> ___
>>> 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: strawman for the := operator

[Russell Leggett]

On Wed, Aug 8, 2012 at 12:35 PM, Brendan Eich  wrote:

> Erik Corry wrote:
>
>> Hi
>>
>> This proposal offers a way to get around some of the strange semantics
>> of '=', specifically the way read-only properties and setters on
>> objects in the prototype chain can restrict what you can do on the
>> receiver of an assignment.
>>
>
> This is "strange" only insofar as you can't say what you mean if you want
> to override. There's no law of nature requiring = to override, though.
>

I actually think that the behavior of = makes total sense in regards to
setters and read-only properties. If that was not the behavior, it would be
pretty silly. If = on a setter overrode the setter, it would defeat the
point of the setter. Same with read-only properties.


>
> Assigning != defining in ES5, even in reality in fixed implementations of
> ES3, and in truth going back to the first JS implementation: proto-setters
> (internal, hidden) are invoked by assignment, readonly proto-props prevent
> = being used to override on a delegating object (silent failure, of course,
> due to lack of try/catch).
>
> What I'm getting at: is assignment != defining strange, or is the lack of
> expressiveness that left JS with = but not := strange, or is = not defining
> strange? I didn't want to assume the last was what you meant, since it is
> not obvious and not the only possible strangeness or asymmetry.


I think the problem is really the conflation of = depending on the context.
In more classical languages, there is a separation between methods and
data. Overriding would never be done with =. If it was data, it would set
the value of the field for that instance, and if it was defining a method,
that would typically be done as an extension. I think that a happy path for
users could aid in untangling the confusion, but I think we have to be
clear about what that happy path should be.


>
>
> However it has some strangeness itself:
>>
>> * There is little point in having read-only properties if the common
>> way to do assignment is :=.  := will just walk all over a read-only
>> property.
>>
>
> No, readonly properties must be {writable: false, configurable: false} to
> have integrity, and := cannot redefine a non-configurable property.


This brings me to an important point. I think we are conflating too much
the ease of definition with the intent of Object.extend. Allen's strawman
actually says := is similar in intent but not semantics. I don't like that,
and I think it adds to the confusion. I think we have three cases here.

   1. You would like to mixin additional behaviors. This is commonly done
   with something like Object.extend, but that typically relies on [Put]
   semantics, but we really would like those to be defined. Mixins are
   available in many languages in various forms. There are many
   implementations for doing them in JavaScript and they are fairly commonly
   used. Mixins typically involve a group of methods which should always be
   mixed in together. Making super work correctly here is important.
   2. You would like to define a single property using a similar style as
   =, but you want to make sure it is a definition instead of a put.
   3. You have several values that you would like to [Put] - basically just
   a batch assignment.

I believe that := is ill suited to straightening out these cases. I think
it will commonly be needed for #3, but instead do definition. Its
convenience lends itself to abuse.

What I would recommend instead is that we match the cases more accurately.
For #1, I think we try to frame it for what it is - a mixin. I think that
is should be usable in conjunction with classes, as well single objects. I
would probably suggest the keyword mixin, but since I think we're avoiding
new keyword, perhaps we can reuse "with". Scala actually uses "with" for
this exact purpose.

//can be used as part of the class declaration
class Foo with Enumerable {
//if similiar to ruby, would supply an each method here
}

//can be using in conjunction with extends
class Foo extends Bar with Enumerable{...}

//can also be used on a single instance
class Point {
   constructor(x,y) {
  this with {
 //define accessor properties on new object that bind to
closure captured private state
 get x() {return x},
 set x(value) {x = value),
 get y() {return y },
 set y(value) {y = value},
 moveTo(newX, newY} {
x = newX;
y = newY;
 }
  }
   }
}

//assuming the 'with' operator returned the LHS after the operation, it
would be easy to be expressive doing something like
let myPoint = new Point() with OneOffMixin;

One important point to be clear about. Even though the RHS would allow any
object, it would only actually copy the functions. This would be consistent
with MaxMin classes, and prevent the foot gun that Rick points out in his
do

Re: Terminology: named data properties

[Russell Leggett]

On Tue, Aug 7, 2012 at 8:04 AM, Dean Landolt  wrote:

>
>
> On Mon, Aug 6, 2012 at 5:38 PM, Axel Rauschmayer  wrote:
>
>> What is the endgame? Add more terminology to the spec or try to define a
>> term to be adopted into the spoken lexicon?
>>
>> The former doesn't currently have any ambiguity and the latter is tough
>> because...
>>
>> 1. Most devs don't even use the term "accessor", instead they say
>> "getter-setters"
>>
>> 2. Most devs will use "value" to describe a scalar and "object" or
>> "reference" to describe an object... "data" is used to mean either/both
>> (which is why Brendan's "value objects" makes complete sense: looks like a
>> value, but is actually an object)
>>
>> 3. "method" is the only commonly used term
>>
>>
>> Good points.
>>
>> Axel, I don't think "we" can redefine the jargon commonly used by JS
>> developers. It's enough to track and influence what's commonly written and
>> spoken.
>>
>> In the spec, even ignoring common usage, I would not try to mess with
>> "data property" right now. As Rick notes, "value" may be taken to mean
>> "primitive, not reference (object)."
>>
>>
>> Got it. Wanted to avoid NIH in my writings, but will try my best to keep
>> my own terminology consistent.
>>
>> I thought value objects came from “compare by value”, but then I am still
>> making Rick’s point.
>>
>
>
> I'm fairly sure the term *value* typically has nothing to do with being *
> scalar* (strictly speaking a string isn't scalar) or even primitive. It
> simply means immutable and identified by content, not reference -- and can
> just as easily apply to product types. This is also the definition given by
> the value object strawman [1] -- which I really hope to see advanced at
> some point.
>

This is my understanding of values as well.


>
> [1] http://wiki.ecmascript.org/doku.php?id=strawman:value_objects
>
> ___
> 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: The Name of the Name

[Russell Leggett]

Symbol is not bad. I think people could use it for similar purposes as
Ruby's symbols, but it might get a little confusing at the differences -
not that it should stop us if we like the word.

Some other ideas:

Key, Signature (unforgeable), Token, Privilege

- Russ

On Wed, Aug 1, 2012 at 5:06 PM, François REMY wrote:

> Symbol could already be used by parsers and compilers. What about
> UniqueName?
> --
> De : Rick Waldron
> Envoyé : 01/08/2012 22:34
> À : Mark S. Miller
> Cc : es-discuss
> Objet : Re: The Name of the Name
>
>
>
>
> On Wednesday, August 1, 2012 at 4:26 PM, Mark S. Miller wrote:
>
> I like it. +1.
>
> Symbol was on my short list but worried it was too similar to Name.
>
> It seems less likely to conflict with extant code, but not by much.
>
> +1 (but we can get weirder if we wanted to)
>
> Rick
>
> On Wed, Aug 1, 2012 at 1:22 PM, Kevin Reid  wrote:
>
> Lisp precedent: Objects which are used to name things (that is, they
> are used as keys by identity), and may be not globally-named
> themselves, are called symbols.
>
> On Wed, Aug 1, 2012 at 12:47 PM, Mark S. Miller 
> wrote:
>
>
> Now that we have both private Names and unique Names, the general
> category covering both is simply Names. Properties can therefore be
> indexed by strings or Names. Strings are the ones consisting of a
> sequence of characters that can typically be pronounced. Names are
> anonymous identities.
>
> In the real world, names and identities are distinct concepts, and
> names are the one corresponding to a unique sequence of characters
> that can be pronounced.
>
> Is "Name" exactly the wrong name for a opaque unique identity
> typically used to index a property? Is there a better term?
>
> --
> Cheers,
> --MarkM
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> --
> Cheers,
> --MarkM
> ___
> 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: ES Modules: suggestions for improvement

[Russell Leggett]

On Tue, Jul 24, 2012 at 5:11 PM, Brendan Eich  wrote:

> Sam Tobin-Hochstadt wrote:
>
>> But I don't think we should ban people from
>> using `import *` because sometimes it's hard to reason about.
>>
>
> Just to focus on import *, here's where I am:
>
> I'm in favor of deferring (not to say cutting) import *, in order to get
> ES6 modules spec'ed and avoid protracted maybe-good/maybe-bad arguments.
>
> If someone prototyping or REPL'ing feels the pain, they should wail in
> agony. Enough wailing and we'll figure out something for their use case --
> but not on the critical path for ES6.


+1 I'm all for deferring on this. Its easy to add later, but you can't take
it back. I'm used to using import * with Java, but I think the pattern
matching should be concise enough, and I think it probably the right level
of explicitness.

- Russ

>
>
> /be
>
> __**_
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Updates to Object.observe

[Russell Leggett]

On Tue, Jul 17, 2012 at 9:54 PM, Rick Waldron wrote:

>
>
> On Tue, Jul 17, 2012 at 7:49 PM, Erik Arvidsson 
> wrote:
>
>> We've done a bunch of updates to Object.observe in preparation for the
>> next weeks face to face meeting. The updates are based on feedback
>> from multiple people but more feedback is always welcome.
>>
>> http://wiki.ecmascript.org/doku.php?id=strawman:observe
>
>
>
> Erik,
>
> This is really shaping up nicely!
>
> I have a only a few small pieces of feedback at the moment and I apologize
> in advance, because the first is definitely bikeshedding.
>
> The term "unobserve" feels clumsy, mostly because it's not a word, whereas
> "unobserved" is a word — but is an adjective, not a verb. Prefixing words
> with "un" is done so to reverse them, eg. I zip my sweatshirt, then unzip
> my sweatshirt. As a programmer, what I really want to do is "ignore" any
> further changes, right? "ignore" is actually the opposite of observe, so it
> makes sense that I would...
>

Another possibility would be "addObserver" and "removeObserver" to match
addEventListener and removeEventListener - although I shudder to model any
method names from the DOM.

I like how simple and clean this is. Having implemented a databinding
framework myself, I certainly appreciate the benefit this would provide.
However, this is really only a building block and not a full solution.
There will still likely have to be libraries that build on top of this for
most cases. That might be fine, but I have a few possible suggestions in
case there is some room to expand the API a little.

One of the absolutely most useful things I would not want to live without
in a databinding framework is bind to properties or property paths. It is
extremely common to want a handler to only listen for changes to a single
property - the same way event handlers do. Something like:

Object.observe(o,"x",observer);

Which would only be notified of changes to x, instead of having to check
which property each time. Its a minor thing, but common.

In my framework it is also possible to databind to a whole path - so lets
say something like:

Object.observe(o,"x.y", observer);

This would be "attached" at o, but it listens down the whole path, so a
change to the y on x would fire, but a change to x would fire also fire
with the new x's y property. This would automatically remove any observers
from the old x.y path and attach observers to the next x.y path. This sort
of thing is incredibly common and powerful in data bound templates.

I would understand if this expanded the API, but if there's an effort here
to provide common features, that would be up at the top for me.

Another couple of other things to consider:

   - A way of firing the callback immediately on attaching - as a way of
   sort of priming any state that depends on the binding. If I have o1 and o2
   and I want them to stay in sync one way - if I attach an observer to o1, I
   might want it to immediately fire with all of the current values of o1 so
   that o2 is up to date. I find there are many cases where one is better than
   the other so this is nice to be configurable.
   - A way of making a block of changes atomically, so that multiple
   changes to the same object can be performed without firing callbacks, and
   then firing the callbacks at the end. This can be important for ensuring a
   consistent state before any observer callbacks fire. Alternatively to
   creating some kind of block, it would be powerful to have the option of
   tying the callbacks to the event loop - I believe this is what ember.js
   does, though I'm sure it could be done a lot more efficiently natively.

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

Re: New Guy with ECMA Question

[Russell Leggett]

Sorry, John, this is not the right area. This group is for the discussion
of the design of the language itself. I think the best place for you to ask
this question is stackoverflow.com

Good luck!

- Russ

On Wed, Jul 11, 2012 at 1:46 PM, John  wrote:

> Hello,
>
> I am not even sure I am in the right area to ask this question but I am
> getting zero support from Novell Forums.  Long Story short...  I am using
> ECMA Script Builder that is in Novell Designer.  All I want to do is put a
> checkbox table on my "site" and it does not seem to work.  When I pull up
> the "site" it des not come up with any error but it will not show up on the
> page.  Anybody know what I am talking about?
>
> Attached is my html file that I created that shows just the chart I am
> trying to use (business pertaining info deleted of course).
>
> I hope I am in the right area!
>
> Thanks again!
> John
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: fail-fast object destructuring

[Russell Leggett]

On Wed, Jul 11, 2012 at 1:06 PM, Brendan Eich  wrote:

> Russell Leggett wrote:
>
>>
>>
>>
>> Russell asked about 'length' -- per a previous thread, I thought
>> we agreed that one [[Get]] of 'length' would be done before
>> matching if and only if the array literal contains a spread
>> (covering rest, the dual for a pattern of spread in the array
>> literal corresponding to the pattern).
>>
>>
>> Yes, I saw this in the proposal algorithm. The reason I ask is because it
>> seems odd to have an additional structural requirement in some cases but
>> not others. Of course, I understand why, but it sort of makes it look like
>> [] implies additional array-like structure in one case, but not in another.
>>
>
> You get what you ask for. Pay as you go. Buy by the yard.
>
> Ok, out of clichés but I hope we aren't going to revisit and impose a
> mandatory [[Get]] of 'length' on all array destructuring forms. That is
> otiose and costly (potentially very).
>
> The presence of ...rest is static syntax, so there's no runtime
> maybe/maybe-not hazard.


It would not have to be a [[Get]] of 'length', just a check for its
existence. Its no deal breaker for me, but it seemed a little inconsistent.
We could also be more strict with an Array.isArray check, but that seems
too strict. Anyway, just a thought.

- Russ


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

Re: fail-fast object destructuring

[Russell Leggett]

>
>
>
> Russell asked about 'length' -- per a previous thread, I thought we agreed
> that one [[Get]] of 'length' would be done before matching if and only if
> the array literal contains a spread (covering rest, the dual for a pattern
> of spread in the array literal corresponding to the pattern).


Yes, I saw this in the proposal algorithm. The reason I ask is because it
seems odd to have an additional structural requirement in some cases but
not others. Of course, I understand why, but it sort of makes it look like
[] implies additional array-like structure in one case, but not in another.

- Russ


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

Re: fail-fast object destructuring

[Russell Leggett]

On Wed, Jul 11, 2012 at 11:31 AM, Andreas Rossberg wrote:

> On 11 July 2012 17:20, Russell Leggett  wrote:
>
>> On Wed, Jul 11, 2012 at 7:14 AM, Andreas Rossberg wrote:
>>
>>> AFAICS, '?' on a variable itself would always be redundant, because a
>>> variable pattern is irrefutable anyway.
>>>
>>
>> So you're saying that even this should match in a refutable pattern:
>>
>>let [a,b,c] = [1,2];
>>
>> I would expect that to fail, especially in a hypothetical pattern
>> matching construct.
>>
>
> That would fail because the array pattern is refutable. What I meant is
> something else, namely that there is no difference between these:
>
>   let x = ...
>   let ?x = ...
>
> or these:
>
>   let {x: x, y: y} = ...
>   let {x: ?x, y: ?y} = ...
>
> Pattern matching recursively decomposes the RHS and matches a (sub)value
> against the respective (sub)pattern of the LHS. Once you reach a variable,
> that submatch is unconditional, so a '?' doesn't change anything.
>

I see. Yes, I would be happy to get rid of any of those useless patterns.

- Russ


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

Re: fail-fast object destructuring

[Russell Leggett]

On Wed, Jul 11, 2012 at 7:16 AM, Andreas Rossberg wrote:

> On 10 July 2012 10:47, Russell Leggett  wrote:
>
>> Another thing that I was also thinking is that it might look a little
>> nicer if the ? was a post-fix instead of a pre-fix.
>>
>> let {first, last, company?} = contact;
>>
>> I might be missing why this wouldn't work out, but it aesthetically just
>> looks right to me. It looks like the regex operator, and is also obviously
>> the position it would be in english.
>>
>
> Even parsing issues aside, I don't like postfix better. It is easier to
> miss, especially if ? was possible on patterns, not just properties.
> Consider:
>
>   let {the, that: {x, y}, those, theirs: {what, why}, thus}? =
> callSomething()
>
> How easy is it to miss the final '?' when looking for the binding of 'x'?
>
> But even on longish property names it can be a tad too easy to overlook:
>
>   let {what, why, whatTheHeckIsGoingOn?} = callSomething()
>

I know what you're saying, but I think it is widely used as postfix. People
are used to it. And it reads fine to me here:

Pattern ::= "{" (Field ("," Field)* ","?)? "}"
  | "[" ArrayPatternList "]"
ArrayPatternList ::= "..." Element
   | Element? ("," Element?)* ("," "..." Element)?
Element ::= Pattern | LValue
Field   ::= Identifier (":" Element)?
LValue  ::= 

 - Russ

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

Re: fail-fast object destructuring

[Russell Leggett]

On Wed, Jul 11, 2012 at 7:14 AM, Andreas Rossberg wrote:

> On 10 July 2012 10:17, Russell Leggett  wrote:
>
>> Yes, I think that arrays are likely the strongest case for ? on bindings.
>> Something like this would be nice:
>> let [first,last,?company] = contact.split(",");
>>
>
> Actually, I don't see how this is a case of "? on bindings". In fact, the
> '?' would have to be interpreted as part of the array pattern syntax for
> the above to make sense (in analogy to object patterns, it happens to be
> associated with the implicit property name "2").
>

Well, I mean, if you could put it on {}, [], and on variable names, it
would have to be part of the expression cover grammer as Brendan was
talking about. I suppose technically I should have said "? on expressions
that can be interpreted as patterns" or something.

In the array case, I guess it would be the equivalent of

let {0:first, 1:last, ?2:company} = contact.split(",");

Although that highlights an interesting point about object patterns,
perhaps it was already covered. If the property is not a valid identifier,
it could not use the property shorthand form. This should be an early error.

Also related, is there any structural requirement for the value being
matched in the case of a [] pattern? If you use ..., there is a requirement
to support length.


>
> AFAICS, '?' on a variable itself would always be redundant, because a
> variable pattern is irrefutable anyway.
>

So you're saying that even this should match in a refutable pattern:

   let [a,b,c] = [1,2];

I would expect that to fail, especially in a hypothetical pattern matching
construct.

- Russ


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

Re: fail-fast object destructuring

[Russell Leggett]

On Tue, Jul 10, 2012 at 10:40 AM, Brendan Eich  wrote:

> Russell Leggett wrote:
>
>> Another thing that I was also thinking is that it might look a little
>> nicer if the ? was a post-fix instead of a pre-fix.
>>
>> let {first, last, company?} = contact;
>>
>> I might be missing why this wouldn't work out, but it aesthetically just
>> looks right to me. It looks like the regex operator, and is also obviously
>> the position it would be in english.
>>
>
> We have to parse LHS-of-assignment patterns using the Expression cover
> grammar, so this does not work in general due to ?:.
>
> If we parse only in binding contexts (let, const, var on the left, or
> formal params and catch clauses), then we could use a different pattern
> grammar. Worth breaking uniformity with assignment expressions?


Right, I've mostly been thinking about only declaration forms of
assignment, however, thinking about it now, wouldn't it be only a single
token of lookahead to disambiguate? A postfix "optional" operator could
only be followed by , ] } or = (when in the value position) - none of which
would be valid tokens for the ternary operator. If it is on an object
property, it could actually be followed by a :, but that is unambiguous
because it is a property, not an expression.

- Russ


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

Re: super constructor calls for max/min classes

[Russell Leggett]

On Mon, Jul 9, 2012 at 8:47 PM, Allen Wirfs-Brock wrote:

>
> On Jul 7, 2012, at 8:14 PM, Luke Hoban wrote:
>
> Two questions on maximally minimal classes.
>
> 1) Should a super constructor call be made if no derived constructor is
> specified?
>
> The wiki and spec drafts suggest that no super call is made automatically
> on behalf of the developer if they leave off a constructor declaration in a
> derived class.  So the example below would run without error and print
> 'undefined'.
>
>class Animal { constructor(name) { this.name = name; } }
>class Snake extends Animal { }
>var sam = new Snake("Sammy the Python")
>console.log(sam.name)
>
> This looks likely to cause problems in practice.  Would it be better to
> behave similar to Ruby/CoffeeScript where the default constructor of a
> class with a super class specified is to apply the super constructor with
> the same arguments?  So the above would print 'Sammy the Python'.
>
> Reaching back to a previous version of "class as operator", this came up
as well.
https://mail.mozilla.org/pipermail/es-discuss/2011-November/018599.html

Here, I believe even Allen was warming to the idea of a pass through
constructor. Personally, I think it makes a lot of sense, because then it
would effectively work like an overloaded method, which I like, although it
would actually have to be a new constructor. It seems like a very
reasonable option.

>
> so would:
>
>class Example extends Object {};
>var x = new Example();
>
> call the Object constructor (as a function) with no argument.  That is
> going to allocate an extra object that gets immediately discarded but I
> guess that is harmless.  However, it's not clear to me why
> class Example2 {}
> shouldn't also make that pointless call, if we do it in the first case.
>

I believe somewhere in that thread I mentioned, somebody suggested skipping
a super call to Object's constructor. I think this would be reasonable.


>
> Also not that Object.prototype.constructor is a writable property.  That
> means that somebody could hijack such automatic calls to and take control
> of the initialization of all such objects.
>

> I see where you are coming from on this, however to some degree the logic
> in support of it it feels awfully close to the logic for providing auto
> coercions (which we have, but most people regret).
>
> Not everybody seems to agree that what Ruby does is desirable.  See the
> comments on
> http://odetocode.com/Blogs/scott/archive/2010/07/13/ruby-initialize-and-super.aspx
>
>
>
> 2) Should explicit constructors without any calls to super be an error in
> classes with declared super classes?
>
>
> I feel much stronger that this should be a no.   Maybe the whole point of
> the subclass is eliminate something undesirable in the super class
> constructor.  This is a dynamic language, many things are possible.  Let's
> not over constrain the developer.
>
> Also, if it wasn't clear from above, I'm not a big fan of
>class Example2 {}
> having different semantics from
>class Example2 extends Object {}
>
> (although if you read the  ES6 draft carefully you will see that
>   class Example2 {}
> is actually specified to be equivalent to
>   class Example2 extends Object.prototype {}
> this ensures that the Example2 class object does not inherit Object class
> methods such as Object.defineProperty.  If you want to inherit those
> methods you would implicitly say
>class Example2 extends Object {};
> )
>

>
> Similar to the first issue above - the wiki and spec draft say that the
> following runs without error and prints 'undefined'.
>
>class Animal { constructor() { this.data = "hello"; } }
>class Snake extends Animal { constructor() { } }
>var sam = new Snake()
>console.log(sam.data)
>
> Again, it looks easy to accidentally miss making a super constructor call
> from an explicit derived class constructor.  There's less that can be
> usefully done about this case than in #1 above.  But this might be a case
> where a stronger static check is warranted.  Something like: report an
> early error when a constructor in a class with a super class specified does
> not include any super call.  This may have to be left to lint tools though.
>
>
> I think lint tools would be a fine place for this sort of audit rule.
>

Yes, I think lint is perfect for missing calls to super as opposed to
missing constructors.

- Russ


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

Re: fail-fast object destructuring

[Russell Leggett]

Another thing that I was also thinking is that it might look a little nicer
if the ? was a post-fix instead of a pre-fix.

let {first, last, company?} = contact;

I might be missing why this wouldn't work out, but it aesthetically just
looks right to me. It looks like the regex operator, and is also obviously
the position it would be in english.

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

Re: fail-fast object destructuring

[Russell Leggett]

On Mon, Jul 9, 2012 at 4:04 PM, Brendan Eich  wrote:

> Russell Leggett wrote:
>
>> Options type objects:
>> let {url,callback,?errback} = options;
>> This lets you very clearly decompose an object and declaratively show
>> which values are optional and which ones are not. If all of them are
>> optional, the ? would just go to the left of the brace, but really this
>> should be the minority case for most situations.
>>
>
> Dave and I had talked about prefix-? as applying only to property names,
> since that covers all but the top level for object patterns:
>
>   {required, ?optional_shallow}
>   {required, ?optional_deep: {foo, bar, ?baz}}
>
> but of course it leaves out the top level.


This makes a lot of sense. It is certainly smaller. I do worry, though,
that it might fall short for the people that would like irrefutable
destructuring. I had imagined that ?{a,b,c} could be used in a case where
all properties would be optional. I did have a question about refutability.
What would happen here?

   let {?a,?b} = null;

Even though both properties are optional, would this still fail? Does the
{} imply some structure? What if we were thinking about actual pattern
matching in the future? Would this just match anything? If we say it should
not match anything, then you would need ?{} to make it fully irrefutable.


>
> If we make prefix-? apply to the "value" side of the ":" (which in object
> patterns is optional, but if present names the binding not the property),
> then we have
>
>   {required, optional_shallow: ?renamed_optional_shallow}
>   {required, optional_deep: ?{foo, bar, ?baz}}
>
> and the object shorthand would still be wanted:
>
>   {required, ?optional_shallow}
>
> This is a strictly larger grammar, though. If we can keep prefix-? in the
> property name side, then all we lose is the top level.
>
> Array patterns don't have explicit "0", "1", "2", etc., property names,
> though so either prefix-? doesn't work, or you have to use an object
> pattern (which works on array values), or else prefix-? goes before the
> binding name (the "value" side) as above.
>
>
>  A disparate list of possible types of matches. This is common in
>> "overloaded" functions where the number and type of arguments can be wildly
>> different. This is probably the strongest case against refutable matching,
>> because it is so likely to result in mismatches which should have logic
>> performed on them instead of having an error thrown.
>>
>
> Right, this minority case could be left out. The array pattern situation
> is stronger motivation for prefix-? applying to bindings not property names.


Yes, I think that arrays are likely the strongest case for ? on bindings.
Something like this would be nice:
let [first,last,?company] = contact.split(",");

And certainly, if you wanted to be able to destructure a list of arguments,
some of which being  optional, it would be very useful.

Ultimately, while I think I could personally do fine with fewer points of
prefix-?, I can see a few cases for it, especially on arrays. I worry that
without supporting these, refutable by default won't be able to reach
consensus.

- Russ




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

Re: fail-fast object destructuring

[Russell Leggett]

>
> On Mon, Jul 9, 2012 at 12:36 PM, Andreas Rossberg wrote:
>>
>>> I agree with almost everything you said. But just to clarify, I think
>>> you actually meant "refutable" everywhere you said "irrefutable".
>>>
>>> /Andreas
>>>
>>> So I corrected my bonehead mistake, here it is again in case anybody
wanted to more cleanly respond to specific points.

==

I would love to see 2/B. A lot of that is likely because I would love to
see pattern matching, though, I'll admit. I think that the ? on refutable
portions of the pattern would work well with the new default and
existential operators, while I think ! will not have a good analog. If I
were to throw out another reason based on destructuring assignment alone,
and not pattern matching later, I would say that if parts of the
destructuring are likely to fail, it would be better to know upfront. If
there are optional fields, ? clearly expresses that. If there are wildly
unknown structures, destructured assignment is probably not the best
approach, or at least there should be some structural testing upfront
(pattern matching would of course be ideal).

As for usability testing, while it obviously is not done refutably in
spidermonkey now, I think we can at least look to other languages. Looking
over several languages, all of the ones I have seen are refutable. Some are
strongly typed languages, but not all. Python does not have complete
patterns, it can basically just destructure list, but even it requires that
the number of elements be correct. Erlang, OCaml, and F# all allow full
pattern assignments, and they will all throw errors if not correctly
matched. Obviously, it is a little different than what it would be in ES,
they have full on patterns not just destructuring, but it would clearly be
all the more consistent when patterns *hopefully* get added. I know that JS
users have come to expect a certain amount of carefree imputing, but
destructuring is new (outside of FF), and I think it is certainly an area
which has options. I haven't exactly done a formal survey of languages, but
from what I've seen JS would be the first to be so lenient. Allowing ? in
portions of a pattern, I actually think would be the perfect compromise.
People who write very loose code will either have to put ?s on their
patterns or keep working the same way they have been, but if there isn't a
reasonable amount of checking by default, I think we're going to be seeing
some more WATs in presentations. JS gets picked on for how much coercion
and silent errors it will chug along with. Best practices of always using
=== and avoiding 'with' are just a couple of examples.

Finally, I would like to take the approach of looking at the best way to
handle the different use cases.
Really simple destructuring with expected results:
let {x,y} = getPoint();
In my opinion, this should throw if x or y are not available. It is
unlikely that the coder is checking properties here, they are just going to
call other functions passing through x or y. It would probably be better to
get the error as soon as possible. Much easier to debug that way. In many
cases, I think these types of destructuring assignments will lead to
effortless checking that would previously have been missed because of the
extra effort to add those checks in as if statements.
Options type objects:
let {url,callback,?errback} = options;
This lets you very clearly decompose an object and declaratively show which
values are optional and which ones are not. If all of them are optional,
the ? would just go to the left of the brace, but really this should be the
minority case for most situations.
A disparate list of possible types of matches. This is common in
"overloaded" functions where the number and type of arguments can be wildly
different. This is probably the strongest case against refutable matching,
because it is so likely to result in mismatches which should have logic
performed on them instead of having an error thrown. However, it is also
the strongest case for pattern matching. There is nothing wrong with
wanting to accept differently shaped things, but right now there is not
really a great facility for acting on them. Pattern matching would be
ideal. I think it would be such a powerful addition to the language as it
is used right now, that it honestly pains me that we would cut out the
possibility. I would love to see patterns now, but I can understand
waiting. Making a decision which would close it off though would be
extremely disappointing.
I know that full blown patterns are out of scope (though I'm hoping maybe
this discussion might change that), but even if we can't have it now, I
think refutable destructuring would really make people see the potential.
Even if no facility was provided for it, a hypothetical match function
could be created which would take function and execute them in sequence in
a try catch until one did not fail. I think we can do better than that and
should prob

Re: fail-fast object destructuring

[Russell Leggett]

::double-facepalm::

On Mon, Jul 9, 2012 at 12:54 PM, Russell Leggett
wrote:

> ::faceplam::
>
>
> On Mon, Jul 9, 2012 at 12:36 PM, Andreas Rossberg wrote:
>
>> I agree with almost everything you said. But just to clarify, I think you
>> actually meant "refutable" everywhere you said "irrefutable".
>>
>> /Andreas
>>
>>
>> On 9 July 2012 18:19, Russell Leggett  wrote:
>>
>>>
>>>
>>> On Fri, Jul 6, 2012 at 1:37 PM, Brendan Eich wrote:
>>>
>>>> Andreas Rossberg wrote:
>>>>
>>>>>
>>>>> We should talk more at this month's TC39 meeting, but I see a
>>>>> sharp divide ahead:
>>>>>
>>>>> 1. Choose (A), possibly with modification, either rejecting useful
>>>>> pattern matching decisively, or else making its pattern language
>>>>> differ by making prefix-! implicit. But you rejected splitting
>>>>> pattern meaning across destructuring and future pattern-matching,
>>>>> in the last sentence cited above.
>>>>>
>>>>> XOR
>>>>>
>>>>> 2. Choose (B) because future-proofing for pattern matching wants
>>>>> prefix-?, and impose a compatibility break from what we and others
>>>>> implemented, and what most JS users might expect based on JS's
>>>>> carefree imputing of undefined.
>>>>>
>>>>>
>>>>> Agreed.
>>>>>
>>>>>
>>>>> Comments from es-discuss peanut gallery welcome.
>>>>>
>>>>> I could go for 1/A, except for two facts. First, I believe there
>>>>> is a non-trivial body of Firefox JS that depends on imputing
>>>>> undefined. Second, and what is more important: we haven't
>>>>> usability-tested 2/B at all.
>>>>>
>>>>>
>>>>> Did you mean "could go for 2/B" there?
>>>>>
>>>>>
>>>> Evidently!
>>>>
>>>> I rearranged and renumbered but missed this one. Clearly I meant 2/B.
>>>> I'm a bit unhappy about making such a change so long after implementing 1/A
>>>> (without prefix-!). But never mind me -- what do others think?
>>>
>>>
>>> I would love to see 2/B. A lot of that is likely because I would love to
>>> see pattern matching, though, I'll admit. I think that the ? on refutable
>>> portions of the pattern would work well with the new default and
>>> existential operators, while I think ! will not have a good analog. If I
>>> were to throw out another reason based on destructuring assignment alone,
>>> and not pattern matching later, I would say that if parts of the
>>> destructuring are likely to fail, it would be better to know upfront. If
>>> there are optional fields, ? clearly expresses that. If there are wildly
>>> unknown structures, destructured assignment is probably not the best
>>> approach, or at least there should be some structural testing upfront
>>> (pattern matching would of course be ideal).
>>>
>>> As for usability testing, while it obviously is not done irrefutably in
>>> spidermonkey now, I think we can at least look to other languages. Looking
>>> over several languages, all of the ones I have seen are irrefutable. Some
>>> are strongly typed languages, but not all. Python does not have complete
>>> patterns, it can basically just destructure list, but even it requires that
>>> the number of elements be correct. Erlang, OCaml, and F# all allow full
>>> pattern assignments, and they will all throw errors if not correctly
>>> matched. Obviously, it is a little different than what it would be in ES,
>>> they have full on patterns not just destructuring, but it would clearly be
>>> all the more consistent when patterns *hopefully* get added. I know that JS
>>> users have come to expect a certain amount of carefree imputing, but
>>> destructuring is new (outside of FF), and I think it is certainly an area
>>> which has options. I haven't exactly done a formal survey of languages, but
>>> from what I've seen JS would be the first to be so lenient. Allowing ? in
>>> portions of a pattern, I actually think would be the perfect compromise.
>>> People who write very loose code will either have to put ?s on their
>>> patterns or keep working the same way they h

Re: fail-fast object destructuring

[Russell Leggett]

::faceplam::

On Mon, Jul 9, 2012 at 12:36 PM, Andreas Rossberg wrote:

> I agree with almost everything you said. But just to clarify, I think you
> actually meant "refutable" everywhere you said "irrefutable".
>
> /Andreas
>
>
> On 9 July 2012 18:19, Russell Leggett  wrote:
>
>>
>>
>> On Fri, Jul 6, 2012 at 1:37 PM, Brendan Eich  wrote:
>>
>>> Andreas Rossberg wrote:
>>>
>>>>
>>>> We should talk more at this month's TC39 meeting, but I see a
>>>> sharp divide ahead:
>>>>
>>>> 1. Choose (A), possibly with modification, either rejecting useful
>>>> pattern matching decisively, or else making its pattern language
>>>> differ by making prefix-! implicit. But you rejected splitting
>>>> pattern meaning across destructuring and future pattern-matching,
>>>> in the last sentence cited above.
>>>>
>>>> XOR
>>>>
>>>> 2. Choose (B) because future-proofing for pattern matching wants
>>>> prefix-?, and impose a compatibility break from what we and others
>>>> implemented, and what most JS users might expect based on JS's
>>>> carefree imputing of undefined.
>>>>
>>>>
>>>> Agreed.
>>>>
>>>>
>>>> Comments from es-discuss peanut gallery welcome.
>>>>
>>>> I could go for 1/A, except for two facts. First, I believe there
>>>> is a non-trivial body of Firefox JS that depends on imputing
>>>> undefined. Second, and what is more important: we haven't
>>>> usability-tested 2/B at all.
>>>>
>>>>
>>>> Did you mean "could go for 2/B" there?
>>>>
>>>>
>>> Evidently!
>>>
>>> I rearranged and renumbered but missed this one. Clearly I meant 2/B.
>>> I'm a bit unhappy about making such a change so long after implementing 1/A
>>> (without prefix-!). But never mind me -- what do others think?
>>
>>
>> I would love to see 2/B. A lot of that is likely because I would love to
>> see pattern matching, though, I'll admit. I think that the ? on refutable
>> portions of the pattern would work well with the new default and
>> existential operators, while I think ! will not have a good analog. If I
>> were to throw out another reason based on destructuring assignment alone,
>> and not pattern matching later, I would say that if parts of the
>> destructuring are likely to fail, it would be better to know upfront. If
>> there are optional fields, ? clearly expresses that. If there are wildly
>> unknown structures, destructured assignment is probably not the best
>> approach, or at least there should be some structural testing upfront
>> (pattern matching would of course be ideal).
>>
>> As for usability testing, while it obviously is not done irrefutably in
>> spidermonkey now, I think we can at least look to other languages. Looking
>> over several languages, all of the ones I have seen are irrefutable. Some
>> are strongly typed languages, but not all. Python does not have complete
>> patterns, it can basically just destructure list, but even it requires that
>> the number of elements be correct. Erlang, OCaml, and F# all allow full
>> pattern assignments, and they will all throw errors if not correctly
>> matched. Obviously, it is a little different than what it would be in ES,
>> they have full on patterns not just destructuring, but it would clearly be
>> all the more consistent when patterns *hopefully* get added. I know that JS
>> users have come to expect a certain amount of carefree imputing, but
>> destructuring is new (outside of FF), and I think it is certainly an area
>> which has options. I haven't exactly done a formal survey of languages, but
>> from what I've seen JS would be the first to be so lenient. Allowing ? in
>> portions of a pattern, I actually think would be the perfect compromise.
>> People who write very loose code will either have to put ?s on their
>> patterns or keep working the same way they have been, but if there isn't a
>> reasonable amount of checking by default, I think we're going to be seeing
>> some more WATs in presentations. JS gets picked on for how much coercion
>> and silent errors it will chug along with. Best practices of always using
>> === and avoiding 'with' are just a couple of examples.
>>
>> Finally, I would like to take the approach 

Re: fail-fast object destructuring

[Russell Leggett]

On Fri, Jul 6, 2012 at 1:37 PM, Brendan Eich  wrote:

> Andreas Rossberg wrote:
>
>>
>> We should talk more at this month's TC39 meeting, but I see a
>> sharp divide ahead:
>>
>> 1. Choose (A), possibly with modification, either rejecting useful
>> pattern matching decisively, or else making its pattern language
>> differ by making prefix-! implicit. But you rejected splitting
>> pattern meaning across destructuring and future pattern-matching,
>> in the last sentence cited above.
>>
>> XOR
>>
>> 2. Choose (B) because future-proofing for pattern matching wants
>> prefix-?, and impose a compatibility break from what we and others
>> implemented, and what most JS users might expect based on JS's
>> carefree imputing of undefined.
>>
>>
>> Agreed.
>>
>>
>> Comments from es-discuss peanut gallery welcome.
>>
>> I could go for 1/A, except for two facts. First, I believe there
>> is a non-trivial body of Firefox JS that depends on imputing
>> undefined. Second, and what is more important: we haven't
>> usability-tested 2/B at all.
>>
>>
>> Did you mean "could go for 2/B" there?
>>
>>
> Evidently!
>
> I rearranged and renumbered but missed this one. Clearly I meant 2/B. I'm
> a bit unhappy about making such a change so long after implementing 1/A
> (without prefix-!). But never mind me -- what do others think?


I would love to see 2/B. A lot of that is likely because I would love to
see pattern matching, though, I'll admit. I think that the ? on refutable
portions of the pattern would work well with the new default and
existential operators, while I think ! will not have a good analog. If I
were to throw out another reason based on destructuring assignment alone,
and not pattern matching later, I would say that if parts of the
destructuring are likely to fail, it would be better to know upfront. If
there are optional fields, ? clearly expresses that. If there are wildly
unknown structures, destructured assignment is probably not the best
approach, or at least there should be some structural testing upfront
(pattern matching would of course be ideal).

As for usability testing, while it obviously is not done irrefutably in
spidermonkey now, I think we can at least look to other languages. Looking
over several languages, all of the ones I have seen are irrefutable. Some
are strongly typed languages, but not all. Python does not have complete
patterns, it can basically just destructure list, but even it requires that
the number of elements be correct. Erlang, OCaml, and F# all allow full
pattern assignments, and they will all throw errors if not correctly
matched. Obviously, it is a little different than what it would be in ES,
they have full on patterns not just destructuring, but it would clearly be
all the more consistent when patterns *hopefully* get added. I know that JS
users have come to expect a certain amount of carefree imputing, but
destructuring is new (outside of FF), and I think it is certainly an area
which has options. I haven't exactly done a formal survey of languages, but
from what I've seen JS would be the first to be so lenient. Allowing ? in
portions of a pattern, I actually think would be the perfect compromise.
People who write very loose code will either have to put ?s on their
patterns or keep working the same way they have been, but if there isn't a
reasonable amount of checking by default, I think we're going to be seeing
some more WATs in presentations. JS gets picked on for how much coercion
and silent errors it will chug along with. Best practices of always using
=== and avoiding 'with' are just a couple of examples.

Finally, I would like to take the approach of looking at the best way to
handle the different use cases.

   1. Really simple destructuring with expected results:
   let {x,y} = getPoint();
   In my opinion, this should throw if x or y are not available. It is
   unlikely that the coder is checking properties here, they are just going to
   call other functions passing through x or y. It would probably be better to
   get the error as soon as possible. Much easier to debug that way. In many
   cases, I think these types of destructuring assignments will lead to
   effortless checking that would previously have been missed because of the
   extra effort to add those checks in as if statements.
   2. Options type objects:
   let {url,callback,?errback} = options;
   This lets you very clearly decompose an object and declaratively show
   which values are optional and which ones are not. If all of them are
   optional, the ? would just go to the left of the brace, but really this
   should be the minority case for most situations.
   3. A disparate list of possible types of matches. This is common in
   "overloaded" functions where the number and type of arguments can be wildly
   different. This is probably the strongest case against irrefutable
   matching, because it is so likely to result in mis

Re: Static Module Resolution

[Russell Leggett]

On Fri, Jul 6, 2012 at 10:58 AM, Aymeric Vitte wrote:

>
>
>
>>>
>>  Do we have a survey of the use of sync against async ? I think it would
>> show that sync is much more used (wrongly or easy way again, but...).
>
>
>  I completely disagree with this. Most developers without the
> knowledge/skill to know why sync is bad are just going to use a library
> like jQuery - which uses async. I'm not aware of any major library that
> uses sync as a default for their ajax api or uses sync in their own code.
>
>  - Russ
>
>
> I am not refering to libraries but to developers/sites that indeed are
> using libraries and then feel (usually wrongly) necessary to extend it with
> unofficial/not good libraries or their own and then add some stuff around
> that usually is sync, as far as I saw debuging node-dom or looking at usual
> web sites
>

I'm not saying people don't do it, I was saying that the percentage is
likely far smaller than you claim. Perhaps I'm deluding myself. Anyway, I
don't think we should cater to something that is considered bad practice.
As Brendan has said, lets lead the horses away from the rotting vegetables
with better carrots.

- Russ


>
> --
> jCore
> Email :  avi...@jcore.fr
> Web :www.jcore.fr
> Webble : www.webble.it
> Extract Widget Mobile : www.extractwidget.com
> BlimpMe! : www.blimpme.com
>
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Static Module Resolution

[Russell Leggett]

On Fri, Jul 6, 2012 at 7:30 AM, Aymeric Vitte wrote:

>
> Le 06/07/2012 03:17, Brendan Eich a écrit :
>
>> Aymeric Vitte wrote:
>>
>>> Then the sync xhr is absurd ?
>>>
>>
>> It's a botch that developers avoid , else they jank the user interface.
>>
> Yes, as far as you can or as far as you want to avoid unnecessary
> complication, for example projet [1] is loading quite a lot of things using
> xhr and scripts (which are loading others), the priority was to load the
> user interface as fast as possible (offline feature, etc), then most of the
> loadings are async but the sync xhr could not be avoided (easy way
> sometimes but as far as I remember not using it could lead to situations
> that looked unresolvable)
>
>   We've been over this. Are you seriously defending it?
>>
> Do we have a survey of the use of sync against async ? I think it would
> show that sync is much more used (wrongly or easy way again, but...).


I completely disagree with this. Most developers without the
knowledge/skill to know why sync is bad are just going to use a library
like jQuery - which uses async. I'm not aware of any major library that
uses sync as a default for their ajax api or uses sync in their own code.

- Russ


> The possibility to have a sync xhr remains usefull, but I see that I will
> be opposed strong arguments (could not find previous discussions about it).
>
> If not possible, could we have at least a System.download(url,callback),
> as simple as just loading the url content and not caring about what is
> inside ? So we have an alternative to creating globals or linking to globals
>
> [1] : http://www.blimpme.com/mobile/
>
>
> --
> jCore
> Email :  avi...@jcore.fr
> Web :www.jcore.fr
> Webble : www.webble.it
> Extract Widget Mobile : www.extractwidget.com
> BlimpMe! : www.blimpme.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: A few more questions about the current module proposal

[Russell Leggett]

Oh, I also meant to ask - I do have a question of my own. It seems so
basic, but I can't figure it out. If I have a file that contains two
modules - let's say in foo.js

--- foo.js 
module Foo {
export let x = 42;
}
module Bar {
export let y = 12;
}

and I try to do:

import y from "foo.js"

What happens? Similar problem if I try to do

import "foo.js" as Foo

Am I incorrect in thinking that there can be more than one top level
module? Or is it that an imported file is automatically a module, and
therefore Foo and Bar are nested modules in this case? Would I then have to
say "export module Foo..." and later "import Foo from "foo.js;"?

Also, I have a suggestion. It has recently been discussed about how to work
with legacy code. For example, the classic example of wanting to import
jQuery even if it is not defined as a module. What if we just allowed for
the syntax:

import "jquery.js"

with no "as" or "from". This would assume jquery.js is not a module file.
It would fail early if there were any imports or exports, and it would
execute in the global scope just like a script tag. The value of it,
though, would be to allow for a declaration of the dependency, and the
ability to load it without putting in a script tag. If multiple modules
import it, it would only be loaded once, and executed in the first place it
was needed, all without needing to include it with a script tag. Because it
is not allowed to contain imports, it would not be capable of causing
circular dependency issues, and because it does not have exports, it cannot
be interpreted as a module and used with the from/as syntax.

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

Re: A few more questions about the current module proposal

[Russell Leggett]

Sorry I haven't gotten a chance to get into this thread sooner, let me
catch up a bit:

On Wed, Jul 4, 2012 at 2:56 PM, Jussi Kalliokoski <
jussi.kallioko...@gmail.com> wrote:

> On Wed, Jul 4, 2012 at 9:13 PM, Sam Tobin-Hochstadt 
>  wrote:
>
>> On Wed, Jul 4, 2012 at 12:29 PM, Jussi Kalliokoski
>>  wrote:
>> >
>> > 1) How does the static resolution and static scoping behave when out of
>> the
>> > normal context. As an example if `import` is in an `eval()` call, what
>> would
>> > happen:
>> >
>> > var code = loadFromURL('http://example.org/foo.js') // content:
>> `import foo
>> > from "bar"`
>> > eval(code)
>> > console.log(foo) // ???
>>
>> First, what does `loadFromURL` do?  That looks like sync IO to me.
>>
>
> Indeed it is, to simplify things. Let's pretend it's a function that gets
> the text contents of a URL.
>
>
>> > Would this example block until the module is resolved and loaded? Would
>> it
>> > throw? What happens, exactly? As my $0.02 goes, I think it's a bad idea
>> to
>> > ban import in eval.
>>
>> Second, it depends on whether "bar" is a previously-loaded module.
>> For example, if "bar" is a library provided by the host environment,
>> such as the browser, then everything will be fine, and the code will
>> import `foo` successfully.  If "bar" is a remote resource, this will
>> throw -- we're not going to add synchronous IO to `eval` (or to
>> anything else).
>>
>
> So basically, eval()'ing something acquired via XHR would no longer give
> the same result as it does if the same script is in a script tag? Suffice
> to say I disagree strongly with this choice, but I'm sure the rationale
> behind this choice is strong.
>

So I guess my take on it is that any import statement should be illegal
inside of eval. Looking at the proposal, that doesn't sound like it,
though. Let's take the "loadFromUrl" out of the equation.

import foo from "baz"
var code = 'import foo from "bar"';
eval(code);
console.log(foo);

There is a reason why import got special syntax, and it wasn't just so that
it would be easier to type. Putting it inside eval eliminates any ability
for static analysis to happen upfront during the parse before actually
executing. The import dependency cannot be seen, and in this case there is
a collision on "foo" which should have been detected at compilation time. I
can think of a dozen other reasons why imports should not be allowed in
eval, but that's just one which seems like a pretty clear problem.

On Thu, Jul 5, 2012 at 8:56 AM, Kevin Smith  wrote:

>
> One question, though:  branching on the file extension, as above, will not
> generally work.  The source code might be served through a URL that does
> not have a file extension.  On the web though, we'll generally have access
> to a Content-Type header.  In the current design, there's doesn't appear to
> be a way to get that information.
>

This makes a lot of sense to me. Great idea.

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

Re: default `deleteCount` value of `Array.prototype.splice`

[Russell Leggett]

On Tue, Jul 3, 2012 at 6:28 PM, Brendan Eich  wrote:

> Allen Wirfs-Brock wrote:
>
>> On Jul 3, 2012, at 9:07 AM, Brendan Eich wrote:
>>
>>  Russell Leggett wrote:
>>>
>>>> ...
>>>>
>>>>
>>>> The spec states: "When the splice method is called with two or more
>>>> arguments..." - therefore, a.splice(2); leads to unspecified behavior.
>>>>
>>>
>> Technically that's not correct.
>>
>
> Note you are replying to Russell here and again later, not to me ;-).


Haha, yes, sorry, I bow to your superior spec-reading powers. I should not
have written with such a confident tone :)

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

Re: default `deleteCount` value of `Array.prototype.splice`

[Russell Leggett]

On Tue, Jul 3, 2012 at 9:09 AM, John-David Dalton <
john.david.dal...@gmail.com> wrote:

> Just checked and IE8 returns `[]` correctly w!
>
> On Tue, Jul 3, 2012 at 8:49 AM, John-David Dalton <
> john.david.dal...@gmail.com> wrote:
>
>> I recently saw something like
>>
>> var a = ['a', 'b', 'c', 'd'];
>> a.splice(2); // -> ['c', 'd'] in latest Chrome, Opera, Firefox, Safari,
>> Rhino, RingoJS, you name it
>>
>> by spec though I thought the `deleteCount` should be `0` and so return
>> `[]`.
>> http://es5.github.com/#x15.4.4.12
>>
>> "Let *actualDeleteCount* be min(max(ToInteger
>> (*deleteCount*),0),*len* –* actualStart*)."
>>
>> var a = ['a', 'b', 'c', 'd'];
>> a.splice(2, 0); // -> []
>>
>> Am I reading it wrong or is this a bug in most engines?
>>
>

The spec states: "When the splice method is called with two or more
arguments..." - therefore, a.splice(2); leads to unspecified behavior. If
you look at the MDN
docs,
splice called with only a single argument removes until the end of the
array, similar to the substring method.

"If no howMany parameter is specified (second syntax above, which is a
SpiderMonkey extension), all elements after index are removed."

Basically, what is happening here is that everyone else accepted the
spidermonkey extension, but technically because it is unspecified, browsers
can do what they want and still be considered compliant. Perhaps it is
something which should be *added* to the spec.

- Russ


>
>
> ___
> 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: Would some like Object.inspect(myObj) be useful?

[Russell Leggett]

On Thu, Jun 14, 2012 at 5:42 AM, Hemanth H.M  wrote:

> Was just wondering if something like *Object.inspect(myObj) *would give
> all the attributes of that particular object.


What would this function return? There's already an
Object.keysfunction
- does that do what you wanted? That's in ES5.

- Russ


>
>
> --
> *'I am what I am because of who we all are'*
> h3manth.com 
> *-- Hemanth HM *
>
> ___
> 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: Function length

[Russell Leggett]

On Wed, Jun 13, 2012 at 12:42 PM, Andreas Rossberg wrote:

> On 13 June 2012 15:25, Russell Leggett  wrote:
> > On Wed, Jun 13, 2012 at 5:29 AM, Andreas Rossberg 
> >> If I understand this correctly, then it will require every function
> >> closure to include meta information for performing the associated
> >> pattern match. Or, when you actually want this to be optimised, the
> >> ability to generate (probably lazily) and attach pattern matching code
> >> to _every_ function closure. That seems pretty intrusive.
> >
> > I'll respond a little out of order by saying that you believe patterns
> > independently implemented would be simple and efficient. If that is the
> case
> > (and I would think it was), then I don't really see how your argument
> holds
> > water. Let's just say we actually had patterns. I'll make an imaginary
> > syntax for them.
> >
> > let pattern = #({x,y});
> > pattern.matches({x:1,y:2});
>
> Well, that's not how other languages do pattern matching, or what the
> strawman proposes. Rather, you usually have a generalisation of what's
> the switch statement in JS, see the strawman. It makes matching,
> binding and dispatching into a single operation that can be compiled
> into efficient decision trees fairly easily (although JS's getters
> make matters less pleasant).
>

Right, I understand that. Yeah, I suppose my syntax was a little odd
towards helping my case. However, there is also this bit from Waldemar:

"Waldemar: where can you use refutable matching outside of switch/match
statements and perhaps catch guards?  switch/match statements are too
heavyweight and differ too much from irrefutable matching assignment;
catching doesn't really need destructuring but benefits from
conditions.  The typical usage (as in Perl) is to use them in if
statements:  if (pattern =~ expr) {we have matched!}"

If I could have my dream version of matching, it would probably be similar
to scala/haskell/erlang. We could maybe use "case" instead of "switch" at
the top. Not sure if that's confusing, but haskell/erlang use it and its
already reserved. Something like:

case p of {
[x,y] => ...
{x,y} => ...
* => throw ...
}

Which I would greatly prefer over the modified switch statement version. It
would be an expression, and have an intuitive tie in to arrow functions. As
you can see from this syntax, though, it's very similar to what can be
achieved using a match function taking arrow function arguments. But even
this form could be reduced down to a single pattern returning true, and a
default returning false and that would be the equivalent of a matches
method.


>
>
> >> Also, the programmer would have to create a closure for every match
> >> arm you ever want to use (unless the compiler is "sufficiently clever"
> >> to recognise rather non-trivial patterns, which I doubt). That is
> >> likely to be pretty costly.
> >
> > I guess to me this is just functional programming - its effectively a
> > callback for each pattern. The one which matches gets called. I don't see
> > why its so different than using forEach instead of a for loop. One is
> more
> > expressive and functional style, the other is more efficient.
>
> The different with forEach is that there is only one closure, and it's
> usually executed. In the case of a match, you'll have to create N
> closures while knowing that at most 1 will actually be called.
>

Depending on the way you used it, the set of closures could easily be
reused for multiple calls, the same way that Irakli's dispatcher helper
works. My point was more that developers have to weigh the tradeoffs for
expressivity vs efficiency now, and this would be no different.


>
>
> >> I'd say (despite being part of the pattern matching choir) that this
> >> is not the proper way to introduce a feature that, as a proper
> >> language construct, would be relatively simple, efficient, and
> >> independent of anything else.
> >
> > I would much prefer to have it as a full, proper language construct, and
> I
> > would not have suggested function.matches if I thought it would be future
> > unfriendly to adding them. On the contrary, my hope is that this would
> be a
> > low footprint feature, but would provide the tool missing to allow for
> the
> > community to play with patterns. One of the great things about
> JavaScript is
> > its flexibility, and the community has really used that to create the
> > cowpaths we later pave. As a way of figuring out the best way to add full
> > patterns to the l

Re: Function length

[Russell Leggett]

On Wed, Jun 13, 2012 at 5:29 AM, Andreas Rossberg wrote:

> On 12 June 2012 23:57, Russell Leggett  wrote:
> > This thread gave me an interesting idea on how to possibly attack pattern
> > matching in ES6 with no new syntax, and still leave room for more sugar
> > later. It actually comes from thinking about the original issue with
> > function.length and using it for arity-based dispatch. What if we just
> gave
> > a better method than length? What if we had something like
> > function.matches(args)? Where it would return true if all arguments were
> > bound, and no parameters resulted in an undefined binding.
> > function add(a,b){
> > return a + b;
> > }
> >
> > add.matches(1,2); // => true
> > add.matches(1); // => false
> > add.matches(1,2,3);  => false
>
> OK, I'll bite. I see lots of problems and unnecessary complexity here.
>
> If I understand this correctly, then it will require every function
> closure to include meta information for performing the associated
> pattern match. Or, when you actually want this to be optimised, the
> ability to generate (probably lazily) and attach pattern matching code
> to _every_ function closure. That seems pretty intrusive.
>

I'll respond a little out of order by saying that you believe patterns
independently implemented would be simple and efficient. If that is the
case (and I would think it was), then I don't really see how your argument
holds water. Let's just say we actually had patterns. I'll make an
imaginary syntax for them.

let pattern = #({x,y});
pattern.matches({x:1,y:2});

If my example pattern could be done simply and efficiently, then why
couldn't the same be done for function arguments. The only meta-data you
would need to store is exactly the pattern that is in the function
parameters. The body of the function provides no additional data. You could
either eagerly generate the pattern, or simply keep the parameter pattern
ast in the most efficient form to generate it lazily.

The simple (and overwhelmingly most common case) would just be a list of
parameters with no rest and no destructuring. Matching against this would
reduce to a simple arity check.


>
> Also, the programmer would have to create a closure for every match
> arm you ever want to use (unless the compiler is "sufficiently clever"
> to recognise rather non-trivial patterns, which I doubt). That is
> likely to be pretty costly.


I guess to me this is just functional programming - its effectively a
callback for each pattern. The one which matches gets called. I don't see
why its so different than using forEach instead of a for loop. One is more
expressive and functional style, the other is more efficient.


> I'm also not sure how you envision
> actually binding variables during a match. Are you suggesting that one
> does something like:
>
>  if (f.matches(x, y)) f(x, y)


> Even if this is abstracted into some 'match' function, a match would
> redundantly decompose x, y for f twice.
>

That is true. Perhaps a builtin Object.match function could optimize?
Still, it does not seem overwhelmingly inefficient, just not as nice as
built in pattern matching.


>
> And just to be clear, this feature also reveals implementation details
> of a function that it shouldn't. For example, it allows you to observe
> cases where a function ignores some of its documented arguments, or
> some parts of its arguments. So it has all the bad properties of the
> 'isBound' function we discussed earlier.
>

I mostly disagree. The signature of a function is it's interface. Even Java
let's you reflectively ask about a method's signature. In reality, it is
almost no different than function.length in terms of revealing
implementation details. My major problem with isBound is that it required
looking at the body of the function, because |this| isn't something you'll
see in a parameter list.

However, as I said, I only *mostly* disagree. The same reason I initially
cringed at Irakli's function.length request because I worried how it would
be abused, I have some of the same worries here. It could make for some
pretty subtle code to change what arguments you send a callback based on
its signature – but unlike function.isBound which I think had fewer
appropriate use cases and looked at the method body, I think
function.matches has a much clearer use case and does not expose too much.
I especially like it in the case of using it with arrow functions, which
have no |this| and no access to an arguments object. I debated about
suggesting it only be available on arrow functions, but I think there are
some big downsides to that too.


>
> I'd say (despite being part of the pattern matchin

Re: Function length

[Russell Leggett]

On Tue, Jun 12, 2012 at 1:06 PM, Brendan Eich  wrote:

> Russell Leggett wrote:
>
>> It does bring up something else, though, that I've avoided mentioning so
>> far, which is pattern matching. I haven't mentioned it because there is
>> clearly a strawman <http://wiki.ecmascript.org/**
>> doku.php?id=strawman:pattern_**matching<http://wiki.ecmascript.org/doku.php?id=strawman:pattern_matching>>
>> for it, and that never made it to harmony, but in light of this thread I
>> wanted to reiterate how useful it would be. It would not really help
>> function.length, but would address the real underlying problem that the
>> arity dispatcher is trying to tackle. In a language without overloading,
>> the ability to do pattern matching would be an excellent solution to a very
>> common problem. We already have destructuring, it seems like such a small
>> jump to pattern matching.
>>
>
> You are preacher, dherman and I are choir. Maybe patterns will make ES7.
> We shall try again.
>
>
>  Hard to tell from looking at the strawman why that never made it. If its
>> a matter or feature bloat, I would rate that higher than some other things
>> like default args or array comprehensions.
>>
>
> See March 2011 TC39 meeting notes, second day.
>
> Quotes below. Note some fine specimens of TC39's future-proofing
> fetishization on parade. I will say no more, as I think Dave agrees
> patterns were not fully baked.
>
> The way to get refutable matching into ES7 is to work now to address all
> the valid worries, and say why the other worries are false.
>

This thread gave me an interesting idea on how to possibly attack pattern
matching in ES6 with no new syntax, and still leave room for more sugar
later. It actually comes from thinking about the original issue with
function.length and using it for arity-based dispatch. What if we just gave
a better method than length? What if we had something like
function.matches(args)? Where it would return true if all arguments were
bound, and no parameters resulted in an undefined binding.
function add(a,b){
return a + b;
}

add.matches(1,2); // => true
add.matches(1); // => false
add.matches(1,2,3);  => false

This still suffers from the same problem as function.length, and when
dealing with simple arity and no destructuring/rest params, would act
exactly the same. However, Irakli's dispatcher utility does lay the
groundwork for something more interesting.

function makePoint(x,y){ return {x:x,y:y}; }
function drawLine({x:x1,y:y1},{x:x2,y:y2}){...}

let p1 = makePoint(1,2), p2 = makePoint(3,4);
drawLine.matches(p1,p2); // => true
drawLine.matches(1,2); // => false
drawLine.matches({x:1}, {y:2}) // => false
//only has to be a structural subset
drawLine.matches({x:1,y:2,z:3}, {x:1, y:2}) // => true

With that simple boolean function, Irakli's dispatcher utility could be
rewritten to loop through the list and check for a match instead of by
arity. It would work correctly for rest parameters, but even more
interesting, would work with all of the destructuring patterns.

let drawLine = dispatcher(
(x1,y1,x2,y2) => ...,
({x:x1,y:y1},{x:x2,y:y2}) => ...
);

Or a more functional replacement for switch

let result = match(value,
({x,y,z}) => "3d"
({x,y}) => "2d"
(...anything) => "not a point"
);

Its not as nice as full pattern matching with literals and wildcards, but
it could be pretty clean. If guards were added later, that would be an
obvious fit. If it became a popular pattern, we could pave the cowpath with
some sugar, and add the things that are missing now.

One of the benefits of getting started this way is that it could be shimmed
to just use length.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ||= is much needed?

[Russell Leggett]

On Tue, Jun 12, 2012 at 2:31 PM, Tom Ellis  wrote:

> I like the sound of ?= too.
>
> var a;
>
> //later on
>
> a ?= 15;
>
> It goes with all the other operators that are out there too (!=, =, ==,
> === etc).
>

+1, useful and intuitive.

- Russ


>
> Tom
>
> On 12 Jun 2012, at 19:04, Brendan Eich wrote:
>
> > Brendan Eich wrote:
> >> Is this (A ? B) ? C : D or A ? (B ? C) : D. We can disambiguate in the
> formal grammar but readers may rebel.
> >
> > Or A ? (B ? C : D), of course.
> >
> > Just say no to lone ? as new operator. I'm warming up to ?= though!
> >
> > /be
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Function length

[Russell Leggett]

On Mon, Jun 11, 2012 at 3:50 PM, Brendan Eich  wrote:

> Irakli Gozalishvili wrote:
>
>> Sorry for not being clear about this. Here is a simplified example of the
>> implementation:
>> https://gist.github.com/**2911817 
>>
>> Also this is just a single particular example, but I expect there to be
>> more. I think what I'm
>> really asking for is a way to know if …rest is being used.
>>
>
> Your code doesn't work on a function that uses arguments the old fashioned
> way, though.
>
> Yes, you can make ...rest affect .length and make a dispatcher that counts
> on that, but it's a just-so story and a hard case. Hard cases make bad law.
> If it really matters, we can provide better reflection facilities, but I'm
> pretty sure it doesn't occur enough to justify doing so now.
>
> So use the toString hack if you must and let's see if this use-case
> becomes hot.


I think this is a pretty creative snippet of code, but ultimately
unreliable for the reasons mentioned. It does bring up something else,
though, that I've avoided mentioning so far, which is pattern matching. I
haven't mentioned it because there is clearly a
strawmanfor
it, and that never made it to harmony, but in light of this thread I
wanted to reiterate how useful it would be. It would not really help
function.length, but would address the real underlying problem that the
arity dispatcher is trying to tackle. In a language without overloading,
the ability to do pattern matching would be an excellent solution to a very
common problem. We already have destructuring, it seems like such a small
jump to pattern matching. Hard to tell from looking at the strawman why
that never made it. If its a matter or feature bloat, I would rate that
higher than some other things like default args or array comprehensions.

- Russ

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

Re: Rest parameter syntax

[Russell Leggett]

On Tue, Jun 12, 2012 at 11:26 AM, Rick Waldron wrote:

>
>
> On Tue, Jun 12, 2012 at 10:38 AM, Felix Böhm  wrote:
>
>> Per definition, rest parameters always need to be at the end of a
>> FormalParameterList. I was wondering if this limitation could be liftet.
>>
>
>  Consider:
>
>
> function foo( a, b, ...others, c ) {
>   return [ a, b, others, c ];
> }
>
>
> foo( 1, 2, 3, 4, 5, 6, 7, 8, 9 );
>
>
>   a  b  others
> [ 1, 2, [ 3, 4, 5, 6, 7, 8, 9 ] ]
>
>
> How do you resolve where to stop claiming arguments as items in the rest
> param "others"?
>

Well, I mean, technically speaking its no different than a very simple
regex.

> /(.)(.)(.*)(.)/.exec("123456789");
["123456789", "1", "2", "345678", "9"]

> /(.)(.)(.*)(.)/.exec("123");
["123", "1", "2", "", "3"]

>From that perspective, it seems pretty deterministic and easy to explain.
There's probably a reason I'm not thinking of, though.

- Russ


Rick
>
>
>
>
>
>
>
>
>
> ___
> 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: arrows and a proposed softCall

[Russell Leggett]

On Tue, Jun 5, 2012 at 2:30 PM, Angus Croll  wrote:

> Yes the thread needs wrapping up. Maybe I can attempt summarize the
> dilemma - with a question:
>
> Is call/apply just a remedy for non-lexical this assignment? Or is it a
> powerful feature in it own right.
>
> I'm with the second camp, but I think I'm in the minority in this list
>

Call/apply are of course powerful features, but they should not be used
just for the sake of using them. You know what's cleaner looking than
call/apply? Just calling the function directly!

I think the bigger, but related question is, "When should dynamic |this| be
used?" Do you think the jQuery style of using the dynamic this in callback
is good? Many of us here do not. Dynamic |this| allows for functions to
work like methods - it enables mixins and all kinds of meta-programming
goodness. However, it can also be abused, and create really funky code that
can lead to weird surprises.

Maybe I'm just conservative here. I suppose I can see the appeal of not
having to add that pesky extra parameter and instead use |this| for
whatever arbitrary thing you might want to put there, but it sure seems
less readable to me. You might as well just use the arguments object for
everything instead having parameter names!

Until now, with the addition of bind, and the fat arrow, there were a lot
of common cases where you would have to put a callback method back with its
original |this| object. That is one use of call/apply, and one that will
hopefully need less use. Another nice use of it was to easily delegate by
using apply and passing through the arguments object. That will go away
with rest parameters. So yeah, we might be seeing less of call/apply with
ES6, but I think we're replacing them with better patterns instead of just
saying they aren't useful anymore.

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

Re: arrows and a proposed softCall

[Russell Leggett]

On Tue, Jun 5, 2012 at 12:36 PM, Brendan Eich  wrote:

>
> What I perceive from the JSFixed effort, and from Angus who is good enough
> to post here: people have a particular concern that fat-arrow is too sweet
> and it will lure the children into the witch's house: passing fat arrows to
> dynamic-this APIs.
>
> We have data suggesting that fat arrows address the dominant use-case,
> thanks to Kevin Smith and others. So fat arrows are in ES6, well and good.
>
> I think the particular concern about => being an attractive nuisance for
> some APIs such as Angus's mixin combinators, which rely on .call overriding
> |this|, can be addressed by adding -> too. Angus agrees, but -> is not on
> the boards for ES6 (yet).
>
> We could try to revive ->, but first, we should face the attractive
> nuisance argument squarely, instead of dancing around it with isBound
> abuses that try to "catch fat arrow going into the witch's house".


I think that with ->, a similar problem will still crop up - specifically
that => will be the more common use, and then in the rare case that -> is
needed, people may still use =>. Do we still need isBound to catch that
error as well? Even with the choice of -> or =>, the person writing the
code has to know which one to use and why. That means they have to
understand the whole dynamic |this| problem. I think that the dynamic
|this| behavior of jQuery is not something that should be encouraged. I
understand it is probably mostly that way because of the dom event api, but
that doesn't change the fact that it really has a bad smell to it.
CoffeeScript has ->, but if you look at the examples, none of them actually
make use of dynamic |this| except for methods, and we're adding a nice
method syntax, so it isn't really needed. Method syntax, and => should
cover the majority of cases and lead people down the right path.

I know this is going around in a circle, but my point is that adding ->
doesn't fix the problem, which is devs not knowing when to use => and when
to use function.

- Russ


>
>
> /be
>
> __**_
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: arrows and a proposed softCall

[Russell Leggett]

On Thu, May 31, 2012 at 1:32 PM, Andreas Rossberg wrote:

> On 31 May 2012 19:01, Bill Frantz  wrote:
> > On 5/31/12 at 2:27, rossb...@google.com (Andreas Rossberg) wrote:
> >
> >> A function is free to _document_ it as part of its
> >> contract, though.
> >
> >
> > Contracts are much more useful if they are enforced by the system, the
> > language and runtime in this case.
>
> It can already be enforced -- as a callee, do or don't use 'this'; as
> a caller, do or don't provide a receiver. What an isBound predicate
> brings to the table is the ability to second-guess the contract, and
> encourage callers to ignore it in cases where it is not actively
> enforced by the callee.
>

If you reframe the problem as |this| just being another parameter, this
whole debate seems quite silly to me. Any function that is written to have
a |this| value be dynamic, and possibly set by the caller can be rewritten
as a function that does not use |this| and simply has an extra parameter.
Framing it this way, asking for an isBound method is no more useful than
having a method isParamUsed(n) which checks if the nth parameter is used in
the function body.

There are certain cases where a dynamic |this| is a useful way to write
that sort of function. If it is being used as a method, or mixed in as a
method, that makes sense. The only other case that I don't actually like,
but we have to live with is DOM event handlers/jQuery event handlers. Other
than that, it just doesn't make sense. Any time a function is passed as an
argument and used, there is an implicit contract about what that function
should take as inputs, perform as side effects, and return. Whether or not
it uses |this| should not really be treated any differently than asking
what parameters the function expects/uses.

I think it would lead to brittle code to try to ask the function if it uses
|this| as some means of overloading/duck typing. That is too much
introspection into the implementation.

- Russ


>
> /Andreas
> ___
> 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