On Sep 1, 1:47 pm, Bemi Faison <[email protected]> wrote: > I'm definitely late to this thread, but isn't this what the ES5 Proxy object > is all about?
Yes, when those are widely available, I believe they would solve the problem Xavier is working on. > Even the ES5 Object constructor lets you handle non-mapped > properties. Also, JavaScript 1.8.1 (available since FireFox 3.5) lets you > define getters and setters for properties - such that assignments (via "=") > actually pass arguments to an internal setter function. I did mention that above. But again, it's not available widely enough. > Without these, you would need to use closures and use an access schema > within your get/set functions. The caveat with this non-native approach, is > that developers would need to learn your table schema, or the API for > defining it (as you have already). If I'm off, then pardon me and continue > your discussion... That's been my biggest concern with the approach presented. > If I'm right, then check out my previous work, GSet, > athttps://github.com/bemson/GSet/. (It was formally called Proxy, until I > discovered the ES5 Proxy object.) My approach differs from yours, in that my > object is compiled (i.e., cannot be changed). XJSAccessors.js lets the > developer change the access scheme of an object dynamically. Thus, I use a > configuration object, while you have an API. On the subject of what to name > getters and setters, I chose to follow jQuery's same-name approach. I've always had misgivings about the same-name approach, but it seems to fit well here. > [ ... very interesting code snipped ... ] > mySquare.width(2); // true > mySquare.width(); // 2 > mySquare,width('foo'); // false > mySquare.area(); // 4 > mySquare.area(10,10); // true > mySquare.area(); // 100 I haven't yet dug into the actual GSet code, but this sort of API is much more palatable to me. Can you also choose to have immutable properties? I would expect area to be only an accessor not a mutator. I can't quite buy the notion of an area function that allows you to set the height and width. But that is a secondary concern. > One last note: I'm phasing out my own use of GSet, as it's numerous closures > actually degrade performance. I would expect some degradation from a naive prototype-based approach, but does it degrade too much to be useful? At least for client-side JS, I find that many significant performance optimizations in don't noticeably affect the end user. Thanks for joining, -- Scott P.S. Any recent news on your flow code? (I can't remember it's name offhand.) -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
