JJ wrote:
> On Mon, 22 Aug 2022 01:08:06 +0200, Thomas 'PointedEars' Lahn wrote:
>> is one of the reasons why it is *deprecated* since ECMAScript Edition 5,
>
> Yet, ECMAScript later added `Symbol.unscopables` to support `with`.
Only to make ES 5− code that still uses “with” for *read* access easily
compatible with ES 6+:
<
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/unscopables>
But:
,-<
https://262.ecma-international.org/13.0/#sec-with-statement>
|
| | LEGACY
| |
| | 14.11 The with Statement
| |
| | NOTE 1: Use of the <Legacy> “with” statement is discouraged in new
^^^^^^^^^^^^^^^^^^^^^
| | ECMAScript code. Consider alternatives that are permitted in both
^^^^^^^^^^^^^^^
| | strict mode code and non-strict code, such as destructuring assignment.
| |
| | […]
,-<
https://262.ecma-international.org/13.0/#sec-conformance>
|
| A conforming implementation of ECMAScript must implement *Legacy*
| subclauses, unless they are also marked as Normative Optional. All of the
| language features and behaviours specified within Legacy subclauses have
| one or more undesirable characteristics. However, their continued usage in
| existing applications prevents their removal from this specification.
| These features are not considered part of the core ECMAScript language.
| Programmers should not use or assume the existence of these features and
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| behaviours when writing new ECMAScript code.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
| | LEGACY
| |
| | 2.2 Example Legacy Clause Heading
| |
| | Example clause contents.
>> and *code containing it cannot even be executed* in Strict Mode.
>
> I'm using `with`, so I don't use Strict mode in the first place.
PEBKAC.
>> This has nothing to do with the capabilities of the Proxy object because
>> its instance does not even "see" that write access.
>
> That is correct. It's not supposed to and can not be the job for Proxy.
> And that's the problem, because Proxy doesn't have a way to intercept
> property creation.
1. That is false, as I have demonstrated previously.
2. Again: The Proxy instance is NOT the target object in what only *seems*
to be a property-write access facilitated with the “with” statement.
>> You can determine whether a property is being created in the “set”
>> handler of the Proxy instance:
>
> That's not possible, because `set()` will only be called if the JS engine
> already know that the property exists as reported by `has()`.
I have demonstrated that to be false previously, too.