Suppose you have a robot object with methods like
move , attack etc. You can store a "script" in a block to automate the object

rebol []

robot: make object! [
move: func [amount] [...] ; whatever
turn: func [angle][..] 
fire: func [] [...]
run: func [code][
                   do bind code 'self
]
]

script: [
           move 100
           turn 45
           fire
           turn 23
           move 34
]
; etc

robbie: make robot []

robbie/run script

// Se si vuole montare una porzione di filesystem in un'altra porzione....

mount --bind Cartella NuovaCartella

I learn to use 2 different types of Canvas callbacks
in the last snippet.

Typically, when I wrote a non-OO code, I will use

app.body = c = Canvas()

where I already had

from appuifw import *

The shortcoming is that I need to define callbacks first,
then pass it to the constructor
c = Canvas(redraw_callback, event_callback)
By using OO, the canvas is created in __init__() and it
can access other methods that come later in the code.
In this case, I use Canvas(self.update) which means that
the self.update will be used to redraw screen.

The secode way to use callback is Canvas.bind() method.
I have always been using this approach to binding any event
callback to a canvas. In some case, the event_callback in
the constructor maybe more elegant, though.

Notice my use of

self.canvas.bind(EKeySelect, self.toggle)

Here I can bind the select key to self.toggle whose definition
will follow. This is more convenient than having to define
it first. So, I think OO code is easier to write in this way.

I also use class variables instead of instance variables.
I found declaring it outside __init__() is more natural
and similar to my previous non-OO approach.
(still easy to read, with variable & def declarations)
When I write self.myvar inside __init__(), I feel the code
is somewhat bloated. The class will have only 1 instance
anyway.

An inelegant use of find and grep, but it works.

find . | grep -e "zone" | xargs perl -pi -e 's/allow-transfer {.+?}\;//'