Object.getProperties and Object.getOwnProperties were part of the early design 
of thiss set of functions.  See for example, the June 24 draft at 
http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft

I proposed removing them, because I felt that they were starting to impinge 
upon the territory that might be occupied by a high-level, mirrors-style 
reflection model (see http://bracha.org/mirrors.pdf )  for ECMAScript.  I would 
like to avoid that  because I think a comprehensive mirror reflection model is 
something we might, over the long term, want to considering adding to 
ECMAScript.

You can see the potential conflicts a couple of places.  As currently defined, 
the property descriptor and property descriptor set objects are pure data 
records.  They have no behavioral properties. If you latter wanted to extend 
them to be mirror objects they would have to add methods and, at least for the 
property set descriptor, there would be issue with such method names 
conflicting with the names of reflected properties. The other place you see it 
is with getProperties which had been specified to return a flattened set of 
properties (flatten as in nothing distinguished own from inherited properties). 
In a generalized reflection model you would definitely what to have access to 
such "inheritance" information, for example by grouping properties by prototype 
or by tagging each individual property with inheritance information.

We ultimately concluded that the best way to think about what we are currently 
provide is that it is a set of primitive mechanisms that could be used to build 
higher level reflection facilities. If we had a strong use case we could 
reintroduce getOwnProperties as such a primitive, but so far it seem 
non-essential.  Incidentally, when we removed getOwnProperties we had to add 
getOwnPropertyName because otherwise you won't necessarily know what properties 
to ask for using getOwnProperty

-----Original Message-----
From: Igor Bukanov [mailto:[EMAIL PROTECTED]
Sent: Friday, July 18, 2008 8:15 AM
To: Allen Wirfs-Brock
Cc: John Resig; es3 x-discuss; es4-discuss@mozilla.org; Mark S. Miller; Robert 
Sayre
Subject: Re: ES3.1 Object static methods rationale document

2008/7/18 Allen Wirfs-Brock <[EMAIL PROTECTED]>:
> Collectively, 
> getOwnProperty,defineProperties/defineProperty,getOwnPropertyNames,getPrototypeOf
>  are intended to provide all the mechanisms necessary to build any of these 
> variants to extent or any other model of property manipulation using whatever 
> policies for property selection that might be desired by the designer.

This suggests to have a convenience method like getOwnProperties that
return an array of ptoperty descriptor for the object. It would allow
a user to define a simple form of the extend method as:

  Object.defineProperties(destination, Object.getOwnProperties(source));

It would also allow to define Object.clone(source) precisely as

  Object.create(Object.getPrototypeOf(source), Object.getOwnProperties(source));

Which in fact shows that Object.clone is in the same category as
Object.extend. Both methods defines very particular arrangement of
properties in the object and less fundamental than the rest sets of
the methods.

Regards, Igor

_______________________________________________
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss

Reply via email to