> I just find the syntax confusing

It combines two syntaxes we know and love: (1) dot notation `o.b` and (2)
deconstructing notation `{a} = o`, into `o.{a}`.

Maybe some have problems with the dot in `a.{o}` being too inconspicuous.
At the cost of using up a precious special character, we could go with `o #
{a}` instead. Actually I think `o pick {a}` is syntactically unambiguous.

> I do like the idea of building a way of taking a portion of an object out
of one object and into another

Good, many people seem to agree.

> Why couldn't this be an Object.pick()

Personally, passing around properties as strings grates on me. Then there's
the issue of typability, although Isiah has pointed out a useful TypeScript
proposal that does deal with that. Within the `_.pick` paradigm, it's hard
to envision a concise syntax for defaults and renaming, which the
deconstructing-like syntax gives us for free.

> It could even be expanded to handle deep nesting

Just curious, what sort of interface to your `_.pick`-like thing do you
have in mind>? Will it support defaults and renaming?

By the way, I was looking at Elm and found it supports one advanced feature
of extended dot notation, which is the unary dot as function, as in
`arr.map(.p)`.

Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160908/b4183691/attachment.html>

> I just find the syntax confusing

It combines two syntaxes we know and love: (1) dot notation `o.b` and (2)
deconstructing notation `{a} = o`, into `o.{a}`.

Maybe some have problems with the dot in `a.{o}` being too inconspicuous.
At the cost of using up a precious special character, we could go with `o #
{a}` instead. Actually I think `o pick {a}` is syntactically unambiguous.

> I do like the idea of building a way of taking a portion of an object out
of one object and into another

Good, many people seem to agree.

> Why couldn't this be an Object.pick()

Personally, passing around properties as strings grates on me. Then there's
the issue of typability, although Isiah has pointed out a useful TypeScript
proposal that does deal with that. Within the `_.pick` paradigm, it's hard
to envision a concise syntax for defaults and renaming, which the
deconstructing-like syntax gives us for free.

> It could even be expanded to handle deep nesting

Just curious, what sort of interface to your `_.pick`-like thing do you
have in mind? Will it support defaults and renaming?

By the way, I was looking at Elm and found it supports one advanced feature
of extended dot notation, which is the unary dot as function, as in
`arr.map(.p)`.

Bob

> I just find the syntax confusing

It combines two syntaxes we know and love: (1) dot notation `o.b` and (2)
deconstructing notation `{a} = o`, into `o.{a}`.

Maybe some have problems with the dot in `a.{o}` being too inconspicuous.
At the cost of using up a precious special character, we could go with `o #
{a}` instead. Actually I think `o pick {a}` is syntactically unambiguous.

> I do like the idea of building a way of taking a portion of an object out
of one object and into another

Good, many people seem to agree.

> Why couldn't this be an Object.pick()

Personally, passing around properties as strings grates on me. Then there's
the issue of typability, although Isiah has pointed out a useful TypeScript
proposal that does deal with that. Within the `_.pick` paradigm, it's hard
to envision a concise syntax for defaults and renaming, which the
deconstructing-like syntax gives us for free.

> It could even be expanded to handle deep nesting

Just curious, what sort of interface to your `_.pick`-like thing do you
have in mind>? Will it support defaults and renaming?

By the way, I was looking at Elm and found it supports one advanced feature
of extended dot notation, which is the unary dot as function, as in
`arr.map(.p)`.

Bob