SPICE-0020: Deferred, type-safe references#1354
Conversation
HT154
force-pushed
the
reference-t
branch
4 times, most recently
from
6bd5bfc to
14a7c24
Compare
HT154
force-pushed
the
reference-t
branch
4 times, most recently
from
d7663a8 to
09ac8d7
Compare
HT154
force-pushed
the
reference-t
branch
9 times, most recently
from
c61ce90 to
0085962
Compare
HT154
force-pushed
the
reference-t
branch
4 times, most recently
from
ce06670 to
98a918f
Compare
HT154
changed the title
Reference<T>
| } | ||
|
|
||
| /// Represents a property or subscript access as part of a [Reference]. | ||
| external class Access { |
There was a problem hiding this comment.
[nit] "AccessPart" feels like a better name for this.
Also, I don't think this needs to be an external class; it's helpful if users can new up these values and play around with them.
| external class Access { | |
| class AccessPart { |
There was a problem hiding this comment.
Hmm I'm not convinced re: naming. Each pkl.ref#Access corresponds to a qualified access or subscript [access].
| |`<value>` | ||
| |Root value | ||
| |link:{uri-messagepack-array}[array] | ||
| |Array of link:{uri-stdlib-ReferenceAccess}[property access] values |
There was a problem hiding this comment.
This is also missing domain.
Food for thought: should this also include the referent type? This might be really useful for the language binding use-case. If we do, I'm not totally sure how that would work.
There was a problem hiding this comment.
If we were to include this, it would mean adding another slot to the table (not a big deal). It would also probably mean encoding the referent as an array of Class and TypeAlias (stdlib U?Int\d+ types only) values. Maybe a future enhancement?
| external property: String(key == null)? | ||
|
|
||
| /// If the access is access via subscript. | ||
| external isSubscript: Boolean |
There was a problem hiding this comment.
This is a binary condition; it's either property or entry access. Do we need two booleans?
There was a problem hiding this comment.
This is for ease/fluency of use: if a user is writing e.g. a function that transforms a Reference to a String, they may need to know whether each access is a subscript key or property; it may be necessary to check one way or the other and access.isSubscript is more meaningful than !access.isProperty (and vice versa).
Another alternative here is something like this:
type: "property" | "subscript"But that makes usage sites pretty verbose!
Curious if you have thoughts or alternative suggestions here.
| /// | ||
| /// Limitations: | ||
| /// * Type constraints are ignored (erased) when referenced. | ||
| /// * Properties marked `external` may not be referenced. |
There was a problem hiding this comment.
I think this should explain how to use it, complete with some examples.
We tend to provide really long doc comments when the use-case is advanced. For example, the doc comments within pkl:Project are quite long.
3 participants
SPICE: apple/pkl-evolution#27
Resolves #912