s
>
> // Create a `Reference` for `obj.x` and dereference it in `x`:
>
> let { ref x: ref x } = obj;
>
> // This is equivalent to the following:
> let ref x = ref obj.x; // Probably what you wanted
> ```
>
> However, this is less clear for shorthand destructuring assi
> How will you prevent the passing of the object down the pipe?
```js
const downThePipe = ({&source}) => {
// you can read source
source;
// you can set source
source = 'blah';
// you can't know where source comes from
// but you could propagate that reference further
evenFurtherDown
ted,
when you can pass it via `{&reactive}` to anything else, covering then the
`arguments` point too.
On Wed, Mar 3, 2021 at 6:44 PM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> > the proposal is just a debatable syntax sugar for something we already
> can do
>
> the proposal is just a debatable syntax sugar for something we already
can do
that's basically the entirety of the syntax sugar proposals since ES2015,
right? also proxy and globalThis are *really* unrelated to this, imho,
while leaking objects all over down the pipe is my major concern, somethi
wrong though
>
> Em ter., 2 de mar. de 2021 às 21:03, Claudia Meadows <
> cont...@isiahmeadows.com> escreveu:
>
>> I would like to see this happen, though I'd like to see it integrated
>> with reified refs. (I know there's a proposal laying around somewhe
Another one (cit. DJ Khaled)
has "by reference" ever been considered as "yet another JS syntax" ???
let object = {value: 1};
let {&value} = object;
value = 2;
object.value; // 2
allowed everywhere destructuring is possible, throwing for frozen
properties ... is this just meh? .. .'cause I think
Hello there 👋
this is going to be quick: how about using the bind operator *at least*
for destructuring?
```js
// today
function util(ref) {
if (ref.prop === 1)
ref.method(2);
}
// tomorrow?
function util({prop, ::method}) {
if (prop === 1)
method(2);
}
```
Such shortcut would simp
reference to function/context
> is lost.
>
> -- Původní e-mail --
> Od: Andrea Giammarchi
> Komu: es-discuss@mozilla.org
> Datum: 17. 9. 2020 21:03:45
> Předmět: Proposal: Function.prototype.bindContext
>
> I've found myself (once again) polluting the `Function.prot
I've found myself (once again) polluting the `Function.prototype` with a
lazy method that, once invoked, grants that the returned bound function is
always the same, per context.
# Use Case
It's still a common footgun to add events either via `context.method` or
via `context.method.bind(context)`,
Sorry, new link:
https://www.typescriptlang.org/docs/handbook/jsdoc-supported-types.html
On Mon, Aug 17, 2020 at 8:34 PM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> TS supports JSDocs already
>
> https://www.typescriptlang.org/docs/handbook/type-checking-javasc
TS supports JSDocs already
https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html#supported-jsdoc
On Mon, Aug 17, 2020 at 8:31 PM Bergi wrote:
> Hi,
>
> > They don't want to add TS to their stack.
>
> Then what else would they want to add to their stack? Notice one does
there is some fundamental misconception of the ECMAScript standard in these
examples ... to start with, assuming the same `arguments` object is passed
twice to two different invokes of a callback, would break down to ES3 and
lower.
Secondly, interpolated values you are passing around are always di
On a second thought ... couldn't `import.meta.cache`, or something similar,
be implemented in NodeJS only?
On Thu, Jul 16, 2020 at 3:44 PM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> FWIW explicit eviction is not only fine, if you own the code that does
> that, b
FWIW explicit eviction is not only fine, if you own the code that does
that, but the only way I can code cover 100% all the branches of my
libraries. The issue here is the untrusted Web, where I'd never expect any
3rd parts library to evict a module I am using within my code ... like ...
ever.
Acc
even if dereferenced, a dynamic import could re-reference it any time, and
I would expect it to still be the same module, it'd be a surprise otherwise
(cached things, same namespace checks, etc).
On Wed, Jul 1, 2020 at 7:33 AM Isiah Meadows
wrote:
> Just to expand on that, if the module record i
I think it doesn't matter where it lands, and I've overlooked at the
already available String.raw.
My idea is to have it "no matter where, or how named" as it's the
functionality I am after, not the name.
String.plain sounds great, but since template literals tag functions are
named "template lit
o have
`String.tag` doing exactly that.
Best Regards
On Mon, Jun 22, 2020 at 2:30 PM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> It doesn't work. There's been a lengthy discussion here
> https://github.com/mjbvz/vscode-lit-html/issues/14 and comments are not
> wrote:
>
>> What exactly are you proposing to do differently than String.raw?
>>
>>
>> https://developer.mozilla.org/en-US/docs/web/javascript/reference/global_objects/string/raw
>>
>> Sent from my phone
>> --
>> *From:* es-discuss o
Sent from my phone
> --
> *From:* es-discuss on behalf of Andrea
> Giammarchi
> *Sent:* Monday, June 22, 2020 12:24:13 PM
> *To:* es-discuss@mozilla.org
> *Subject:* A Function.tag proposal?
>
> This is something somehow bothering developers and tools, sooner or later,
> the n
This is something somehow bothering developers and tools, sooner or later,
the need for a no-op template literal tag function that just returns the
string as is.
The current workaround to have highlights, proper content minification,
etc, is the following one:
```js
import css from 'dummy-tag';i
Anyway, if anyone is interested, I've published the `assign-properties`
module [1]
[1] https://github.com/WebReflection/assign-properties#readme
On Thu, Feb 13, 2020 at 7:51 PM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> The fact `assign` doesn't copy descriptor
ation you want, just for 1 object
> instead of N.
>
> Object.assign was added because versions of it were all over the web, used
> very frequently. How frequent is the pattern where people want to copy
> descriptors, such that it would deserve reification in the language?
>
&
iptors(mixin)
),
{}
)
);
```
On Thu, Feb 13, 2020 at 6:51 PM Jordan Harband wrote:
> `Object.defineProperties(target,
> Object.getOwnPropertyDescriptors(source))`?
>
> On Thu, Feb 13, 2020 at 2:24 AM Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
&g
Both `Object.assign` and `{...extend}` suffer a tiny gotcha: properties are
never assigned, neither retrieved, as accessors, with side-effects too.
Example:
```js
const Counter = {
_count: 0,
get count() {
return this._count++;
}
};
const incr1 = Object.assign({}, Counter);
const incr2
a satisfactory
> argument for introducing the heavy feature you proposed. It could maybe be
> a conceivable argument for introducing `Array.createAsNonSparse(2)`.
>
> [Array.from]: https://tc39.es/ecma262/#sec-array.from
>
> —Claude
>
>
> Le 12 févr. 2020 à 10:23, Andrea
n Sun, Feb 9, 2020 at 11:08 PM Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> Unfortunately, `Array.from({ length: 4 }, () => whatever)` produces a
>> holey array, so that the `.repeat(...)` idea, if capable of packing
>> elements in a
So ...
On Tue, Feb 11, 2020 at 5:44 PM Isiah Meadows
wrote:
> You have proof of this? That it doesn't produce a dense array in engines?
>
Yes, I have d8 traces, after long discussions in twitter too, that shows
there's no way to have PACKED_SMI_ELEMENTS, but also a bug in Chromium from
2017, bu
aightforward.
>
>
>
> V8’s inability or unwillingness to perform a safe “upcast” internally to
> an appropriate tag doesn’t seem to provide enough weight to introduce a new
> construct.
>
>
>
>
>
> *From:* Andrea Giammarchi
> *Sent:* Monday, February 10, 2020 2:26
Great, now maybe you also read how it works behind the scene, and debug
properly to understand that every array is holey, including the latter one,
to date.
https://v8.dev/blog/elements-kinds
Please, let's assume for a second I knew what I was talking about, when
I've said it's a mess to not have
They couldn't even optimize the most obvious case of them all:
https://bugs.chromium.org/p/v8/issues/detail?id=6892
And "javascript is not the best tool for the job" makes no sense when it's
the most targeted transpiled language, but fair enough.
And yes, I've used SQLite wasm version too ... as
reation function would be just as effective as
>> a StructuredArray constructor.
>>
>> enforcing shapes during element deletions and updates are going to be hard
>> and likely just as confusing with StructuredArray as they are with
>> regular Array.
>>
>> a
> having to retroactively add checks like...
we already have typed arrays in JS so I don't think this would be any
different
> I _think_ that moderns virtual machines already did these optimisations
despite there isn't a TypedArray like that.
It's a bit of a mess to create an Array that is not h
Any name would do, I'm rather interested in the proposal itself, and its
ergonomics/logic ;-)
On Fri, Feb 7, 2020 at 10:11 PM Scott Rudiger
wrote:
> `StructuredArray` or `StructArray` for short? Just throwing it out there.
>
> On Fri, Feb 7, 2020, 1:08 PM Andrea Giammarchi <
memory; being able to
> pass an arbitrary value seems like it would require implementations to
> calculate the precise (not just the maximum) memory size a single item
> requires.
>
> On Fri, Feb 7, 2020 at 6:33 AM Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
As more and more often devs are shifting into TS, or would like to have
dynamic typed arrays without a fixed length, and as v8 and likely other
engines too optimize a lot for same-kind arrays, I wonder what people here
think about this `TypedArray` rough proposal:
# Signature:
```js
new TypedArra
am officially out of this
thread.
Best Regards.
On Mon, Oct 14, 2019 at 10:41 PM Tab Atkins Jr.
wrote:
> On Sat, Oct 12, 2019 at 7:19 AM Andrea Giammarchi
> wrote:
> > in order to work, `await` must be executed in an async scope/context
> (either top level or within a closure).
o the apparent confusion this proposal would add.
I hope I've explained properly what was this about.
Regards
On Fri, Oct 11, 2019 at 10:43 PM Tab Atkins Jr.
wrote:
> On Fri, Oct 11, 2019 at 1:15 AM Andrea Giammarchi
> wrote:
> > Again, the `await?` is sugar for the following:
to each others things we know already.
Best Regards
On Fri, Oct 11, 2019 at 1:32 AM Tab Atkins Jr. wrote:
> On Wed, Oct 9, 2019 at 11:17 PM Andrea Giammarchi
> wrote:
> > > What's the order of the logs?
> >
> > Exactly the same, as the `await?` is inevitably i
ing like that by default, while it seems to
unconditionally create micro tasks even when it's not strictly necessary.
On Wed, Oct 9, 2019 at 11:47 PM Tab Atkins Jr. wrote:
> On Wed, Oct 9, 2019 at 12:08 AM Andrea Giammarchi
> wrote:
> > I don't know why this went in a com
I don't know why this went in a completely unrelated direction so ... I'll
try to explain again what is `await?` about.
My first two examples show a relevant performance difference between the
async code and the sync one.
The async code though, has zero reasons to be async and so much slower.
``
When developers use `async` functions, they'll likely also await
unconditionally any callback, even if such callback could return a non
promise value, for whatever reason.
Engines are great at optimizing stuff, but as of today, if we measure the
performance difference between this code:
```js
(as
produces a buggy "rowsCount". It can only ever
> be 0. However, another developer may be tempted to say `else if(rowsCount >
> 1)` not realizing that it's undefined if there are actually any rows. This
> is what I mean by confusing & bug prone results of the pattern.
t is a confusing behaviour, if not bug prone
>
> On Mon, 9 Sep 2019, 09:17 Andrea Giammarchi,
> wrote:
>
>> so *maybe* we'll come back...
>>
>> On Mon, Sep 9, 2019 at 10:04 AM Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>
so *maybe* we'll come back...
On Mon, Sep 9, 2019 at 10:04 AM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> `require("module") initially explained.
>
> `db.get(SQL) that won't fail but might not return the desired result, so that you end up
> ho
> about what you would typically want to do with the "foo()" if that was the
> returned result.
>
> On Sat, 7 Sep 2019 at 12:08, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> Interesting I forgot about that, but it wouldn't cover the "tra
nary' operator (or
> whatever I called it) I suggested a couple of years ago. I believe you were
> involved in the discussion, Andrea...!
>
> ```
> const val = foo() ?!
> (x) => x.bar.baz :
> someFallbackValue;
> ```
>
> On Sat, 7 Sep 2019, 10:17 Andrea
cause the latest one might result into `foo().bar`.
Moreover, in both cases you'll end up multiplying the payload at least * 2,
while the mouse trap will work like this:
```js
foo() wrote:
> On Fri, Sep 6, 2019 at 8:04 AM Andrea Giammarchi
> wrote:
> > Indeed I'm not super c
er; but the specific syntax can be bikeshedded separately)
>
> On Fri, Sep 6, 2019 at 8:04 AM Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> Indeed I'm not super convinced myself about the "branching issue" 'cause
>> `const result = th
Indeed I'm not super convinced myself about the "branching issue" 'cause
`const result = this?.is?.branching?.already` and all I am proposing is to
hint the syntax where to stop in case something else fails down the line,
as in `const result = this.?.is wrote:
> Typically, "dot" expressions naviga
t language constructs
> should encourage that type of programming and discourage type branching
> (and other patterns that risk having a lack of logical clarity).
>
> Just my opinion, as I said. Disagreements welcome.
>
> On Fri, 6 Sep 2019 at 08:59, Andrea Giammarchi <
> an
logical flow. These things, in my mind, would lead
> to more bugs. Hence I would tend to be against introducing it, especially
> in light of other proposals that I find more useful that haven't been taken
> even to discussion.
>
> On Fri, 6 Sep 2019, 07:58 Claude Pache, wrote:
As someone noticed already, the operator should be called eventually
"mouse" operator, as mice is plural and was a misunderstand of mine 😅
On Fri, Sep 6, 2019, 00:54 Andrea Giammarchi
wrote:
> Since somebody asked me already elsewhere about the expected precedence of
> the oper
sefield <
> rosyatran...@gmail.com> wrote:
>
>> Another pattern it could be useful in is with, say, nosql dbs where
>> something might be an object or id reference:
>>
>> ```
>> const fooId = foo> ```
>>
>> On Thu, 5 Sep 2019, 23:03 Andrea
d = foo ```
>
> On Thu, 5 Sep 2019, 23:03 Andrea Giammarchi,
> wrote:
>
>> Another use case that I believe will be common is the following one:
>>
>> ```js
>> // current state of the art
>> const result = dbQuery(data)?.rows ?? 'did it just failed or
Another use case that I believe will be common is the following one:
```js
// current state of the art
const result = dbQuery(data)?.rows ?? 'did it just failed or what?';
// VS the "mice operator"
const result = dbQuery(data) wrote:
> On Thu, Sep 5, 2019 at 2:39 PM And
This is basically a solution to a common problem we have these days, where
modules published in the wild might have a `default` property, to support
ESM logic, or not.
```js
// current optional chaining logic
const imported = exported?.default ?? exported;
// my "mice operator" proposal
const imp
> "joinWith".
>
> On Mon, 19 Aug 2019 at 09:56, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> A lot of libraries flatten template tags for a reason or another. The JSX
>> oriented `htm` project [1], as example, does that to obtain a sing
more on how this is a *common* case in the wider
> ecosystem?
>
> On Fri, Aug 16, 2019 at 5:29 AM Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> early reply "which otehr cases"? this is just an example:
>>
>> [2019, 08, 16, 14,
early reply "which otehr cases"? this is just an example:
[2019, 08, 16, 14, 28, 30].map(i => i < 10 ? ('0' + i) :
i).joinWith('--T::.');
On Fri, Aug 16, 2019 at 2:24 PM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> `this ${Symbol(
string, so I'm not sure what
> else is happening with your proposed method? Clearly I've missed something.
>
> Apart from that, how would you handle arrays that whose values are not all
> strings?
>
> For naming is still think "weave" would be OK fro
> I'm just not seeing what it's supposed to do. If you could give a brief
> explanation of the array method, and the string method then of course I
> would get it. I know it would seem obvious to you from the examples alone,
> it's just not to me.
>
> On Fri,
eared. I've since recreated it:
>
> https://github.com/isiahmeadows/es-stdlib-proposals/blob/master/proposals/array/interleave.md
>
> -----
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
>
>
> On Thu, Aug 15, 2019 at 1:12 PM Andrea Giammarchi
&
isn't the second argument already reserved for the context?
```js
[1, 2, 3].findIndex(function (i) { return i == this; }, 2);
// 1
```
On Thu, Aug 15, 2019 at 11:51 PM Cyril Auburtin
wrote:
> It should be possible to add a second optional argument to the `find` and
> `findIndex` array methods,
function tag2str(template, ...values) {
return template.joinWith(values);
}
tag2str`a${1}b${2}c`;
// "a1b2c"
```
On Thu, Aug 15, 2019 at 7:39 PM Naveen Chawla wrote:
> "weave"? (I've likely missed the purpose of the method)
>
> On Thu, 15 Aug 2019, 18:12 A
Fair points, but since `**` has its `Math.pow` counter part, why wouldn't
`%%` have `Math.mod` as counterpart too? At least it looks like there's
room for both, if standardized, as the behavior and description would
likely be mostly the same (precedence a part)
On Thu, Aug 15, 2019 at 7:13 PM Isia
0 PM Michał Wadas wrote:
> https://lodash.com/docs/#zip
> https://docs.python.org/3/library/functions.html#zip
>
> On Thu, 15 Aug 2019, 15:34 Andrea Giammarchi,
> wrote:
>
>>
>>1. the suggested name is just ... suggested, I don't have strong
>>opinion on
tcome adding new syntax anyway ... the smoosh accident, is the equivalent
of custom Babel utilities these days.
Look at TypeScript and the private class fields, if you want to compare new
syntax instead
On Thu, Aug 15, 2019 at 4:50 PM Michael Haufe
wrote:
> Thursday, August 15, 2019 2:47 AM
se.
>
> On Thu, 15 Aug 2019, 10:50 Andrea Giammarchi,
> wrote:
>
>>
>> I wonder if there's any interest in adding another handy Array method as
>> joinWith could be:
>>
>> ```js
>> // proposal example
>> Array.prototype.joinWith = funct
I wonder if there's any interest in adding another handy Array method as
joinWith could be:
```js
// proposal example
Array.prototype.joinWith = function (values) {
const {length} = this;
if (length < 2)
return this.join('');
const out = [this[0]];
const len = values.length;
for (let
FWIW another disadvantage is that operators cannot be polyfilled, so it'll
take forever for those not using transpilers to adopt these, while having a
`Math,mod` would work right away
On Thu, Aug 15, 2019 at 8:40 AM Claude Pache wrote:
>
>
> Le 12 août 2019 à 22:00, Matthew Morgan a écrit :
>
>
ith WASM around, any programming language can target the
Web, so you want this proposal to land in WHATWG, not here).
Regards
On Thu, May 23, 2019 at 7:15 PM Randy Buchholz
wrote:
> @Andrea Giammarchi , While the connection is
> secondary, HTML often serves as the specification for the
it's meant there couldn't be two indexes with the same value, but even IDs
can be duplicated on a page (it's not suggested or anything, but nothing
prevents you to do that)
to be honest, since IDs already cover the whole story (IDs are accessible
even via globalThis/window, no need to query the do
live *
On Wed, May 22, 2019 at 7:25 PM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> With Custom Elements you have `attributeChangedCallback` which reacts
> after `observedAttributes` returned attributes, and I believe you'd like to
> use that to create getters an
With Custom Elements you have `attributeChangedCallback` which reacts after
`observedAttributes` returned attributes, and I believe you'd like to use
that to create getters and setters out of the box.
I don't think DOM specific class fields/syntax will ever land in JS itself,
but I can suggest you
People use JSX, which is basically E4X, so I'd argue the word useless is
not really appropriate. You can use E4X to produce HTML, the fact we're
talking XML is merely about the E4X background, but as you could produce
strings out of E4X you could do the same and have better templating out of
the bo
That'd give you info after declaration, which I believe was the major
concern in using strings instead of literals.
FWIW, I also wish E4X was still a thing, despite these handy and successful
template literals based libraries (hyperHTML, lighterhtml, or heresy for
the client, viperHTML for NodeJS)
egistering APIs and custom elements inside
>>> them, adding the `window` object to a WeakSet so the initialisation only
>>> ran once.
>>>
>>> On Tue, 23 Apr 2019 at 10:26, Andrea Giammarchi <
>>> andrea.giammar...@gmail.com> wrote:
>>>
&g
WeakSet can be very useful in general to avoid *any* object to be
visited/setup twice, not just those coming from user-land classes.
Circular references, mixins, DOM nodes one-off events handling, and so on
and so fort.
On Mon, Apr 22, 2019 at 8:26 PM #!/JoePea wrote:
> (I edited the broken for
That solves half of the problem. What of the other half (`Type v =
> "somevalue";` where `Type` is not a static class)? With your approach, that
> would need to be restricted to solve the other half. Otherwise, you'd still
> be facing the issues Waldemar spoke about.
&g
If something is missing, let's move forward finding out solutions, 'cause
if we base any assumption only to the current highly dynamic nature of JS
we won't go too far.
As example, I think the mutable prototype issue can be solved through
static classes where no changes would be possible and all i
#x27;s very hard to write / remember for humans, IMO.
I also would like to know the opinion of someone close to V8 or other
engines.
Regards
On Tue, Mar 26, 2019 at 10:03 AM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> jsdoc doesn't exist in production so it
jsdoc doesn't exist in production so it cannot provide any info to the
runtime, making WASM interoperability and hot code optimizations impossible.
Let's please keep the discussion focused on the achievements current JS
cannot possibly have, thanks.
On Tue, Mar 26, 2019 at 9:06 AM Dan Peddle w
* trough (gz)
On Mon, Mar 25, 2019 at 11:41 AM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> > WASM interoperability and optimiser efficiency instead of developer
> productivity.
>
> I've personally always seen types useful **only** for typed langua
> WASM interoperability and optimiser efficiency instead of developer
productivity.
I've personally always seen types useful **only** for typed languages
interoperability and/or optimization/performance hints to engines/runtimes,
but since many developers apparently experience some productivity bo
the day I'll disable autocorrect everywhere will be always too late ...
transpolar => transpilers
trample => transpile
On Mon, Mar 25, 2019 at 10:13 AM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> I am having hard time understanding the counter argument &quo
I am having hard time understanding the counter argument "you need a
transpolar anyway".
That's been the case since ES2015 landed with breaking syntax that has been
required mandatory transpilation to keep it backward compatible, with
things also not really transpilble such as classes with built-i
Just my personal thoughts on this.
The way PHP migrated to types has been thought incremental steps, and it
worked pretty well.
Since types have been demanded by the JS community for a while, I think
it'd be key to approach JS types not all at once, but through smaller
iterations.
As example, a
honestly this look like an `or` would've been great as reserved
try import fs from 'fs'
or import fs from 'fs-polyfill'
or import fs from 'another-fs-polyfill'
catch optional, and triggered only if previous 3 imports failed
finally optionally do something;
On Fri, Mar 1, 2019 at 12:05 PM Mich
> 1. If `value` is either `null` or `undefined`, it gracefully falls back
to `false` instead of throwing an error.
I am having hard time logically thinking of an empty void as false:
Object.isEmpty(void 0) is false ?
I think keys(o || {}).length === 0 is a more explicit, ambiguity free,
alternat
nse 👋
On Mon, Jan 14, 2019 at 4:49 PM Boris Zbarsky wrote:
> On 1/14/19 9:47 AM, Andrea Giammarchi wrote:
> > rather because of the bloat it produces once transpiled:
>
> Hold on.
>
> The transpiling is necessary because of lack of what features in
> implementations?
>
It's not so easy to implement in user land, not because it's difficult to
do so:
```js
Function.prototype.bindArgs = (...args) => {
const fn = this;
return function (...moar) {
return fn.apply(this, args.concat(moar));
};
};
```
rather because of the bloat it produces once transpiled:
h
I dare saying tags are another issue here, 'cause "abc" === "abc", and with
an identity function such `const id = o => o`, `id("abc") === id("abc")`
but due latest changes to template literals, id`abc` !== id`abc` so it's
easily misleading in the tagged case.
On Wed, Jan 9, 2019 at 7:53 PM Jordan
[time to write specs, pass through the whole process, ship it to all
engines, have it 100% usable without polyfills]
[value of this proposal]
both sentences represents time, -1 here
On Mon, Jan 7, 2019 at 8:35 PM Ranando King wrote:
> Either way it goes, there's a lot of ways to do this that a
FWIW, I've used same logic for something like a no-op for i18n`strings` [1]
so, considering it has easily use cases with mapped interpolations too, I
think it's more than natural to have that in core.
It's also backward compatible/polyfillable so this is kinda a no-brainer,
name a part, of course.
I agree with Mark, and I wonder why `String.tag` is not the obvious choice
here, since every interpolation is also coerced as String
On Thu, Dec 13, 2018 at 9:34 AM Isiah Meadows
wrote:
> I mean equivalence to untagged behavior, if that helps.
>
> FWIW, as stated previously, I'm not married to t
7;s still callable, but I can tack other properties to it
>> easily. Something like this, maybe:
>>
>> ```js
>> {
>> (...args) { ... },
>> }
>> ```
>>
>> In this, the `this` value is set to the callee itself, not the given
>> `this` v
> the apply hook needs objects anyway.
I meant functions
On Wed, Dec 5, 2018 at 1:33 PM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> I've actually replied to the op, I didn't mean to answer you directly, but
> the only reason I wrote that is because
e easily handled via objects and functions? (looking for use
> cases here)
> How does this make coding easier to do and understand? (for the AST parser
> and for the human)
>
> On Tue, Dec 4, 2018 at 11:54 PM Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>
How about this:
```js
// the poly
if (!Symbol.callable)
Symbol.callable = Symbol('callable');
// the setup
class Callable extends Function {
constructor(object) {
super('return arguments.callee[Symbol.callable](...arguments)');
//sloppy mode FTW!
Object.setPrototypeOf
gards
On Wed, Dec 5, 2018 at 7:44 AM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> It's well known that twitter users pay a lot of attention to details, vote
> only once they've understood the issue and their own opinions about
> technical matters, and follow clos
1 - 100 of 1636 matches
Mail list logo
