(Still working on the acronym.) A while ago I said…
and one of the biggest reasons phrase-properties don’t work as methods is because there’s no actual connection between the phrase and the object, just the object’s ownership of a property whose value is the phrase: a one-way relationship. There’s no self variable the phrase can make use of to get access to the object’s internal states. So then I thought, what if there… were?
To decide what phrase object -> number is the property-value of
(o - an object) for (p - (phrase object -> number) valued property):
(- {o}.{p} -).
To decide what number is (o - an object) -->
(p - (phrase object -> number) valued property):
let fn be the property-value of o for p;
decide on fn applied to o.
With that setup, we can then do:
To decide what number is the computed encumbrance of (o - an object)
(this is encumbrance-method):
decide on (100 * number of things carried by o) / (carrying capacity of o).
A person has a phrase object -> number called encumbrance.
The encumbrance of a person is usually encumbrance-method.
Joe carries an attache case and a lunch bag.
When play begins: say Joe --> encumbrance.
With his default carrying capacity of 100, we see that Joe’s two items put him at 2% encumbrance.
We could be more specific and say person instead of object there, but we’d multiply the number of variants on the first couple of phrases we need.
It’s easy to extend to other data types, and we can have up to two extra parameters – applied to can go up to three and the invoking object is eating one of them up. As with any I7 phrase, we’re limited to one return value. (Of course, one of the arguments could be a bespoke data structure object with a bunch of other parameters tucked away in its properties for the purpose of parameter-passing, just as the return value could be an object made to pass back multiple values.) We can’t directly use inline I6 phrases as methods because they can’t be named – they need to have a wrapper around them.
I have to admit, I started playing around with this as a goof to see if I could come up with some perverse way to shoehorn this into I7 and expecting it to be too ugly and tedious to ever be a real consideration, but… I think this is actually plausibly useful.
As with many things in programming, the little toy examples that make it easy to illustrate what you’re doing makes it hard to see what the point is, because it’s also easy to do another way. Where the potential power of this comes in is from the ability to create default methods based on kind that things inherit automatically, but also to be able to override them for sub-kinds or on an individual basis, and from when you’re computing results from other properties of the thing.
I’ll try to thread the needle of something complicated enough to demo this better while still short enough to apprehend later.