Re: ES3.1 Object static methods rationale document

2008-07-16 Thread Kris Zyp

 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

2008-05-11 Thread Kris Zyp
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

2008-05-09 Thread Kris Zyp
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)

2008-04-12 Thread Kris Zyp
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...)

2008-04-07 Thread Kris Zyp

 '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...)

2008-04-06 Thread Kris Zyp
 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)

2008-04-03 Thread Kris Zyp
 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

2008-03-28 Thread Kris Zyp
 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)

2008-03-13 Thread Kris Zyp
 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)

2008-03-13 Thread Kris Zyp
 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...)

2008-03-13 Thread Kris Zyp
 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

2008-03-11 Thread Kris Zyp
  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)

2008-03-11 Thread Kris Zyp
 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)

2008-03-11 Thread Kris Zyp
 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)

2008-03-11 Thread Kris Zyp
 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

2008-02-21 Thread Kris Zyp
 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

2008-02-20 Thread Kris Zyp
 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

2008-02-20 Thread Kris Zyp
 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

2007-11-15 Thread Kris Zyp

   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

2007-11-14 Thread Kris Zyp
 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

2007-11-14 Thread Kris Zyp
 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

2007-11-01 Thread Kris Zyp


 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

2007-10-30 Thread Kris Zyp
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

2007-10-21 Thread Kris Zyp
 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__

2007-09-11 Thread Kris Zyp
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

2007-08-21 Thread Kris Zyp
 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

2007-07-30 Thread Kris Zyp
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