"Member Functions" (in the era of Pure Virtual Binding)

Development Binding
5

The most coherent model yet of .WORD for member selection has made me fairly comfortable with the mechanism.

What it does is makes it so that .word captures its full environment, and is able to simulate whatever you would have gotten if you had written (.).word - where . is just the name of the "current" object. So that's good, and also lets you do peer-method calls as ./word

It's working much better than anything we've had before, so I shouldn't be too hard on it.

Raises Questions About The "Method Flag"

Today, METHOD is just a lightly tweaked version of FUNCTION, that offers the .-in-body field and coupling-extraction-behaviors.

But there are other generators... like LAMBDA and DOES and ->. Or you might make a COMBINATOR for UPARSE that lives in an object that provides it with contetxual variables, where you can make new instances of that object and get new combinators that are implicitly "adjusted" to the new instance variables. Not to mention all the ideas users might come up with...

So you should be able to turn any ACTION! into a "methodlike" action.

This might be a good repurposing of my.

obj: {
   field: 1020

   foo: my does [print [.field]]
   bar: my lambda [x] [.field + x]
   baz: my func [x y] [return x + ./bar y]
}

Note that I'm actually proposing a situation where by default, you wouldn't have visibility of field in the functions of this object otherwise, or visibility of the methods to each other. You have to use the . and the ./

But making objects with {} wouldn't be the only game in town. You'd still have something along the lines of:

ctx: context [
   field: 1020

   foo: does [print [field]]
   bar: lambda [x] [field + x]
   baz: func [x y] [return x + bar y]
]

But there'd be no expectation of derivation behaviors, e.g. creating new instances of this context where you'd change up the fields and expect the bindings to "adjust". If you want that, you're going to be using dots :dotted_line_face: (or some other level of indirection to capture a "this"-like entity)!

Keep METHOD Around As Shorthand For my func ?

This assumes we might want to keep METHOD around as a more literate way of saying my func(tion).

But maybe leaving the word METHOD free and just encouraging people to learn the pattern is better?

1 Like