You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If we could just get that information from the individual type objects, that would be much preferable.
Rough sketch: you have a type T, and you call T.slots(). An Array of Slot instances is returned. For our purposes here, it's enough that a slot has a slot.name. Later, we can extend the design of Slot into whatever #490 requires. (Accessors, whatever.) We're sticking to the name "slot" here (instead of "field" or "member" or "attribute") because going forward, we're going to be adhering pretty close to CLOS and Dylan in our object system.
What the walker script does with the attribute name attr is get the attribute by saying root[attr]. This idiom comes from a time in Alma when objects were interchangeable with dicts; they're not any more, but the idiom remains. When we remove it, we'll have to be sure to have some other general way to get an attribute from an object, either by string, or maybe the Slot can provide an actual getter function...? (Great for introspection, but a death knell for "true privacy" of private slots. On the gripping hand, my understanding as an OO language designer is that true privacy never existed in the first place, when you're either high-enough up in the MOP clouds, or low enough in the bytecode gutter. It's more like an "everyday" restriction for when you're in neither of those extremes.)
This issue can be considered fulfilled when a rebased ven-walker runs on top of a PR that provides slots on the types, and it doesn't need its own attrList because it can use the built-in instead.
The text was updated successfully, but these errors were encountered:
There's a pattern that started to show up involving type-chain.reverse.map — finding all the fields, including inherited ones, for example. Find all the uses of this pattern and extract one or more appropriate methods into Type
@vendethiel Yes. Looking closer, it happens twice in that branch, at least in that file. Once is for default stringification (recursing over all attributes), and once is for the Q-cloning in the detach method.
Both of these are kind of "internal", in the base source code of 007/Alma itself, and not in user code. On the other hand, such distinctions are kind of moot in the long run, as we attain self-hosting.
These 41 LoC:
alma/ven-walker/walker.alma
Lines 1 to 41 in 7f3d9c7
If we could just get that information from the individual type objects, that would be much preferable.
Rough sketch: you have a type
T
, and you callT.slots()
. AnArray
ofSlot
instances is returned. For our purposes here, it's enough that a slot has aslot.name
. Later, we can extend the design ofSlot
into whatever #490 requires. (Accessors, whatever.) We're sticking to the name "slot" here (instead of "field" or "member" or "attribute") because going forward, we're going to be adhering pretty close to CLOS and Dylan in our object system.What the walker script does with the attribute name
attr
is get the attribute by sayingroot[attr]
. This idiom comes from a time in Alma when objects were interchangeable with dicts; they're not any more, but the idiom remains. When we remove it, we'll have to be sure to have some other general way to get an attribute from an object, either by string, or maybe theSlot
can provide an actual getter function...? (Great for introspection, but a death knell for "true privacy" of private slots. On the gripping hand, my understanding as an OO language designer is that true privacy never existed in the first place, when you're either high-enough up in the MOP clouds, or low enough in the bytecode gutter. It's more like an "everyday" restriction for when you're in neither of those extremes.)This issue can be considered fulfilled when a rebased ven-walker runs on top of a PR that provides slots on the types, and it doesn't need its own
attrList
because it can use the built-in instead.The text was updated successfully, but these errors were encountered: