Re: Proposal: Placeholder operator
On Fri, Jan 11, 2019 at 6:42 AM Sultan wrote:
> >empty space with a comma?
>
> I think that only works with trailing params. For example this is not
> possible:
>
> const foo = (a, , c) => {}
It doesn't even "work" with trailing params. Function arglists can
*contain* a trailing comma, it's just ignored and does nothing. `const
foo = (a, b, )=>a+b` still has a .length == 2, and `(a, b, ,)=>a+b` is
just invalid syntax. The trailing comma is just allowed so you can
format a long arglist onto separate lines, and don't have to remember
that the last argument doesn't have a comma.
> >Today, you can write: const foo = (a, b, _) => {}
>
> However that does throw with:
>
> const foo = (a, _, _) => {}
Yup, I've run into that problem before, and had to hack around by
using `_1` for the second ignored arg. It's rare/niche enough that I'm
not sure it's worth solving, but I do acknowledge it as an annoyance.
> >You can already write: const [ , setState] = useState(0)
>
> Thanks i forgot about that.
Yeah, using holes *works*, but it's definitely harder to read than using _.
And the fact that the last trailing , does *not* create a hole isn't
relevant for destructuring, but it would be relevant and confusing for
function-arity if we allowed holes in arglists. That is,
`[1,2,].length` returns 2 list, while `[1,2,,].length` returns 3. If
we get pattern-matching and array literals can do strict length
checking, it would also become relevant and confusing. (But that's
several stacked "if"s!)
~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: Placeholder operator
>empty space with a comma?
I think that only works with trailing params. For example this is not
possible:
const foo = (a, , c) => {}
>Today, you can write: const foo = (a, b, _) => {}
However that does throw with:
const foo = (a, _, _) => {}
>You can already write: const [ , setState] = useState(0)
Thanks i forgot about that.
On Fri, Jan 11, 2019 at 5:31 PM Claude Pache wrote:
>
>
> > Le 11 janv. 2019 à 14:02, Sultan a écrit :
> >
> > Placeholder operator: !
> >
> > Use in function parameters(maintains arity without creating a named
> binding):
> >
> > const foo = (a, b, !) => {}
>
> Today, you can write:
>
> ```js
> const foo = (a, b, _) => { }
> ```
>
> Is the complexity added to the language worth the feature?
>
> >
> > Use in de-structuring(allows you to capture further along a tuple
> without creating a named binding):
> >
> > const [!, setState] = useState(0)
>
> You can already write:
>
> ```js
> const [ , setState] = useState(0)
> ```
>
> —Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: Placeholder operator
> Le 11 janv. 2019 à 14:02, Sultan a écrit :
>
> Placeholder operator: !
>
> Use in function parameters(maintains arity without creating a named binding):
>
> const foo = (a, b, !) => {}
Today, you can write:
```js
const foo = (a, b, _) => { }
```
Is the complexity added to the language worth the feature?
>
> Use in de-structuring(allows you to capture further along a tuple without
> creating a named binding):
>
> const [!, setState] = useState(0)
You can already write:
```js
const [ , setState] = useState(0)
```
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal: Placeholder operator
Any reason you don't like the empty space with a comma? I also don't, but that's what it is now: ```js arr.map(( , index) => ...) ``` Also wouldn't mind ? or *, since I associate ! with "not" as a unary operator, but "*" isn't a unary in JS. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Proposal: Placeholder operator
Placeholder operator: !
Use in function parameters(maintains arity without creating a named
binding):
const foo = (a, b, !) => {}
Use in de-structuring(allows you to capture further along a tuple without
creating a named binding):
const [!, setState] = useState(0)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Syntax operator for "default assignment if value doesn't exits"
An operator syntax for the the "typeof" pattern used to detect if a
environment/object has a value:
if (typeof variable === 'undefined') {...}
if (typeof object.key === 'undefined') {...}
This could manifest in destructuring as the following
var fn = ({ key ||= 1 }) => {
}
And with variables as:
var global ||= {}
Equivalent code:
(arg) => {
if (typeof arg.key === 'undefined') {
arg.key = 1
}
}
if (typeof global === 'undefined') {
var global = {}
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Array.create and Function.create
You can already do that - `function f() {} Object.setPrototypeOf(f,
customObject)`
On Thu, Jan 10, 2019 at 4:18 PM Matthew Robb wrote:
> Fwiw I'd absolutely love a way to create function objects that inherit
> from an existing custom object.
>
> On Thu, Jan 10, 2019, 2:13 PM Sultan
>> >what're the benefits over a object indexed by numbers `const o =
>> Object.create(null); o[0] = 12; ...`?
>>
>> Better "optimisable" heuristics in a similar vain to `TypedArrays`. Most
>> engines have perf cliffs with indexed objects after a certain threshold,
>>
>> Memory: at some point indexed objects have to grow by some factor(* N of
>> the current size) until it reaches and exceeds your desired size resulting
>> in more memory use that you bargained for or at some point the engine could
>> downgrade it to dictionary-mode for any one reason.
>>
>> It is a fickle round to cross when you want predictable throughput
>> performance, TypedArrays afford this, but they are not generic(support any
>> value).
>>
>> >About the other function proposal (`Function.create`) I don't see any
>> benefits in day to day use having a function without prototype
>>
>> Both the Array.create and Function.create are not meant as day-to-day
>> data-structures.
>> They are meant as low-level building blocks for abstraction that might be
>> used on a day-to-day, abstractions that wish to guarantee better
>> predictable performance.
>>
>> >and there'd be no way to get the length or iterate over it if you did.
>>
>> You don't need a length property to iterate the array if you own and
>> manage the data-strucure:
>>
>> Exhibit A:
>> var len = 10
>> var arr = Array.create(null, len)
>> for (var i = 0; i < len; i++) arr[i]
>>
>> Exhibit B: (tuple)
>>
>> var arr = Array.create(null, 2)
>> arr[0] = 'a'
>> arr[1] = 'b'
>> return a
>>
>> In both examples you don't need a length property to access/visit all the
>> elements in the array given they are both statically known at creation time.
>>
>>
>> On Fri, Jan 11, 2019 at 12:20 AM Jordan Harband wrote:
>>
>>> Sorry if I was unclear; it's *impossible* to have an array without a
>>> `.length` own property, and there'd be no way to get the length or iterate
>>> over it if you did. I'm also not clear on why you'd want to store named
>>> properties on an array, especially if you can't iterate it because it
>>> doesn't have a length?
>>>
>>> On Thu, Jan 10, 2019 at 11:04 AM T.J. Crowder <
>>> tj.crow...@farsightsoftware.com> wrote:
>>>
On Thu, Jan 10, 2019 at 1:54 PM Augusto Moura
wrote:
>
> If you don't want the iterable features neither the own properties,
> what're the benefits over a object indexed by numbers `const o =
> Object.create(null); o[0] = 12; ...`?
Exactly.
And re functions, using them as state containers without their usual
features seems like a bad idea^H^H^H^H^H^H^H^H edge case best handled
by `setPrototypeOf` and `delete`. :-)
-- T.J. Crowder
___
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
