Allen Wirfs-Brock <allen at wirfs-brock.com> writes:
> I think what you are doing here falls under the "newly added
> properties are not guaranteed to be visited" rule.  However, I think
> this is also one of the situations where it makes a difference on
> whether "visited" is interpreted to mean returned to the user or
> processed by this algorithm.  This is a case where "processed" was the
> intended meaning.

Ah I see - I had thought it meant "returned to the user", and therein
lay my confusion.

> Behind all this was the basic idea that an implementation was not
> required to keep looking for new properties (or changes of attributes)
> in objects that have already been processed by the algorithm.  With my
> generator algorithm and you test case, "x" only gets added to obj
> after the algorithm has already processed obj and moved on to proto_ob
> so the algorithm is allowed to ignore that added property and any
> shadowing effect it might of had.

*nods.

>> You haven't mentioned guarantees of enumeration as (whether x is
>> definitely guaranteed to be printed out in the two examples in my
>> original email) as properties that everyone in ES5 agreed upon, so I'm
>> going to continue to assume that I should specify those as permissively
>> as possible. I'd be very interested to hear if (1) is too strong though!
>
> right, (1) would require that the second predicate clause in line 10 of my generator:
>    if (desc && desc.enumerable) yield name;
> be augmented with an additional search starting with the original obj
> for a shadowing non-numerable property with the same name.  This was
> the sort of processing that some (most?) existing implementations
> didn't do and we didn't want to require it but neither did we have any
> agreemnt to forbid it.  So, either result is acceptable.  If you code
> is dependent upon either specific result for this case then you're
> screwed.  Don't do it.

That's really helpful, thanks!

I'll have a bit of a think about how best to update my property, then
might reply again to ask if what I come up with is an accurate
reflection of what you've told me.

Thanks again,

Gareth

Allen Wirfs-Brock <allen at wirfs-brock.com> writes:
> I think what you are doing here falls under the "newly added
> properties are not guaranteed to be visited" rule.  However, I think
> this is also one of the situations where it makes a difference on
> whether "visited" is interpreted to mean returned to the user or
> processed by this algorithm.  This is a case where "processed" was the
> intended meaning.

Ah I see - I had thought it meant "returned to the user", and therein
lay my confusion.

> Behind all this was the basic idea that an implementation was not
> required to keep looking for new properties (or changes of attributes)
> in objects that have already been processed by the algorithm.  With my
> generator algorithm and you test case, "x" only gets added to obj
> after the algorithm has already processed obj and moved on to proto_ob
> so the algorithm is allowed to ignore that added property and any
> shadowing effect it might of had.

*nods*.

>> You haven't mentioned guarantees of enumeration as (whether x is
>> definitely guaranteed to be printed out in the two examples in my
>> original email) as properties that everyone in ES5 agreed upon, so I'm
>> going to continue to assume that I should specify those as permissively
>> as possible. I'd be very interested to hear if (1) is too strong though!
>
> right, (1) would require that the second predicate clause in line 10 of my generator:
>    if (desc && desc.enumerable) yield name;
> be augmented with an additional search starting with the original obj
> for a shadowing non-numerable property with the same name.  This was
> the sort of processing that some (most?) existing implementations
> didn't do and we didn't want to require it but neither did we have any
> agreemnt to forbid it.  So, either result is acceptable.  If you code
> is dependent upon either specific result for this case then you're
> screwed.  Don't do it.

That's really helpful, thanks!

I'll have a bit of a think about how best to update my property, then
might reply again to ask if what I come up with is an accurate
reflection of what you've told me.