Approved in 2009, much of ES5 is supported by several current and upcoming browsers. However, the Proxy object didn't seem to get much attention until mid 2010. To date, FireFox 4 is the only browser supporting the ES5 Proxy API (with their own extensions, natch). Still, it's here and clearly my work's namesake is in the shadows of a looming standard.
Thus, the tangible similarity between ES5 and my work is the namespace "Proxy". An intangible similarity is the overlapping purpose of both objects. Both provide wrappers to "base" objects, for security, simplicity... many of the benefits described in the ES5 wiki for Proxy. Actually, I'm rather glad there is language to describe and capture why such an object is needed in web programming - a difficult task for me. I'll be sure to update my wiki pages to reflect the shared intentions.
Everything else between my Proxy and ES5's is different, however. After all, it's an entirely new language, using constructs unavailable to the environment that my Proxy object was designed for. My work is still a viable alternative to native getters and setters, and will continue to be for older browsers that don't support ES5 - which makes heavy use of these and other new constructs. Must be nice designing a language...
Does my Proxy object do anything ES5's doesn't? From what I've read so far - and I'm not claiming to be an expert, ES5's Proxy is a one-way street. That is, there doesn't seem to be a way to capture the source object - what they refer to as the "subject" - from a given ES5 Proxy. Therefore, one could return a Proxy (of either type), but only mine allows extracting the subject again for further manipulation. My Proxy does so securely, using a signature object.
The hardest part: parting with the name. Obviously, I can't keep calling my object a "Proxy". Granted, the term "proxy" is generic enough. Even after you isolate it to programming, it still has a variety of meanings and applications. I've considered "Alias", "Mirage" or "Mirror" (to flatter AmbientTalk - I think they had a hand with writing/inspiring the ES5 Proxy draft). Of course, I'm open to suggestions from readers.
One driver to change the name, is my latest project: Flow. I hope to present and blog about soon, but know that it uses my Proxy object extensively. In some cases, that project would do better using the ES5 Proxy - assuming better performance and less memory. I'll save discussing that project for another day... First, I'm going to make sure that name isn't slated for another ECMA-Script standard!
No comments:
Post a Comment