Or maybe it would be
```js
theFunction(obj., obj.);
```
to explicitly pass the particular properties, and would account for
nested properties too:
```js
theFunction(obj.foo., obj.lorem.);
```
#!/JoePea
On Wed, Mar 3, 2021 at 6:29 PM #!/JoePea wrote:
>
> I think it is a good idea, but
allow the function to destructure, and only destructure, by
reference of those given properties, for example. Then the contract
can not silently change from secure to insecure.
#!/JoePea
On Wed, Mar 3, 2021 at 9:47 AM Andrea Giammarchi
wrote:
>
> to expand further: you *could*
lar) would surely create a
single object.
#!/JoePea
On Sun, Oct 18, 2020 at 10:19 AM Jordan Harband wrote:
>
> `new Set(Object.keys(obj))` seems pretty straightforward - I doubt it's worth
> adding something to the language just to make that shorter.
>
> Separately, if you're looking
re closed source.
Seems that even http://jspm.dev is closed source.
Looks like at this point in time people are aiming to make money from
ESM servers, and there's no viable open source ESM server solution.
#!/JoePea
On Sun, Oct 18, 2020 at 8:50 AM Randy Buchholz wrote:
>
> Right, it's basic
I think it's a good idea that would make things more efficient. +1
*#!/*JoePea
On Thu, Sep 17, 2020 at 12:57 PM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> I'm not sure I'm following, but I'm not here to find solutions, I already
> have solutions, I'm here to p
een lodade by its identifier,
can we? So we have to make the request, because that's the only way to
check.
#!/JoePea
On Sat, Oct 17, 2020 at 1:28 PM Randy Buchholz wrote:
>
> I think some form of bundling will always be necessary. I use classes and
> took a name-spaced and typed
That would be interesting indeed. Encouraging documentation is great I think.
#!/JoePea
On Sat, Oct 17, 2020 at 3:38 AM Michaël Rouges wrote:
>
> Yeah, I prefer the JSDoc solution too for the same reasons... but JSDoc is
> really slow to evolve,
> always several years behind the sta
Well that makes sense! Would it be worth adding an option like
`Object.keys(obj, true)` to return a set? Or perhaps
`Object.keySet(obj)`?
#!/JoePea
On Fri, Oct 16, 2020 at 11:54 PM Jordan Harband wrote:
>
> Because Object.keys was standardized in 2009, 6 years before Set existed.
>
>
es-dev-server by open-wc seems to be import-aware.
https://open-wc.org/developing/es-dev-server.html
#!/JoePea
On Fri, Oct 16, 2020 at 6:40 PM #!/JoePea wrote:
>
> So in practice, bundling is still a thing because there isn't an
> import-aware server that has been released th
Sets are faster, even for tiny lists of four items. See the perf tests
(tested in Chrome):
https://twitter.com/trusktr/status/1315848017535098880
https://twitter.com/trusktr/status/1317281652540731392
#!/JoePea
___
es-discuss mailing list
es-discuss
So in practice, bundling is still a thing because there isn't an
import-aware server that has been released that proves to be better
than bundling? Or perhaps it's too much overhead to set up a server,
so people just bundle?
#!/JoePea
On Wed, Oct 14, 2020 at 2:45 PM Randy Buchholz wrote
also without build tools).
However, JSDoc can not currently do everything that regular TypeScript
syntax can do (there's some open issues regarding that in the
TypeScript repo).
#!/JoePea
On Wed, Oct 14, 2020 at 11:53 AM kai zhu wrote:
>
> > Sorry but my question isn't about providi
I introduce a single private field within my class.
#!/JoePea
On Mon, Jul 27, 2020 at 3:33 PM Jordan Harband wrote:
>
> oh oops, i meant `if (o !== this)` not `if (o.foo !== this)` :-)
>
> On Mon, Jul 27, 2020 at 3:06 PM #!/JoePea wrote:
>>
>> > `o.foo(); // works
being in play would be neat too!
#!/JoePea
On Sun, Aug 9, 2020 at 7:55 PM Michael Theriot
wrote:
>
> Why stop at class definitions?
>
> e.g.
> ```js
> let obj;
> {
> let local = 0;
> obj = {
> get local() {
> return local;
> }
> }
&g
Why not? People are generating less docs now? That doesn't sound good!
#!/JoePea
On Mon, Aug 17, 2020 at 4:15 PM Isiah Meadows wrote:
>
> JSDoc is not dead (far from it), people just don't frequently use
> automated docs generation tooling in the JS community. Most the actual
&g
Right, exactly. So naively sending all dependencies wastefully is just
the first step.
> Afaik the more promising path are prefetch hints on the client. E.g. the
client (or initial HTML payload) knows the dependency tree, adds tags
for preloading the required modules, and then the browser can
I'm asking about a server that, upon request of a `.js` file, knows
how to enumerate the dependency tree based on that file, _then_ HTTP
pushes all the modules at once.
So basically, from the code
```html
-analyzable)
imports should appear only within `async` functions (so they operate
the same as `await import()`).
Is there something bad about the idea that isn't described in those writings?
#!/JoePea
___
es-discuss mailing list
es-discuss@mozilla.org
https
be attractive to those people who
normally publish static sites and need to publish ES Modules as static
resources somewhere without the fuss if managing a server.
#!/JoePea
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es
of pasting my identity tag everywhere.
#!/JoePea
On Thu, Sep 24, 2020 at 2:25 PM #!/JoePea wrote:
>
> I mean, it would be only a parse time cost if the identity tag is used like
>
> ```js
> String.tag`...anything...`
> ```
>
> assuming it is not monkey-patchab
I mean, it would be only a parse time cost if the identity tag is used like
```js
String.tag`...anything...`
```
assuming it is not monkey-patchable (readonly). But maybe if it is
patchable then all bets are off, and it has a runtime cost.
#!/JoePea
On Thu, Sep 24, 2020 at 2:22 PM #!/JoePea
Perhaps a built-in identity tag would be only a parse-time performance cost.
#!/JoePea
On Thu, Sep 24, 2020 at 2:21 PM #!/JoePea wrote:
>
> I don't know what you mean about the raw stuff, but using `/*css*/`
> works perfectly fine in VS Code with a plugin. There's no reason
> intell
right. Missing auto-completion inside the
little comment isn't that bad.
I prefer using the comment because using an identity tag just for
syntax feels like I'm adding a performance cost for no reason related
to my runtime code.
But perhaps a built-in identity tag would be fast.
#!/JoePea
On Mon
ies with WeakMap-ish semantics.
#!/JoePea
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
> `o.foo(); // works`
I think there is something missing from that example as that line
throws before it can get to the `new Proxy` line.
#!/JoePea
On Wed, Jul 15, 2020 at 10:47 PM Jordan Harband wrote:
>
> So can:
> ```jsx
> const o = { foo() { if (o.foo !== this) {
nce in some way?
#!/JoePea
On Sun, Jul 26, 2020 at 11:33 AM Andrea Giammarchi
wrote:
>
> 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 callba
(argsArrays[0] === argsArrays[1]) // false!
```
So yeah, just wondering why our only option is to use `...args` and
create new arrays each time, thus the performance is not optimized
like it is with the string parts.
#!/JoePea
On Sun, Jul 26, 2020 at 10:49 AM #!/JoePea wrote:
>
> What
ike it would've been great to have the cached values arrays
too. Why isn't this the case?
#!/JoePea
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
There's a good number of upvotes for it. It would be nice.
#!/JoePea
On Thu, Apr 30, 2020 at 1:13 PM Jordan Harband wrote:
>
> See https://github.com/tc39/proposal-optional-chaining/issues/18
>
> On Thu, Apr 30, 2020 at 1:08 PM #!/JoePea wrote:
>>
>> I was hop
that
only ever allocates memory that will never be freed.
Is someone working on a solution for this?
#!/JoePea
On Wed, Jul 1, 2020 at 6:16 AM Mark S. Miller wrote:
>
> No, definitely not. The table from specifiers to module instances is indexed
> by specifiers. Specifiers are st
licate
frames in the stack, so a loop would result in only one unique set of
entries in the stack trace and not repeat.
#!/JoePea
On Sun, Jul 12, 2020 at 11:53 AM Jacob Bloom wrote:
>
> Reading through the issue JoePea linked to, it looks like the difficulties
> with standardized asy
> private members (safely) allow classes with internal slots.
I'd say that they aren't safe, if they can break 3rd-party code on the
external public side.
#!/JoePea
On Sun, Jul 12, 2020 at 3:09 PM Michael Theriot
wrote:
>
> I assume OP wants to use proxies and private members
then give it to external code, or if you tell all your
users to make sure they write proxy membranes for all your methods
(ouch!).
A true solution would leave all existing code working as-is, and would
never break if internal code introduced a private field.
#!/JoePea
On Sun, Jul 12, 2020 at 3:17 P
Error
at globalThis.fetch (pen.js:5)
at three (pen.js:27)
```
Live example:
https://codepen.io/trusktr/pen/b8fd92752b4671268f516ad3804869e4?editors=1010
I opened a request for this over here:
https://github.com/tc39/proposal-error-stacks/issues/34
#!/JoePea
On Fri, Jul 10, 2020 at 1:21
to
detect traces in third-party code installed locally).
#!/JoePea
On Wed, Jul 8, 2020, 2:13 AM kai zhu wrote:
> here's a simple throwaway-function you can wrap around promises like fetch
> to get the caller's async-stack-trace `promiseWithErrorStack`:
>
> ```html
>
>
>
&g
. As a specific example, I'd
like to detect the async stack trace of any call to `fetch`.
Is such a thing possible with runtime code?
Or would it require instrumentation of the source code?
#!/JoePea
___
es-discuss mailing list
es-discuss@mozilla.org
https
(because farming for resources is disabled if the app is not running,
or something).
I would imagine that we want unused modules (when we leave a planet,
for example) to be (destroyed) garbage collected so that we don't
waste memory.
#!/JoePea
___
es
steps to have a
clean way of doing it.
#!/JoePea
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I was hoping to avoid things like
```js
const baz = this.foo?.bar?.baz
if (baz) baz.lorem = 123
```
#!/JoePea
On Thu, Apr 30, 2020 at 1:04 PM #!/JoePea wrote:
>
> This is perfectly fine:
>
> ```js
> this.foo?.bar?.setBaz(123)
> ```
>
> but this is not:
>
> ``
and
awesomely inserts the `?` characters, only to fail once I write the
assignment part.
#!/JoePea
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
being equivalent
to "window". (I know it is wrong, but that's what many people think while
not knowing about window proxies).
On Thu, Nov 21, 2019 at 2:37 PM Boris Zbarsky wrote:
> On 11/21/19 5:21 PM, #!/JoePea wrote:
> >> They were duly marked invalid, because the problem was wit
I forgot to add, this even works with builtin scenarios like Custom
Elements,
```js
class MyEl extends mix(HTMLButtonElement, One, Two, Three) { /* ... */ }
customElements.define('my-el', MyEl)
```
On Fri, Nov 22, 2019 at 9:36 AM #!/JoePea wrote:
> HI Cyril, thanks for pointing that out
g.ts#L10
>
> On Fri, Nov 22, 2019 at 4:23 AM #!/JoePea wrote:
>
>> After messing with Proxy-on-prototypes for two days, I've just come to
>> the conclusion that I probably need to have Proxies on this (the
>> receiver) returned from constructors to achieve what I want. A
inheritance-related traps. That might make some things
easier.
On Thu, Nov 21, 2019 at 2:55 PM #!/JoePea wrote:
>
> I really thing that because `has` is about detecting inherited
> properties, the `receiver` parameter should be included. For things
> like `ownKeys`, which are not about
Any idea why it isn't spamming the console? I mean, if it is
recursive, shouldn't it fire my console.logs over and over, like
50,000 times, before finally throwing the error?
On Thu, Nov 21, 2019 at 3:12 PM Alex Vincent wrote:
>
> I'm afraid your testcase is still far too complicated to really
I really thing that because `has` is about detecting inherited
properties, the `receiver` parameter should be included. For things
like `ownKeys`, which are not about inheritance, then yeah, let's not
add receiver there.
I'm trying to implement my own multiple inheritance, but now I
stumbled on
I should stop asking questions about something that is highly-unlikely
to change! I can live with it. :) Thanks anyways for the insights. -
Joe
On Thu, Nov 21, 2019 at 2:21 PM #!/JoePea wrote:
>
> > They were duly marked invalid, because the problem was with the
> &g
ty didn't match what was intuitive. I'd say it is a DX flaw.
Honestly though, I don't know what a fix would be.
I'm not sure I even know what "globalThis" means now. :)
On Sun, Nov 17, 2019 at 11:52 AM Boris Zbarsky wrote:
>
> On 11/16/19 12:52 PM, #!/JoePea wrote:
> > Th
Sorry you all, I realized I should've simplified it. Here's a [simpler
fiddle](https://jsfiddle.net/trusktr/tf6hdn48/6/).
On Thu, Nov 21, 2019 at 1:17 PM #!/JoePea wrote:
>
> I was trying to implement "multiple inheritance" in the following code
> ([jsfiddle](https://j
I was trying to implement "multiple inheritance" in the following code
([jsfiddle](https://jsfiddle.net/trusktr/tf6hdn48/)), but it gives a
max call stack (infinite recursion) error.
However, the infinite recursion does not execute any of my console.log
statements repeatedly like I'd expect, so
This is indeed an ugly problem that I've faced when making Custom
Elements. The problem is: in templates, custom elements do not get
"upgraded" into their identity. They only get "upgraded" once they are
inserted into the live DOM.
The best you can do is make deferred code in your custom element
I haven't read the whole thread, but I also disliked the ugly
conditional checking I had to do to get faster results.
I agree that this would changed perceived code execution order
(unexpectedly, a breaking change).
I believe that a better solution would be to make it explicit in the
function
who know enough not to be
confused, or the very few people hitting a browser bug that should in
all honesty be patched in effort to make things easy for end
developers.
All the best,
- Joe
On Mon, Oct 7, 2019 at 1:11 PM Boris Zbarsky wrote:
>
> On 10/7/19 1:56 PM, #!/JoePea wrote:
> &
Any one have any thoughts on this?
On Fri, Oct 4, 2019 at 11:54 AM #!/JoePea wrote:
>
> Currently we can implement things like "reactive variables" and
> "reactive computations". Contrived example:
>
> ```js
> import {rv, computation} from './rea
Fri, Oct 4, 2019 at 12:33 PM Boris Zbarsky wrote:
>
> On 10/4/19 2:39 PM, #!/JoePea wrote:
> >> but the global `this` you captured still has the same identity as the new
> >> reference.
> >
> > Interesting, I never knew that. Do you have a code sample to
I didn't see it. For some reason my gmail thread split into two
separate threads, and I read one before the other.
On Mon, Oct 7, 2019 at 7:14 AM Boris Zbarsky wrote:
>
> On 10/7/19 1:29 AM, #!/JoePea wrote:
> > I've never written any sort of code that can prove or verify any of
>
Ah, this thread got forked from the other one, which has a code
sample. Taking a look at that...
On Sun, Oct 6, 2019 at 10:29 PM #!/JoePea wrote:
>
> I never knew any of all that stuff you have all mentioned, and as an
> end user, I don't think I would ever need to know. To me, I use
I never knew any of all that stuff you have all mentioned, and as an
end user, I don't think I would ever need to know. To me, I use
`window` as a global object, and it has never been more than that.
I've never written any sort of code that can prove or verify any of
what you all are talking
Currently we can implement things like "reactive variables" and
"reactive computations". Contrived example:
```js
import {rv, computation} from './reactive-variable'
const count = rv(0)
// read the value
console.log(count()) // 0
// set the value
count(1)
console.log(count()) // 1
//
s misuse "entries" as if it were synonymous with "pairs".
> Contrast this with Underscore's `_.pairs`, named by a native English speaker
> back in 2012, long before ES6 was a thing, and it stood as precedent for
> having `coll.entries()` for various collections.
>
&
I know it may be too late for this, but I imagine `globalThis` can bring
confusion to beginners, especially ESL beginners.
Things like `globalObject`, `systemGlobal`, or `globalEntity` would've been
more intuitive; they make sense in plain English.
Well anyways, have a good weekend!
- Joe
I feel like I'm going crazy, but I have a class hierarchy, and one of
the constructors in the hierarchy defers some logic to a microtask,
```js
// class Foo
constructor() {
Promise.resolve().then(() => {
this.methodThatSubclassOverrides()
})
}
methodThatSubclassOverrides() {}
```
and in
(I edited the broken format of my previous post)
What other use cases are there?
On Mon, Apr 22, 2019 at 11:20 AM #!/JoePea wrote:
> > WeakSets are perfect for branding and are how I would expect web
> platform class branding to be explained.
> >
> > ```js
> &g
> WeakSets are perfect for branding and are how I would expect web platform
class branding to be explained.
>
> ```js
> const foos = new WeakSet();
>
> class Foo {
> constructor() {
> foos.add(this);
> }
>
> method() {
> if (!foos.has(this)) {
> throw new
I many times find myself in cases where a base class wants to ensure that
logic is always fired after the current method's execution, so that for
example no matter in which order sub classes call the `super` method, the
`super` method can still guarantee that logic fires after the whole stack
of
I sometimes find myself doing things like
```js
this.children.splice(this.children.indexOf(child), 1)
```
but it seems that it will iterate the array twice. Maybe a new method can
be introduced so engines can optimize it:
```js
this.children.remove(child)
// or
I often find myself enjoying async functions until the time comes when I
don't want to await anything, and I want the call stack to be sync (i.e. I
don't want to defer if I don't have to).
But, async functions always return a Promise. So I find my self converting
my async functions back into
Here's some nice output in the console in Chrome, for `DOMPoint` and
`DOMPointReadOnly` classes:
```js
const point = new DOMPoint(1,2,3,4)
console.log(point)
```
output:
```
> DOMPoint {x: 1, y: 2, z: 3, w: 4}
```
([codepen example](https://codepen.io/anon/pen/xmaVej), open the devtools
crickets
```
`Object.observe` just works, and is s simple. I won't shoot
myself in the foot with it. I'd like to make a one-way data flow
implementation with it, using 3rd party web components, and
`Object.observe` would make this _incredibly simple_.
*/#!/*JoePea
On Sat, Jul 28, 2018 a
z'], (propName, newValue) => {
console.log('changed value:', propName, newValue)
})
o.foo = 'foo'
o.bar = 'bar'
o.baz = 'baz'
```
*/#!/*JoePea
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Another caveat of my implementation, for example, is that it adds
getters/setters for properties that previously didn't exist. This will
break code that checks existence of props. etc. etc. That's not a problem
with a theoretical `Object.observe`.
*/#!/*JoePea
On Fri, Jul 27, 2018 at 10:53 AM
props are not.
If I am okay to drop support for IE (I'm a little skeptical), then I'd like
to consider how Proxy might help, but it just seems more complicated that
it ought to be compared to `Object.observe` (which my behaviors could use
to observe elements).
*/#!/*JoePea
On Tue, Jul 24, 2018
Is there a way to polyfill `Object.observe` in such a way that the object
before observation is the same reference as the object being observed after
the call (i.e. not a Proxy), and other than monkey-patching getters/setters?
Is defining getters/setters the only way?
*/#!/*JoePea
modules (just needs infrastructure for passing that info around).
On Sun, Apr 15, 2018, 11:58 AM Mike Samuel <mikesam...@gmail.com> wrote:
> The box function defined in github.com/mikesamuel/tc39-module-keys
> enables things like this.
>
>
> On Sun, Apr 23, 2017 at 4:42 PM, /#!/JoePea <
Ah, interesting! That would be useful!
*/#!/*JoePea
On Sun, Apr 15, 2018 at 11:58 AM, Mike Samuel <mikesam...@gmail.com> wrote:
> The box function defined in github.com/mikesamuel/tc39-module-keys
> enables things like this.
>
>
> On Sun, Apr 23, 2017 at 4:42 PM, /#!/Jo
Thanks for sharing that Claude. It's interesting to see how others are
implementing public/protected/private for their classes. :)
- Joe
*/#!/*JoePea
On Mon, Apr 24, 2017 at 12:34 PM, Bradley Meck <bradley.m...@gmail.com>
wrote:
> To an extent, yes. You can use hoisting of function decla
Ah, makes sense. Thanks! - Joe
*/#!/*JoePea
On Thu, Mar 29, 2018 at 9:53 PM, Rob Brackett <r...@robbrackett.com> wrote:
> Why is it that the static version you implemented above can `.apply`
> itself without this same error (and `new` is not being used)?
>
>
> Wow, this
. Do you know of some
place to get such statistics besides for browsers?
*/#!/*JoePea
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
, if I try the following,
it fails:
```js
class Foo {}
Foo.apply(window, ['foo'])
```
Why is it that the static version you implemented above can `.apply` itself
without this same error (and `new` is not being used)?
- Joe
*/#!/*JoePea
___
es-discuss maili
. If the
engine were to read these all in advance, this would cause a problem. Are
we sure that all engines don't read the handler spec in advance?
*/#!/*JoePea
On Sat, Mar 24, 2018 at 2:59 PM, Oriol _ <oriol-bugzi...@hotmail.com> wrote:
> Hi Joe, I used a 2nd proxy as the handler in order to o
instances of my classes can be modified, but all
prototypes in the inheritance are not.
I'm also noting that Object.seal and Object.preventExtensions behave the
same way (they affect object that inherit from the prototype which is what
I want to avoid).
*/#!/*JoePea
__
Hello Oriol, why did you make two Proxies there? Does it serve some purpose
not achieved with only one Proxy? - Joe
*/#!/*JoePea
On Mon, Feb 19, 2018 at 12:35 PM, Oriol _ <oriol-bugzi...@hotmail.com>
wrote:
> > So, what if there was a way to unfreeze an object in the scope in which
and to avoid GC.
*/#!/*JoePea
On Mon, Feb 19, 2018 at 12:08 PM, Michał Wadas <michalwa...@gmail.com>
wrote:
> You can just do:
>
> const proxy = new Proxy(obj, {
>set() { throw new Error(); },
>defineProperty() { throw new Error();},
>deleteProp
] = otherArray[5]
// can be
array[
1
,
4
] = [
otherArray[3]
,
otherArray[
5
]
]
// but also a shorter form:
array[1, 4] = otherArray[3, 5]
```
*/#!/*JoePea
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org
C'd, but `somePromise` is not and the above console.log should
still fire at some point (or memory will be leaked)?
*/#!/*JoePea
On Thu, Jan 12, 2017 at 1:12 PM, Isiah Meadows <isiahmead...@gmail.com>
wrote:
> And that's why we're waiting on the next meeting to happen with notes
> po
.
*/#!/*JoePea
On Tue, Nov 7, 2017 at 4:37 PM, Isiah Meadows <isiahmead...@gmail.com>
wrote:
> Also, for future reference, these kinds of feature requests belong in the
> WHATWG's mailing lists, not here.
>
> On Tue, Nov 7, 2017, 18:59 Eli Perelman <e...@eliperelman.com> wrote:
>
What do you mean? Like coffeescript?
*/#!/*JoePea
On Tue, Oct 24, 2017 at 2:06 PM, doodad-js Admin <dooda...@gmail.com> wrote:
> Hi,
>
>
>
> By seeing many proposals about reducing the syntax for X and Y, I just
> want to open the idea of a [non-native] compiled JS wo
I'm not polyfilling Custom Elements, I'm polyfilling something else
that doesn't have the problems that Custom Elements has that makes
them not usable with SVG.
/#!/JoePea
On Tue, Oct 24, 2017 at 12:42 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:
> On 10/24/17 2:03 PM, /#!/JoePea wrote
`obj.foo() {}` is a syntax error in Chrome, so it seems possible to
make that a function definition.
/#!/JoePea
On Tue, Oct 24, 2017 at 12:45 PM, Brian Blakely
<anewpage.me...@gmail.com> wrote:
> Is it only valid with a semicolon after `foo()`, though? Pragma without
> semicolon thr
this prototype object from somewhere ... */
prototype.foo = function foo() {
// do something with `this`.
}
```
That sort of stuff (relying on non-arrows) isn't going away.
/#!/JoePea
On Tue, Oct 24, 2017 at 1:12 PM, Brian Blakely <anewpage.me...@gmail.com> wrote:
> To be clear, this isn't a
ementation).
The idea is that it would work on any type of element because it is
really generic (just like jQuery works on any type of element), so
patching Element seemed the best way to do it.
/#!/JoePea
On Tue, Oct 24, 2017 at 11:36 AM, Andrea Giammarchi
<andrea.giammar...@gmail.com>
or to the Map values.
I'm intuitively assuming "yes", but just want to confirm that I don't
have to explicitly removed everything from the `Map`s manually first.
/#!/JoePea
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/l
, what if browsers come out with `MathElement`,
`WebGLElement`, etc.
/#!/JoePea
On Tue, Oct 24, 2017 at 10:55 AM, Michał Wadas <michalwa...@gmail.com> wrote:
>> To "polyfill" an idea I have for DOM, to propose it later, etc.
>
> You can consider something like this depe
darkness my old friend');
}
};
// then ...
class MyEl extends HTMLElement {}
customElements.define('my-el', MyEl);
new MyEl;
```
/#!/JoePea
On Tue, Oct 24, 2017 at 10:36 AM, Andrea Giammarchi
<andrea.giammar...@gmail.com> wrote:
> I know I'm going to regret this already, but since I've s
= document.createElement('div')
console.log(div.foo) // it exists and is specific to the instance, not
a prototype property
```
Can this be done?
/#!/JoePea
On Tue, Oct 24, 2017 at 10:19 AM, /#!/JoePea <j...@trusktr.io> wrote:
>> This feels like a problem similar to
>> https://esdiscu
ds.
---
So suppose I want to "polyfill" a concept. For example, I want all
elements to have a new "foo" accessor after they've been constructed.
Or for example, suppose `HTMLElement.prototype.style` and
`SVGElement.prototype.style` didn't exist yet. How would I patch those
in?
/
It can be confusing because it is too similar to non-arrow functions. The
arrow syntax is clear in meaning.
*/#!/*JoePea
On Tue, Oct 24, 2017 at 9:51 AM, Brian Blakely <anewpage.me...@gmail.com>
wrote:
> This syntax is shorter, easier to write, and arguably easier to read.
> Wh
t modifying the global wouldn't
have any effect.
Is there a way to monkey patch a constructor in the middle of a built-in
prototype chain or to otherwise inject construction logic to base classes
of existing class hierarchies?
*/#!/*JoePea
___
es-dis
Here's a new real-world example showing people are naturally expecting ES6
`super` to be dynamic when they copy methods from objects to other objects:
https://stackoverflow.com/questions/46306598.
It makes sense to assume it would work this way considering how dynamic
pre-ES6 is!
*/#!/*JoePea
guage "feature" of concise methods that makes them not
constructable forces library authors to write ugly code who's output
is harder to inspect and debug by end developers.
/#!/JoePea
On Sat, Jul 30, 2016 at 3:04 AM, /#!/JoePea <j...@trusktr.io> wrote:
>> The distinction bet
1 - 100 of 232 matches
Mail list logo
