At least to this dev, it's pretty clear what each line is doing and how -- certainly clearer than what you mean by ugly.
> your meta-programming doesn't have to always be only eval and .bind in various incarnations
I don't think this statement makes a whole lot of sense except to the degree all meta-programming could be argued to be eval and bind in various incarnations. Certainly there's literally other options available for JS.
> unsafe, inconvenient and slow
Someone holding up Ruby as an example while complaining about safety and speed in other languages is... interesting.
> the "with" usage on which this hack is based is actively discouraged by everyone using JavaScript as it basically mixes in the object into the current scope
"with" gets a bad rap, and its blanket discouragement/deprecation may be as big a mistake as its original design. It's true that using it takes some thought about the potential scope ambiguities, and it's true that it could have been better designed (personally, I think an optional de-ambiguating dot-operator would have been a nice lightweight way to go), but it's also pretty useful, and once you take the time to understand what the possibly ambiguous cases are and what the decided-on rules are, it's not hard to work with.
> In a sane language, you do .instance_eval, and you narrow the scope to whatever the object contains.
The right instance scoping construct might've been one of several nice ways to go too, but certainly not the only sane option.
> this doesn't make them great.
No, apparently just... useful. Useful enough to build something like this. Certainly not great, though.
> "with" gets a bad rap, and its blanket discouragement/deprecation may be as big a mistake as its original design
Unfortunately not. The design of with not only makes the code difficult to reason about for humans, it also makes the code difficult to reason about for js engines, and so it typically prevents any interesting optimisations. So code written using "with" will be both confusing and slow.
At least to this dev, it's pretty clear what each line is doing and how -- certainly clearer than what you mean by ugly.
> your meta-programming doesn't have to always be only eval and .bind in various incarnations
I don't think this statement makes a whole lot of sense except to the degree all meta-programming could be argued to be eval and bind in various incarnations. Certainly there's literally other options available for JS.
> unsafe, inconvenient and slow
Someone holding up Ruby as an example while complaining about safety and speed in other languages is... interesting.
> the "with" usage on which this hack is based is actively discouraged by everyone using JavaScript as it basically mixes in the object into the current scope
"with" gets a bad rap, and its blanket discouragement/deprecation may be as big a mistake as its original design. It's true that using it takes some thought about the potential scope ambiguities, and it's true that it could have been better designed (personally, I think an optional de-ambiguating dot-operator would have been a nice lightweight way to go), but it's also pretty useful, and once you take the time to understand what the possibly ambiguous cases are and what the decided-on rules are, it's not hard to work with.
> In a sane language, you do .instance_eval, and you narrow the scope to whatever the object contains.
The right instance scoping construct might've been one of several nice ways to go too, but certainly not the only sane option.
> this doesn't make them great.
No, apparently just... useful. Useful enough to build something like this. Certainly not great, though.