Re: ES3.1 Object static methods rationale document
Arguably, some of the need for direct prototype access is alleviated by providing the clone method. However, there are still plenty of other situations where it is useful. I observe that __proto__ in SpiderMonkey- and Rhino-based JS is mostly used for cases covered by Object.create, with a minority use- case that we've discussed before initializing it to null in object initialisers to make maps (dictionaries). I am curious how Object.create covers this __proto__ use case of making objects with a defined proto. Doesn't Object.create create a new object and copy properties over? __proto__ allows objects with existing properties to have their proto defined in constant time, but isn't Object.create still O(n), with n being the number of properties? Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: getter and setter inheritance
When an object A is defined that inherits from it's prototype object B that has a getter and setter defined for foo, and object A wants to inherit the behavior of B except for a slight modification to the getter behavior, it could be advantageous if the setter could still be inherited without having to redefine it on object A. If the developer wants to make property foo read-only, this can still easily be done by creating a setter that throws an exception (or does nothing). That being said, I would still favor the approach of treating getters/setters as a full slot, where inheritance doesn't go past half-definitions because that is behavior that is currently used on the web today. Also, the idea of making setters without getters illegal is interesting. However, while they may be rare, I think setters without getters has use cases. This seems like unnecessary arbitrary restriction to dissallow setters without getters. Furthermore, this is not the behavior of current browsers, there is no precedent in JavaScript implementations for preventing this combination. Is there other reasons for this restriction that I am not aware of? Thanks, Kris - Original Message - From: Mark S. Miller [EMAIL PROTECTED] To: Kris Zyp [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; es4-discuss Discuss es4-discuss@mozilla.org Sent: Sunday, May 11, 2008 10:23 AM Subject: Re: getter and setter inheritance 2008/5/9 Kris Zyp [EMAIL PROTECTED]: A question of how inheritance/delegation should work with getters and setters was raised in a recent discussion. Hi Kris, The way I've been thinking of getters and setters is as if there are two kinds of properties: * A data property is defined by its current value, and whether the value is writable. If the value is not writable, the property is considered read-only. * A procedural property is defined by a getter function and an optional setter function. If there is no setter function, the property is considered read-only. For both kinds of properties, a property is further defined by its property name, whether the property is enumerable, and whether the property's definition is redefinable. (Where redefinable implies deletable.) This would be reflected (so to speak) concretely in the results of Object.getProperties and Object.getProperty, and in the argument of Object.defineProperties. Object.getProperty(x, 'foo') = {value: 3, writable: false, enumerable: false, redefinable: false} Object.getProperty(x, 'bar') = {getter: function(){return 3;}, enumerable: false, redefinable: false} in which case x.foo and x.bar are behaviorally identical for non-reflective clients. If there is an object A whose prototype is object B, and object A defines a getter for property foo, and object B defines a setter for property foo, and we write a value to A.foo, should the setter defined on object B be called? I think it should be illegal to define a setter without defining a getter. A procedural property should either have a getter or have a getter and a setter. Assuming B defines a getter and a setter for foo, and A defines a getter for foo, the answer should be no. A's own foo is a read-only procedural property that fully masks B's foo. If A didn't define any property on A, the setter would be inherited from B and would be called when A.foo was modified. Yes. However, with the getter defined on A, should the inheritance stop at A, because there is a slot defined, or should it continue along the prototype chain because there was no setter defined for that property (nor plain value)? Stop at A. s/slot/property The question also applies when the getter and setter are reversed. When a property is accessed and there is a setter defined, but no getter, That case should be rejected as illegal. should we continue to down the prototype chain to find a getter or a plain value, or stop and return undefined? AFAICT, ES4 doesn't explicitly define which is the correct behavior. Firefox follows the former behavior: B={set foo(v){foo = v}, get bar(){return bar value}} B.foo should be rejected as illegal. A={get foo(){return foo value}, set bar(v){bar = v}, __proto__:B} A.bar should be rejected as illegal. -- Cheers, --MarkM ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
getter and setter inheritance
A question of how inheritance/delegation should work with getters and setters was raised in a recent discussion. If there is an object A whose prototype is object B, and object A defines a getter for property foo, and object B defines a setter for property foo, and we write a value to A.foo, should the setter defined on object B be called? If A didn't define any property on A, the setter would be inherited from B and would be called when A.foo was modified. However, with the getter defined on A, should the inheritance stop at A, because there is a slot defined, or should it continue along the prototype chain because there was no setter defined for that property (nor plain value)? The question also applies when the getter and setter are reversed. When a property is accessed and there is a setter defined, but no getter, should we continue to down the prototype chain to find a getter or a plain value, or stop and return undefined? AFAICT, ES4 doesn't explicitly define which is the correct behavior. Firefox follows the former behavior: B={set foo(v){foo = v}, get bar(){return bar value}} A={get foo(){return foo value}, set bar(v){bar = v}, __proto__:B} A.bar - undefined A.foo = 'new value' - setter is not called, foo is not set Thanks, Kris___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
lookup attributes/getters/setters (was Re: ES4 draft LAST CALL: Object)
Do we have any mechanism for detecting if a property is using a getter/setter or detecting the attributes of a property? It seems like if we can get make getters/setters as properties through object initializers, we should be able to detect if a property is using a getter/setter. Also, if we can define property attributes through Object.defineProperty, it seems we should also be able to detect the attributes of a property. As far as attributes, I believe you can use various (ugly) tests to see a property is readonly, permanent, and/or enumerable, but it seems reasonable to have a complement to defineProperty that could provide this information. In SM (and Safari and newer Opera, I assume), you can determine if a property has a getter/setter (and get the function) with __lookup{G|S}etter__. Thanks, Kris - Original Message - From: Brendan Eich [EMAIL PROTECTED] To: Mark S. Miller [EMAIL PROTECTED] Cc: es4-discuss@mozilla.org Sent: Friday, March 21, 2008 11:09 AM Subject: Re: ES4 draft LAST CALL: Object On Mar 20, 2008, at 6:05 PM, Mark S. Miller wrote: * I still prefer __defineProperty__ (under whatever name) to be a static property rather than an instance property, so that an object can reliably perform this operation on itself without worrying about whether it is shadowed by an own property of the same name. As an instance method, to protect against this shadowing, one must instead write: Object.prototype.__defineProperty__.call(this, ...) This is so much less convenient than the unsafe this.__defineProperty__(...) that people will get sloppy. Part of programming language design is to make the safer way also generally be the easier way. The innumerable places where Object.prototype.hasOwnProperty.call(this, ...) were or needed to be written should have already taught these lessons. I agree completely, based on Narcissus experience -- see: http://lxr.mozilla.org/mozilla/search?string=__defineProperty__ in particular http://lxr.mozilla.org/mozilla/search?string=hasDirectProperty Thanks for pointing this out. The long-standing Mozilla __defineGetter__, __defineSetter__, etc., if they were to be standardized, could also be rephrased as Object static methods. In ES4 terms these would be final and static, so fixtures. * I also continue to think that any of the other alternatives for parameterizing __defineProperty__ were more readable than a bunch of positional flag parameters whose order will often be mis-remembered. My favorite remains a C-style or-ing of bit flags, with manifest constants defining the bits. Agreed again -- Narcissus's __defineProperty__ used dontDelete, readOnly, dontEnum trailing booleans, which at least initially helped by allowing the most common cases to leave off trailing arguments. But I could never remember which was which, reading opaque triples of boolean values in call sites. /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Dynamic class default (was Re: Class method addition...)
'final' already means can't be overridden for methods and can't be extended by subclassing for classes in several languages. Adding another meaning, even if it's of the same mood, seems like a bad idea to me. What's the point of your request? If you mean to promote AOP I don't know what the connection would be. (a sacred cow, per my last message to you, reply-less :-P) I ran out of arguments :). , you risk degrading overall integrity, or merely imposing a syntax tax as most class users have to say inextensible class (kidding, but it would have some contextual keyword in front -- and not static). Just a idea for budget cuts, it's rejection doesn't bother me, not an important issue to me. Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Dynamic class default (was Re: Class method addition...)
Since you grant use-cases for sealing objects against mutation, are you simply arguing about what the default should be (that 'dynamic class' should not be required to get an extensible-instance factory, that 'class' should do that)? Well if it is up for debate... Can we have classes be dynamic by default, and non-dynamic if the class is declared to be final? I realize that non-dynamic and final are not identical concepts, but they are similar. Keywords surely count towards the complexity budget, this would save us a buck. Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Class method addition and replacement (was Re: AOP Compatibility)
the moment, but I assume you can't do replace a method on a user class with another ad-hoc function. Absolutely not with fixtures, I was thinking about this, is there any reason why you can't replace a class's method with another method or install a method on an instance object that overrides the class's method, assuming that the method signature remains the same, the body has correct typing use of |this|, and the class is non-final? This seems to have the same integrity as method overriding in subclasses. Being able to do this (and possibly dynamically adding methods to classes) would bring the level of dynamicism that Mark had suggested with his ES4 sugar proposal (being able to create classes on the fly), but without destroying the fundamental ES4 typing/fixture system. This could be used to solve AOP as well, and bring a distinctly higher level of dynamicism which could be leveraged to progressively build, serialize (with proper introspection), and deserialize classes. Essentially, are there mutations to classes and object instances that do not effect integrity and do not violate explicit contracts against mutation (final annotation=no method mutations) that we could allow? Thanks, Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Generator use-cases
Generators, besides supporting one level of coroutine suspending and (re-)calling, are the cheapest way to implement an iterator. I think Neil's inspiring demonstration of pseudo-threading with generators is also worthy of inclusion in your list of generator use cases: http://www.neilmix.com/2007/02/07/threading-in-javascript-17/ It is quite interesting in that single level coroutines can be combined to create multi level coroutines in a form that provides explicit control of creating composable flow or maintaining atomicity. Generators are a pretty powerful and valuable construct, IMO. I certainly hope they stay in ES4 as well. Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Controlling DontEnum (was: ES4 draft: Object)
the frequency of use). Thus on Object.prototype and as an intrinsic propety on Object instances: function __createProperty__(name:EnumerableId, dontEnum:boolean=false, dontDelete:boolean=false, readOnly:boolean=false): void I thought that this only made sense in conjunction with Neil's suggestion of providing the value at the same time. If you create a readonly property, how are you supposed to set the value otherwise? Shouldn't it be: function __createProperty__(name:EnumerableId, value, dontEnum:boolean=false, dontDelete:boolean=false, readOnly:boolean=false): void And if readOnly implied dontDelete, I would have guessed readOnly to be a little more frequent than dontDelete, but of course that is just a guess. Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Controlling DontEnum (was: ES4 draft: Object)
set dontDelete and readOnly? You can create non-deletable properties by using a class or record type They can't be added after an object is created. and you can create read-only properties by adding a get function without a corresponding set... Unless behavior is different than ES3, setters (and lack thereof) are not dontDelete, therefore still easily mutated: obj = {get foo() { return 'hi' }} Object foo=hi obj.foo hi delete obj.foo true obj.foo = 'goodbye' goodbye obj.foo goodbye ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Deleting Getters and Setters (was Re: Controlling DontEnum...)
the fact; getters and setters defined by an object initializer or in a class are fixtures and hence not deletable. Really, that doesn't create a compatibility problem? I realize getters and setters aren't in ES3, but this seems like ES4 would be making a significant departure in behavior from the majority of current browser implementations of the same getter/setter syntax used by ES4: obj = {get foo() { return 'hi' }} Object foo=hi obj.foo hi delete obj.foo true obj.foo = 'goodbye' goodbye obj.foo goodbye With ES4, obj.foo would still be returning hi at the end? That sounds nice, but is there no fear of compatibility issues with that? Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Object
1) Remove the feature entirely from ES4 (as part of the judicious feature cuts process) until a more appropriate syntax is found Setting dontEnum is immensely valuable as a framework developer. I realize that is not a very technical argument, but controlling dontEnum is of more value than many of the other features in ES4, and would certainly hope it is not omitted. So long as setPropertyIsEnumerable is a method of Object.prototype, it raises the otherwise pointless question of the meaning of overriding it. At the last ES3.1 face-to-face, we agreed instead on the following static method on Object, as recorded at http://wiki.ecmascript.org/doku.php?id=es3.1:targeted_additions_to_array_string_object_date: - Object.dontEnum(object, memberName) I realize I wasn't there (at the ES3.1 F2F, only called in), but why was this discussed for ES3.1? I thought the page you are referencing was simply items that hadn't been cleaned up yet, since it clearly does not subset ES4 (as I noted in my comments on that page). If we desire that this be a part of ES3.1, it should be brought up as a proposal for ES4, so that ES3.1 can safe subset it, rather than creating new divergent features for ES3.1. Frankly, I like the idea of using Object.dontEnum(object, memberName), that sounds great to me, but it should be an ES4 proposal first and should not be considered for inclusion in ES3.1 unless and until accepted by ES4. BTW, Another possible syntax could be: Object.setAttribute(object, memberName,attributeFlag) which could be used to set the dontEnum, readOnly, and dontDelete flags and probably more closely follows the internal structure of implementations as well. Thanks, Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Controlling DontEnum (was: ES4 draft: Object)
The use of a __-bracketed name satisfies the second goal, but it would be a problem for Caja or similar. This is an issue where I would appreciate Mark's feedback. I can't speak for Mark, but it seems like it might actually be beneficial that unsecured code (regular ES4) would have the ability to set DontEnum and secured code (Secure ES, Cajoled Caja, ADsafe, or whatever) wouldn't have that capability. +1 Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Controlling DontEnum (was: ES4 draft: Object)
It seems wrong that the code should run once one way, and then another way, but there be no way back. It's not so much that I think there should be a way back, but I'd rather that than this, which I consider a weird situation. Declarative is nice, but as mentioned before, it ignores one of the primary use cases: addition of non-enumerable properties to built-ins (by libraries, primarily). Also the double underscores are really ugly syntax... That's the idea, no one is currently using such an ugly method ;). Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Controlling DontEnum (was: ES4 draft: Object)
I've read mention of the weirdness of the timing window between the property definition and it's marking as non-enumerable. That combined with the above observation makes me wonder if this should really be obj.__setNonEnumerableProperty__(name, value); +1 I like it too. Any chance that by setting the attribute at the same time of setting the property value, we could resurrect the possibility of setting other attributes as well (with a single method): Object.prototype.__setPropertyWithAttributes__(name, value, dontEnum: boolean, readOnly: boolean, dontDelete: boolean); And various proposed syntax like: obj = {dontenum a: 1, const b: 2, var c: 3}; could be written: obj = {}; obj.__setPropertyWithAttributes__(a,1,true); // property a is not enumerable obj.__setPropertyWithAttributes__(b,2,false,true); // property b is readonly obj.__setPropertyWithAttributes__(c,3,false,false,true); // propery c is permanent I wonder if readonly and dontdelete are other attributes where there might be benefits derived from trusted code (regular ES3/4) being able to control, and untrusted code (ses, caja) not being able to control. I can't think of what those benefits might be, maybe another question for Mark or Doug to think on. Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: AOP Compatibility
Another thought: does ES4 provide enough introspection capability to write proxy objects that wrap an immutable class instance? It seems as though it should be possible to create a single class (with * getter/setter functions) that can wrap any object, emulate its interface and provide AOP advice capabilities. If this is indeed possible, would that prove useful for the situations Kris is concerned about? That is good question. It wouldn't truly solve the problem. When you call dojo.connect to request that your method add advice/a listener, the caller doesn't expect that it is going to be told that it should no longer use the original class instance, but rather a proxy. But this could still mitigate the problem. At least users could proxy class instances such that they are advisable in the same way their ol' dynamic ES3 objects were. I don't know if their is sufficient introspection capability though, I would love to know if that is possible. Thanks, Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: AOP Compatibility
I thought the question was about annotating class fixtures? Yes, that was my intent, sorry I wasn't clearer. I knew that built-ins were designed to be backwards compatible. I don't have the RI in front of me at the moment, but I assume you can't do replace a method on a user class with another ad-hoc function. Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: AOP Compatibility
Absolutely not with fixtures, but you can put the prototype qualifier in front of function definitions in classes to create prototype methods just like the ones in ES3's builtins, and you can make your class dynamic (although IIRC, all class objects where static properties live are mutable; class *instances* are fixed unless the class is dynamic -- Graydon or Jeff should correct me if I'm wrong). Of course a library function (like dojo.connect) that is called to advise a method on an object doesn't have control of how the object was created. If it is an instance of user class (and not dynamic), this function will this fail. This functionality is pretty core and heavily used by Dojo and I believe is used by other libraries as well. Of course existing code will continue to work, but it will be disappointing to find this function fail for new objects created with ES4 functionality. I don't know an easier solution, other than real AOP support. Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Close review of Language Overview whitepaper
Various interested parties favored something like the json2.js API already, and I think everyone will rally round it and beat on it, to make sure it has the right usability and knobs. I'm hopeful. +1 from me. One request: When a filter function is provided to JSON.parse, I would like the filter to be called with |this| defined to be the root object that is being created by the parsed JSON text. Having a reference to the created root object can be useful for some forms of filters such as reference resolvers. The problem in general is that Bob's classes and Alice's classes were written without anticipating Carol's combination of the two, but Carol cannot use MI. Nor can she provide objects that match structural types. She has to inherit from both Bob's and Alice's classes. Was multiple inheritance discussed for inclusion in ES4? I am aware of the general arguments against it, but I was wondering if had been considered or if there are technical aspects of ES4 that preclude it. Does this clear things up? Yes, that certainly helps me to understand the rationale. Thanks for being so willing to answer questions about ES4 issues. Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Restricted Eval
On Nov 1, 2007 3:46 PM, Kris Zyp [EMAIL PROTECTED] wrote: It's a sandbox, right? Should be safe. Not so fast: last they gave up. rexec was removed from the language. With the complexity of creating and verifing a sandboxing eval that allows shared mutable objects with some degree of safety, is it conceivable that ES4 could alternately pursue sandboxed eval through a shared nothing construct? I remember that Brendan mentioned that Google Gears approach is a good model, but that it would be premature to standardize. I agree standardizing on the actual Gears API would be strange, however, wouldn't taking a shared nothing approach to sandboxing (using messaging) like gears (but with our own API) be a safer and easier to analyze approach to sandboxing and more reasonable in terms of time constraints for inclusion in ES4 than the scopable eval? Shared nothing techniques are hardly a new PL concept, albiet I am sure it is still not a trivial addition. Just thinking about what it could look like: mySandbox = new Environment(myScriptToSandbox); onmessage=function(message : string) {...} mySandbox.sendMessage(start); And of course, it seems hard to resist the temptation to entertain the hope that this could be a possible API for adventurous implementors to use for a concurrency construct (use the same API for ConcurrentEnvironment), which could advise ES5's work on concurrency. Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Close review of Language Overview whitepaper
JSON: Sounds good. This proposal is withdrawn and another API is being considered for reinclusion later. See http:;//json.org/json2.js. toJSONString and parseJSON are going away? I was actually wanting to write and suggest the removal of these, with Douglas's recent change in his JSON API. I am glad to see these will be going away. Will ES4 include the other API (JSON.parseJSON / JSON.stringify)? You miss the main difference: structural types are not equated by name, so they avoid the inheritance trap of classes, which consists I would love to understand the purpose of structural types better. I don't understand how base class evolution is constrained in ways that super record types aren't. I also don't understand how the goal of applying types to existing ES3 objects can not be achieved with wrap operator and nominal types. I know there something I am missing here. Thanks, Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Restricted Eval
But the only point I was trying to make was that providing a fun eval(s, obj) and encouraging users to roll their own sandboxes would be irresponsible. Point taken, you are right. I still hope that some type of sandboxing can be developed though. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: [TLUG]: ECMAScript (Javascript) Version 4 - FALSE ALARM
From a pragmatic perspective, it seems to that the critical goal behind all of this, is what will bring a better development environment for the future of the web, and the key to this is what will be broadly implemented. The choice of the name is of course around this central issue since the ES title brings such a strong motivitation for implementation. However, if ~10 years down the road, ES4 is not implemented broadly enough that web developers can code to it, than it is of signficantly less value. While unanimity is not needed for a standard to be passed, if the one of the key browser vendors will not implement it, than how valuable are our efforts? I know that there are, or will be efforts to provide a Tamarin plugin for other browsers, but is this really what we are pinning our hope on? Plugins usually don't reach necessary distribution for developers to rely on them. Or are we hoping that the ES4 title will be sufficient to get an implementation from every vendor? I certainly acknowledge that it is insidious that there might a suggestion to design around one member, but I will still ask, is there any concessions that can be made to increase the probability that MS would implement ES4 in the future? Perhaps this has already been discussed, so I apologize if it has. Does MS have specific issues, or is their dissent simply for the purpose of avoiding committing to implementation (regardless of the content of ES4)? Is security one of the main issues? Is it the size and scope of the language? From what I understand, I think these are Crockford's concerns, although I don't know if that is true for MS. I think that if even 25% subset of ES4 was uniformly implemented in all browsers in 10 years, web developers would be vastly further along than if the 100% of ES4 was implemented in half the browsers. While unfortunate that such orthogonal issues could affect language design, and perhaps stifle innovation, I would like to see what will be best for the future of the web. Does anybody know if there is anything that can be done to increase the likelood of full cross browser implementation of ES4? Does anyone know the issues or parts of ES4 that are causing dissent? Is it the impact of the size of the language (on security, implementability, etc)? Apologies for my excessive pragmatism, Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Object.prototype.clone
http://javascript.crockford.com/prototypal.html It is the act of creating a object that inherits from/delegates to the provided object. Peter is suggesting sugar for one of the important mechanisms in a prototypal language. I believe the copy semantic is used in Self. clone is bit misleading (well, I think copy is too). With classes, we call it subclassing. We could call it subobject :). Douglas calls it begetObjet (nice), I personally think it is very valuable construct and I like what it encourages, but on the otherhand it is so easy/compact to create (about 4 lines of code), and it doesn't seem to be the direction ES4 is headed, so it's omission seems reasonable. YAHOO.mst.app.code = (function(){ // 1100+ lines... I don't think this doesn't have anything to do with the topic. Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: __proto__
Is __proto__ somehow a new security threat? __proto__ has been around for ages in SM/FF and not only that, but it has been there in the more hazardous writable form. I just wanted it be actually included in the spec. Or is there some new functionality in ES4 that will somehow interact with __proto__ to introduce a security threat? Kris - Original Message - From: Lars T Hansen [EMAIL PROTECTED] To: Kris Zyp [EMAIL PROTECTED] Cc: Brendan Eich [EMAIL PROTECTED]; liorean [EMAIL PROTECTED]; es4-discuss@mozilla.org Sent: Tuesday, September 11, 2007 2:34 AM Subject: Re: __proto__ On the one hand, __proto__ is another potential security hole, and it prevents implementations from sharing prototype objects among multiple documents -- the link may be read-only but the object isn't. Function B called from function A with object O may hack O.__proto__ and A can do nothing about it; suddenly all O-like objects in the system act differently. On the other hand, Constructor.prototype is generally available for any Constructor, so it's hard to see what the real damage is -- it's not obviously worse than some other aspects of the language. On the third hand, some implementations may have specialized objects for which no Constructor is available and for whom keeping [[Prototype]] unavailable is desirable. Similarly, some toolkits may have private prototype objects that are not available to client code because the constructor is hidden in a lexical scope (ES3) or package/namespace (ES4). Introspection is great, but it assumes a lot about how trust works in the environment. --lars On 9/11/07, Kris Zyp [EMAIL PROTECTED] wrote: The alternative above would standardize read-only __proto__, which would make that property no longer implementation-specific. But of course we have no proposal to do that. I realize this wasn't really the main subject... but could the __proto__ property be defined in the spec (as readonly)? I would love to see that property standardized. Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Comments to the JSON related proposals
but I think we should not add a TRANSIENT attributes for ES3, DONTENUM should be enought and backward compatible See http://wiki.ecmascript.org/doku.php?id=proposals:enumerability If we added the ability to set attributes, the propertyIsEnumerable extra parameter proposal would be unnecessary (albiet convenient). Also, IMHO, transient and dontenum are different concepts. They both affect enumeration, but one in the context of introspection and one in the context of serialization. Kris ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Transient property attribute
The transient property is not just for JSON serialization, but gives an abstracting indication of transience that is important for any future persistence, serialization, or mapping mechanisms (which could include libraries or future language additions). Thanks, Kris On 7/30/07, Lars T Hansen [EMAIL PROTECTED] wrote: On 6/6/07, Kris Zyp [EMAIL PROTECTED] wrote: Would it be possible to add a property attribute transient? It would not need any special treatment, it would serve purely as a marker. Java has this as a property attribute/field modifier, and it is very helpful for defining what fields should be included in persistence/serialization. The only implementation detail that this might effect is that I believe that it would be most proper if toJSONString ignored properties that had been marked as transient. So if one declared an instance variable: class A{ transient var b } b would not be included in toJSONString serializations, and other persistence/serialization strategies could use introspection to be aware that such values should not be saved. Any chance this could make it in the spec? As this is probably just one more approach to customizing JSON serialization, and we're not trying to do much with that (despite extensive debate on that list), my guess is no. --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss