Cascade operator proposal — native fluent interfaces

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Cascade operator proposal — native fluent interfaces

Timothy Johnson
I'm putting together a proposal for a cascade operator like the one in dart. I think it fits the javascript design space quite well. The popularity of method chaining APIs points to this being something the javascript community wants.

For example

foo
    ..a.b = c
    ..d()

Would be equivalent to

foo.a.b = c
foo.d()

Or more accurately

(obj => {
    obj.a.b = c
    obj.d()
    return obj
})(foo)

The full proposal is here. Any thoughts?

Also, how do I go about getting this accepted at stage 0?


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Cascade operator proposal — native fluent interfaces

T.J. Crowder-2
On Sat, Nov 10, 2018 at 5:49 PM Timothy Johnson
<[hidden email]> wrote:

It's **great** to see a proposal backed by an example implementation. :-)

I suggest adding some explanation to the proposal about how your example knows the `..d()` applies to `foo` and not to `c`. From the Dart documentation, I'd *guess* (not being a Dart person) that it's because you'd need parens around the `c..d()` to force it to apply to that instead, but... More about the specific mechanics of that as it applies to JS would be useful.

Probably also worth a one-liner that you're aware of and have allowed for how this relates to numeric literals (e.g., `console.log(12..toString())`). I can see in your commit on the Babel fork that you have allowed for it, but for those who don't dig that deep...

If this were in the language, I'd happily use it. I don't really feel the lack of it, though.

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Cascade operator proposal — native fluent interfaces

Andrea Giammarchi-2
I have a dejavu ... a similar proposal was rejected a while ago.

Can't remember its name but it was like:

```js
foo.{
  a.b = c;
  d();
}
```

how is this different, if it's actually any different?


On Mon, Nov 12, 2018 at 2:23 PM T.J. Crowder <[hidden email]> wrote:
On Sat, Nov 10, 2018 at 5:49 PM Timothy Johnson
<[hidden email]> wrote:

It's **great** to see a proposal backed by an example implementation. :-)

I suggest adding some explanation to the proposal about how your example knows the `..d()` applies to `foo` and not to `c`. From the Dart documentation, I'd *guess* (not being a Dart person) that it's because you'd need parens around the `c..d()` to force it to apply to that instead, but... More about the specific mechanics of that as it applies to JS would be useful.

Probably also worth a one-liner that you're aware of and have allowed for how this relates to numeric literals (e.g., `console.log(12..toString())`). I can see in your commit on the Babel fork that you have allowed for it, but for those who don't dig that deep...

If this were in the language, I'd happily use it. I don't really feel the lack of it, though.

-- T.J. Crowder
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Cascade operator proposal — native fluent interfaces

Timothy Johnson

I believe you're referring to https://web.archive.org/web/20160310120516/http://wiki.ecmascript.org/doku.php?id=harmony:object_literals#object_extension_literal? While my proposal is similar in theory, it does have a few differences in practice. Namely, object extension literals only update properties on the root object, they don't allow for function calls. The intended purpose of the two proposals are also quite different: object extension literal were intended to be used as part of the object creation process, the cascade operator on the other hand, while it can be used for object creation, the main focus is to ease using objects.

Furthermore, object extension literals where proposed 7 years ago. Long before jQuery and the rise of fluent interface popularity in the javascript community.

To summarise: A similar proposal was indeed rejected but the cascade operator has notable differences, and javascript is in a very different place then it was 7 years ago.

On 11/12/18 5:31 AM, Andrea Giammarchi wrote:
I have a dejavu ... a similar proposal was rejected a while ago.

Can't remember its name but it was like:

```js
foo.{
  a.b = c;
  d();
}
```

how is this different, if it's actually any different?


On Mon, Nov 12, 2018 at 2:23 PM T.J. Crowder <[hidden email]> wrote:
On Sat, Nov 10, 2018 at 5:49 PM Timothy Johnson
<[hidden email]> wrote:

It's **great** to see a proposal backed by an example implementation. :-)

I suggest adding some explanation to the proposal about how your example knows the `..d()` applies to `foo` and not to `c`. From the Dart documentation, I'd *guess* (not being a Dart person) that it's because you'd need parens around the `c..d()` to force it to apply to that instead, but... More about the specific mechanics of that as it applies to JS would be useful.

Probably also worth a one-liner that you're aware of and have allowed for how this relates to numeric literals (e.g., `console.log(12..toString())`). I can see in your commit on the Babel fork that you have allowed for it, but for those who don't dig that deep...

If this were in the language, I'd happily use it. I don't really feel the lack of it, though.

-- T.J. Crowder
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Cascade operator proposal — native fluent interfaces

Michael Haufe-2
In reply to this post by Andrea Giammarchi-2

On Mon, Nov 12, 2018 at 7:31 AM Andrea Giammarchi <[hidden email]> wrote:
I have a dejavu ... a similar proposal was rejected a while ago.

Can't remember its name but it was like:

```js
foo.{
  a.b = c;
  d();
}
```

how is this different, if it's actually any different?


On Mon, Nov 12, 2018 at 2:23 PM T.J. Crowder <[hidden email]> wrote:
On Sat, Nov 10, 2018 at 5:49 PM Timothy Johnson
<[hidden email]> wrote:

It's **great** to see a proposal backed by an example implementation. :-)

I suggest adding some explanation to the proposal about how your example knows the `..d()` applies to `foo` and not to `c`. From the Dart documentation, I'd *guess* (not being a Dart person) that it's because you'd need parens around the `c..d()` to force it to apply to that instead, but... More about the specific mechanics of that as it applies to JS would be useful.

Probably also worth a one-liner that you're aware of and have allowed for how this relates to numeric literals (e.g., `console.log(12..toString())`). I can see in your commit on the Babel fork that you have allowed for it, but for those who don't dig that deep...

If this were in the language, I'd happily use it. I don't really feel the lack of it, though.

-- T.J. Crowder
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Cascade operator proposal — native fluent interfaces

kai zhu
quick PSA:

jslint recently (2018-09-27) added warning against "." delimited, per-line method-chaining [1]

```javascript
/*jslint node*/
"use strict";
var str = "hello world";

// jslint - no warnings
console.log(
    str.replace(
        "hello",
        "goodbye"
    ).replace(
        "world",
        "john"
    ).toUpperCase()
);

// jslint - warnings against "." delimited, per-line method-chaining
console.log(
    str
    // Unexpected space between 'str' and '.'.
    .replace("hello", "goodbye")
    // Unexpected space between ')' and '.'.
    .replace("world", "john")
    // Unexpected space between ')' and '.'.
    .toUpperCase()
);
```

[1] jslint commit 2018-09-27 - warn against per-line method-chaining

Screen Shot 2018-11-13 at 11.06.26 AM.jpg

On Tue, Nov 13, 2018 at 3:33 AM Michael Haufe <[hidden email]> wrote:

On Mon, Nov 12, 2018 at 7:31 AM Andrea Giammarchi <[hidden email]> wrote:
I have a dejavu ... a similar proposal was rejected a while ago.

Can't remember its name but it was like:

```js
foo.{
  a.b = c;
  d();
}
```

how is this different, if it's actually any different?


On Mon, Nov 12, 2018 at 2:23 PM T.J. Crowder <[hidden email]> wrote:
On Sat, Nov 10, 2018 at 5:49 PM Timothy Johnson
<[hidden email]> wrote:

It's **great** to see a proposal backed by an example implementation. :-)

I suggest adding some explanation to the proposal about how your example knows the `..d()` applies to `foo` and not to `c`. From the Dart documentation, I'd *guess* (not being a Dart person) that it's because you'd need parens around the `c..d()` to force it to apply to that instead, but... More about the specific mechanics of that as it applies to JS would be useful.

Probably also worth a one-liner that you're aware of and have allowed for how this relates to numeric literals (e.g., `console.log(12..toString())`). I can see in your commit on the Babel fork that you have allowed for it, but for those who don't dig that deep...

If this were in the language, I'd happily use it. I don't really feel the lack of it, though.

-- T.J. Crowder
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss