On Tue, May 31, 2011 at 3:09 PM, Cameron McCormack wrote:
> Jonas Sicking:
>> At least in the indexedDB case we need to enumerate the object anyway
>> since we want to throw if it contains any properties that we don't
>> understand. This is for forwards compatible reasons.
>>
>> Hence we automatic
Jonas Sicking:
> At least in the indexedDB case we need to enumerate the object anyway
> since we want to throw if it contains any properties that we don't
> understand. This is for forwards compatible reasons.
>
> Hence we automatically limit ourselves to enumerable properties, so
> toString woul
On Fri, May 27, 2011 at 3:38 PM, Cameron McCormack wrote:
> Israel Hilerio:
>> > For the optional parameters variable that is expected by the
>> > IDBDatabase.createObjectStore function, would it be possible to constrain
>> > the variable to have the keyPath and autoIncrement attributes as part of
On Fri, May 27, 2011 at 2011 12:43 PM, Jonas Sicking wrote:
> -Original Message-
> From: Jonas Sicking [mailto:jo...@sicking.cc]
> Sent: Friday, May 27, 2011 12:43 PM
> To: Israel Hilerio
> Cc: public-webapps@w3.org
> Subject: Re: [indexedDB] OptionalPar
Israel Hilerio:
> > For the optional parameters variable that is expected by the
> > IDBDatabase.createObjectStore function, would it be possible to constrain
> > the variable to have the keyPath and autoIncrement attributes as part of its
> > instance members and not as part of its inheritance hie
On Fri, May 27, 2011 at 10:27 AM, Israel Hilerio wrote:
> For the optional parameters variable that is expected by the
> IDBDatabase.createObjectStore function, would it be possible to constrain
> the variable to have the keyPath and autoIncrement attributes as part of its
> instance members and n
For the optional parameters variable that is expected by the
IDBDatabase.createObjectStore function, would it be possible to constrain the
variable to have the keyPath and autoIncrement attributes as part of its
instance members and not as part of its inheritance hierarchy?
Israel
