On 13.04.2011 12:08, David Bruant wrote:
Le 13/04/2011 09:02, Dmitry A. Soshnikov a écrit :
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?
I warned from the beginning that I didn't see any :-p
More seriously, the main point of sharing my experiment was the
discussion on shared handlers for several proxies.
Currently a one possible I see -- a query to database with building
the query itself. Sort of:
where
.name("Dmitry")
.surname("Soshnikov")
.active(true)
I have tried to think of a lot of use cases. This one, for instance,
doesn't even requires proxies (As I understand it). As long as you
know the number and names of the all properties (I assume you do by
knowing which database table you're querying), ES5 accessor properties
could be used. This goes with the restriction that it's likely to be
far more memory consumming, but the pattern could be applied the same way.
Now that I think about it, I realize that for getters/setters, the
exact same object could be used (may depend on the use case). Same for
my pattern, I use Proxy.createFunction for each intermediary (l.10),
but I could factorize it and return the same proxy each time since
traps don't change at all.
Also, I'd like to note that if each of your property is a function
call, you don't even need accessor properties. That's what jQuery
already does by returning "this".
etc (though, it should be callable in contrast with yours
implementation). But, it also arguable whether it's so useful.
I have no strong opinion on callable or not. It was just an idea that
the pattern would better be used as a constructor. The main point of
the pattern lies on the use of the get trap in "firstHandler" and
"middleHandler". It could be improved by a different call/construct
trap (and the use of arguments for these).
Yeah, right, that's why I also mentioned that it's arguable whether the
pattern is useful to apply to this particular issue. It wast just a guess.
Regarding shared handlers, if exactly this is the point, we have also
think which practical things can we have.
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;
Shouldn't it desugar to "(typeof user.address == "object" &&
user.address != null)?" ?
Yeah, it's also just an example, any (but the most efficient) desugared
variant can be used.
Dmitry.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
