Hindsight, I probably sent that last message prematurely.
-
Here's some of the things I learned while making that, among dabbling
with other things:
The problem domain of working with collections is hard. Generically
modifying them is also hard. It wasn't until we got OO until we
learned how
I would suggest, if you have support in your editor, just making a
`???` snippet expand to `throw new Error("unimplemented")`. I've been
doing similar (mod the snippet) for a while, and it's worked pretty
well.
-
Isiah Meadows
m...@isiahmeadows.com
Looking for web consulting? Or a new website
I don't know why `foo(let x = 10)` would be a bad practice or hurt
readability.
I find it perfectly readable and with obvious meaning!
```js
foo(const x = 10)
bar(x)
```
vs
```js
const x = 10
foo(x)
bar(x)
```
I also find it "clean". So I guess these aren't really useful te
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 _
wrote:
> > So, what if there was a way to unfreeze an object in the scope in which
> the object was frozen?
>
> I don't thin
I disagree, I feel it's too clever. It'd make sense in a control flow
statement where in the alternate branch, the value is
meaningless/useless/ineffable/etc. (and this is why `for` loops
commonly allow such syntax already), but in ordinary function calls,
it seems like it's just trying to golf the
Hi Joe, I used a 2nd proxy as the handler in order to only allow the desired
traps.
Sure, I could have defined all blacklisted traps in an ordinary object, and
make them throw an error.
But this wouldn't be future-proof in case new traps are eventually added.
Whitelisting is safer.
-- Oriol
Currently, `Object.freeze`ing a prototype affects all objects "inheriting"
from the prototype when trying to modify props on an inheriting object when
those same props exist on the prototype, which isn't the behavior that I
want.
I'd like to prevent a prototype from being modifiable directly, but
I see, so you're relying on the engine reading the handler object during
the moment that the user of my `obj` will try to read `obj`, so if the
engine tries to read something in the handler (that we haven't whitelisted)
due to what the user is doing with `obj` then we throw the error. If the
engine
I find it odd and even a bit bizarre that [[Set]] even checks
frozenness of the prototype for non-getter, non-setter descriptors,
when it only adds own properties. Here's what I propose should change:
1. If the descriptor used by [[Set]] is an accessor property, use that
descriptor directly as is
> If the engine were to read these all in advance, this would cause a problem.
No, my handler always provides the same function for a given trap name, so even
if the traps were cached when the proxy is constructed, the code would still
work.
> Are we sure that all engines don't read the handler
BTW, just filed https://github.com/tc39/ecma262/issues/1154. It's
bizarre enough it seemed like a spec bug to me.
-
Isiah Meadows
m...@isiahmeadows.com
Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com
On Sat, Mar 24, 2018 at 6:41 PM
I understand the fear about "bad code" potentially sprouting from it. I
guess I'm not as bothered as long as I can do what I want. So it's a matter
of how heavily weighted the "potential bad practice" concern is over
developer power.
The advantage is that it's as powerful as the developer wants it
1. My concern with `while` is that it's a little too duplicative of
C-style `for` functionally (although it's not an exact partial clone).
That's why I backtracked on it right as I proposed it (within the same
email).
2. The scope would have been just like `if`, where it's scoped to the
body with a
13 matches
Mail list logo
