You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This proposal seeks to formalize the behavior of "looping" DefineMap methods and JavaScript functions and statements in relationship to the serialize, get and a new enumerable behavior.
Methods, functions, and statements
This proposal attempts to define the behavior of the following DefineMap methods, JavaScript functions, and JavaScript statements:
.get() - gets a non-observable representation of this map.
Note that JavaScript does not provide a mechanism to control the following behaviors:
Object.keys() - Would need [OwnPropertyKeys] symbol here.
.hasOwnProperty() - Would need [OwnPropertyKeys] symbol.
.getOwnPropertyNames() - Would need [OwnPropertyKeys] symbol.
In these cases, this proposal provides a desired behavior. The actual behavior will probably not work that way and a can-define alternative will need to exist.
I propose two behaviors for controlling the previously listed methods, functions, and statements.
enumerableBoolean - true if the property is enumerable, false if otherwise. getters are enumerable: false by default, all other properties are enumerable: true by default.
serializeBoolean | function() - Controls the behavior of only serialize, overwrites the behavior of enumerable.
Furthermore, all core JavaScript functions and statements should follow the .get() behavior:
for...in - Same as for(var prop in map.get())
Object.keys() - Same as Object.keys( map.get() )
.hasOwnProperty() - Same as map.get().hasOwnProperty( propName )
.getOwnPropertyNames() - Same as map.get().getOwnPropertyNames()
How define could be used to support for ... in loops currently:
var definition = {
get prop(){},
};
var MyType = function(props){
var obj = define( props, definition );
return obj;
}
new MyType();
for(var prop in obj ) {}
}
From: canjs/canjs#2441
This proposal seeks to formalize the behavior of "looping" DefineMap methods and JavaScript functions and statements in relationship to the
serialize
,get
and a newenumerable
behavior.Methods, functions, and statements
This proposal attempts to define the behavior of the following DefineMap methods, JavaScript functions, and JavaScript statements:
.get()
- gets a non-observable representation of this map..serialize()
- gets the POJO form of this map.for...in
- Can control in limited fashion.Object.keys()
.hasOwnProperty()
.getOwnPropertyNames()
in
operatorNote that JavaScript does not provide a mechanism to control the following behaviors:
Object.keys()
- Would need[OwnPropertyKeys]
symbol here..hasOwnProperty()
- Would need[OwnPropertyKeys]
symbol..getOwnPropertyNames()
- Would need[OwnPropertyKeys]
symbol.In these cases, this proposal provides a desired behavior. The actual behavior will probably not work that way and a
can-define
alternative will need to exist.for...of
can be controlled with Symbol.iterator.define behaviors
I propose two behaviors for controlling the previously listed methods, functions, and statements.
Boolean
- true if the property is enumerable, false if otherwise.getters
areenumerable: false
by default, all other properties areenumerable: true
by default.Boolean | function()
- Controls the behavior of onlyserialize
, overwrites the behavior ofenumerable
.Furthermore, all core JavaScript functions and statements should follow the
.get()
behavior:for...in
- Same asfor(var prop in map.get())
Object.keys()
- Same asObject.keys( map.get() )
.hasOwnProperty()
- Same asmap.get().hasOwnProperty( propName )
.getOwnPropertyNames()
- Same asmap.get().getOwnPropertyNames()
in
operator - Same asprop in map.get()
Examples
enumerable: undefined
enumerable: undefined
enumerable: undefined, serialize: false
for #100enumerable: false
enumerable: false
enumerable: false, serialize: true
enumerable: true
enumerable: true
enumerable: true, serialize: false
Big example
The text was updated successfully, but these errors were encountered: