Okay, it seems I don’t agree with the only use case you gave for redifining
getPropertyNames, but, well it doesn’t mean the feature should be dropped if
nobody else is complaining about that.
For your curiosity :
[[Since “fixing” getPropertyNames would involves returning the properties of an
My understanding of “inferred” values for the LocaleInfo object is that, when
inferred is allowed/used, that values which are not explicitly specified in the
constructor (eg: calendar), will be inferred as best as possible from the other
inputs.
For example: If I construct it with:
var
I think there would be a couple of differences between a noop-handler and a
forwarder-to-an-empty-object.
For one: defining a property on a forwarder-to-an-empty-object would
actually define the property on the empty object. AIUI, the noop handler
would silently absorb the assignment. Fixing
Hi David,
Your questions are very relevant, and we did consider some of these issues.
They are part of the reason why we split the traps into fundamental and
derived traps, and why we specified that derived traps have a default
behavior (in terms of the fundamental traps). That at least gives us
There is no particular reason an object couldn't have both .region and
.regionName properties. However, .region.name might provide the same result as
regionName. In general, you need to think about what interface makes sense
for the object you are defining. Is there ever a situation where
David,
Your intuition of what constitutes a fundamental vs. a derived trap is
correct. Strictly speaking, the Proxy API could do with just the fundamental
traps. The motivation for providing the optional derived traps was that
overriding derived traps often allows proxy implementors to implement
As stated before, I think that this approach is more error prone; that it
would be better to explicitly call the other function. Here would be the
difference between the two alternatives for the API: A and B, under the two
common scenarios:
*Scenario 1 I don't care*
A.
x = myLocaleInfo.region;
The “black box” library has no clue if the person calling the black box wants
me to infer or not, that’s up to the caller. However the black box would have
to choose which API to call. With inferred being a state of LocaleInfo though,
then it’s somewhat easy for the caller to ensure that it
I think we are missing couple details here.
In case user provides the region when constructing LocaleInfo, both .region
and .inferredRegion would be the same (i.e. there is nothing to infer).
---
data provided | US | nothing
I agree, but I don’t think that’s necessarily clear to the blackbox library.
Additionally the “inferredRegion” seems a bit harder to use, so I think maybe
the blackbox would lean towards “region” even if “inferredRegion” might be
acceptable.
And then the “black box” library has to make the
So you are saying, if library developer wanted to keep his library flexible
and avoid:
var region = loc.region;
if (region === undefined allowInferrence) {
region = loc.inferredRegion;
} else {
return error; // or fallback gracefully.
}
blocks of code, he could let end developer pass
11 matches
Mail list logo
