On 12.04.2011 20:41, David Bruant wrote:
Hi,
I'd like to share my experience on a recent experiment. First off, I'd
like to apologize for the name; "declarative object" doesn't really
capture it and may be confusing. Second of all, what I have created
doesn't really solve any use case (I'll discuss it), but offers at
most some syntactic sugar. Code can be found here :
https://github.com/DavidBruant/DeclO
One idea is to have an object "o". This object can accept any property
name (get trap only in my case). Accessing a property will generate an
object on-the-fly which itself can accept any property name and
generate an object, etc. At the end, the object can be used as a
constructor to do something. Example:
---
var a = new o.azerty.are.the.first.letters.of.my.keyboard();
var b = new o.David.Bruant.writes.JavaScript();
---
The point could be to build something based on the property names
(stored in the propNames variable and added with the push l.8). Of
course, a constructor taking a string array could be as useful. That's
the reason why I said earlier it doesn't solve any use case. The
syntax sugar is the only added value I can think of.
The exact use of the string array is to be defined in the
constructTrap function. The pattern is here.
Yes, the pattern is interesting, though, really, which practical
use-case will it have? Currently a one possible I see -- a query to
database with building the query itself. Sort of:
where
.name("Dmitry")
.surname("Soshnikov")
.active(true)
etc (though, it should be callable in contrast with yours
implementation). But, it also arguable whether it's so useful.
However, your letter made me think on proposing existential operator,
which is a syntactic sugar to avoid long testing whether a property
exists and only after that to apply it. This already is again used in
CoffeeScript, so I'll show the examples:
let street = user.address?.street
which desugars e.g. into:
street = (typeof user.address != "undefined" && user.address != null)
? user.address.street
: undefined;
The same with functions (which is even more convenient that just with
properties):
let value = entity.getBounds?().direction?.x
which desugars into:
let x = (typeof entity.getBounds == "function")
? (typeof entity.getBounds().direction != "undefined" &&
entity.getBounds().direction != null)
? entity.getBounds().direction.x
: undefined
undefined;
(I specially avoid optimization with saving intermediate results -- just
to keep clarity)
I think it's useful thing and I already used in several times.
Dmitry.
Anyway, the main thing I want to share is a reflection on shared
handlers. At l.13, all proxies created on-the-fly use the same handler
object (I have purposefully not inlined it in l.10).
Thinking about shared handlers, I have realized that a proxy internal
state is "stored in" its method handlers and the way they interact
with each other, so this has to be taken into account when considering
sharing a handler among several proxies.
In order to share the same handler, some proxies must share the same
functions (even dynamically). Each function having a unique scope, it
means that these proxies must share their traps scopes. So, either the
state of several proxies is shared (like in my case where they share
"propNames" on purpose) or the shared scope could be reduced to a
WeakMap which in turn can store a per-instance "state". Both solutions
aren't mutually exclusive.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
