Discuss
  • Pick operator

Pick operator

# Bob Myers (9 years ago)

In the spirit of the discussion about language complexity and extensibility, consider the following brain-addled, pre-strawman proposal for a new pick operator.

rtm.github.io/boberator.html

I wonder if whatever macro-like facilities make their way into ES 20XX will be able to handle this. I suspect this is beyond the capabilities of sweet, but haven't really tried.

Bob

# Edwin Reynoso (9 years ago)

Wow Bob that's really neat. I really like it. Because it returns an object instead of assigning like destructuring. So it's very useful. So LGTM now as I kept reading I got a little confused, just give me a moment I will. But +1 for me. :)

# Tim Disney (9 years ago)

On Fri, Jun 19, 2015 at 9:30 PM, Bob Myers <rtm at gol.com> wrote:

I suspect this is beyond the capabilities of sweet, but haven't really tried.

I think it's doable with sweet. You need to use infix macros which are a bit more complicated than standard macros though.

Here's a first stab.

macro # {
    // let p #= o
    rule infix { let $prop | = $obj:expr } => {
        let $prop = $obj.$prop
    }
    // p = 42 # o
    rule infix { $prop = $val:expr | $obj:expr } => {
        ($obj.$prop || $val)
    }
    // [ p1, p2 ] # o
    rule infix { [ $prop (,) ... ] | $obj:expr } => {
        [ $($obj.$prop) (,) ...]
    }
    // { p1, p2 } # o
    rule infix { { $prop (,) ... } | $obj:expr } => {
        {
        $($prop : $obj.$prop) (,) ...
        }
    }
    // p # if o
    rule infix { $prop:ident | if $obj:expr } => {
        $obj && typeof $obj === "object" ? $obj.$prop : void 0
    }
    // q # (p # o)
    rule infix { $prop:ident | $obj:expr } => { $obj.$prop }
}

macro @ {
    // { p1, p2 } @ [1, 2]
    rule infix { { $props (,) ... } | [ $el:expr (,) ... ] } => {
        {
            $($props : $el) (,) ...
        }
    }
}

This dosn't handle { p1, p22 # p2 } # o but I think that totally possible to handle.

# Benjamin Gruenbaum (9 years ago)

Some comments:

{ p1 as x, p2 } # o // { x: o.p1, p2: o.p2 }

Not sure why the as syntax since we already have x : p1 syntax from destructuring.

p # if o

This is really complicated syntax, especially given if is not an expression.

{ a, b } @ [ 1, 2 ] // { a: 1, b: 2 }

A second operator seems even more overkill

propname* # o

Yet more syntax.

{ a, b } ##

And another operator.

All and all I'm strongly against adding so much syntax complexity to something like this, if the bind (::) proposal gets in you can do this sort of thing with a simple function and get as-nice syntax.

# Claude Pache (9 years ago)

The first issue (in chronological order) with that proposal is the lack of motivation. What is the problem that the proposal is trying to solve?

And since we are speaking of explosion of language complexity: It is good to try to solve the problem with existing syntax, in order to judge if the addition is worthwhile. But since we don't even know what the problem is, we can't even try.

(I understand that my remarks are not what the original message asked for. But I think it is important to underline that there are fundamental question that must arise before "Is it implementable (in sweet.js or whatever)?")

In the document it is said: "It also provides an elegant solution to the so-called existential operator problem." What is the problem and the solution? A concrete example would help. (Personally I’m particularly confused with that statement, because in situations where I want the existential operator, I certainly don’t want to invert the order of the key and the object.)

# Bergi (9 years ago)

Bob Myers schrieb:

In the spirit of the discussion about language complexity and extensibility, consider the following brain-addled, pre-strawman proposal for a new pick operator.

rtm.github.io/boberator.html

Thanks, some quite interesting ideas!

Some quick thoughts while reading:

  • o && typeof o === 'object' should just test for o != null. Or at least not ignore function objects.
  • that array picker operator should be omitted. Nobody needs this, picking from an array is very rare. Just use the standard # picker operator, onto an array literal, with explicit property names if need be.
  • Don't introduce a new syntax for computed properties, we have brackets already. That * looks to much like generator functions.

However, instead of introducing a new operator I'd rather like to extend destructuring and property shorthands to take more than single identifier. The basic examples from your motivation could easily handled by this, withoug looking much worse:

let pickedObj = {o.p1, o.p2}; // uses "p1" and "p2" for property names

{pickedObj.p3} = o; // takes "p3" as property name, assigns to LHS pickedObj.p3

Bergi

# Claude Pache (9 years ago)

Le 20 juin 2015 à 06:30, Bob Myers <rtm at gol.com> a écrit :

In the spirit of the discussion about language complexity and extensibility, consider the following brain-addled, pre-strawman proposal for a new pick operator.

rtm.github.io/boberator.html, rtm.github.io/boberator.html

I'm just wondering whether reversing the order of the object and their keys is a good choice. Contrary to destructuring assignment, there is no need to put a target at the left hand side of an assignment operator.

	o.{ p, q: r }   // { p: o.p, r: o.q }

Incidentally, it could help to keep strict left-to-right evaluation order (which is an issue for destructuring assignment, IIRC).