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
-
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
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,
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
'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
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
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
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:
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,
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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__
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
[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
27 matches
Mail list logo
