-
Notifications
You must be signed in to change notification settings - Fork 37
Final change suggestion #25
Comments
The shorthand syntax (your 4) was removed from the proposal a while back, and the suggestion of having declarations be Also, personally I quite like the symmetry in |
I share @VAlley's analysis here. |
@bakkot's analysis (autocorrect) |
@bakkot I'm happy to see (1) & (4). As for the remaining suggestions, no one on the thread you linked mentioned an argument in favor of (2). If (2) were accepted, (3) would be a natural requirement. The argument in favor of (2) has to do with the changes (that I'm sure you've already coded in v8) to variable declaration semantics. ............ you know what? I argued myself into a corner that I couldn't get out of logically when thinking about (2). The overloaded meaning for Oh well. ¯_(ツ)_/¯ |
@littledan This thread will contain the last suggestions I'm going to make. I'm taking into account your issue with
[]
being "two completely different meanings... punned onto the same token". My new suggestion is a compromise. You've currently got 3 completely different meaning punned onto#
. If my approach is bad in your eyes, your's is logically worse. So try this:class
as syntactic sugar should be a primary goal.#
act only as a "private scope access" token. That way it has exactly 1 meaning in the context of aclass
.private #name
for declarations. Since the sigil is a "private scope access" token, it cannot be used alone to declare, henceprivate
.#x
) for access notation. Consider that if a variable is not declared, but used within a particular scope, it is treated as though it extends[[Global]]
. Since#
cannot declare, by default it would try to access[[Global]].#x
which does not exist and cannot be dynamically created, especially since it's outside of anyclass
definition of[[Global]]
would need to be, but wouldn't be an instance. Thus, naturally a TypeError.These 4 changes to your proposal would directly address all but 1 of my objections to your proposal. The last issue (the use of
this.#x
without allowing eitherthis["#x"]
orthis[#x]
) is indirectly resolved by (2). Since the#
is a "private scope access" token,this.#x
resolves tothis.[[PrivateScope]].x
. As such, the key name "x" is on the[[PrivateScope]]
which is inconsistent withthis["#x"]
where the key name is "#x". Further, since withthis[#x]
the key name is not a string, but an impossible variable name due to (4), it is also invalid. This means the new suggestion is completely in keeping with your proposal and objections while removing the issues I outlined in my previous suggestion.The text was updated successfully, but these errors were encountered: