Come disaccoppiare il SELF come parola speciale all'interno degli oggetti Rebol?

Is there an approach to removing the special qualities of these words that'd work while retaining the characteristics of each type?

Bene, quali sono queste caratteristiche? Per SELF:

1. Punta all'istanza dell'oggetto in modo che possa riflettere automaticamente.
2. Non può essere sovrascritto dal tuo codice.
3. Si presenta automaticamente senza che tu lo chieda.
4. Non viene ereditato così com'è, ma viene aggiornato per riflettere un nuovo oggetto.
5. Non viene visualizzato quando si utilizza words-of o mold .

Il punto (1) è tecnicamente possibile, ma a causa del punto (2) non puoi usare il nome auto per un SELF personalizzato (a meno che non si sia verificato un disaccoppiamento e la parola sia stata aperta per l'uso dell'utente) . Puoi ottenerlo con il bind:

document: make object! [
    x-self: bind? 'x-self
    name: "Document"
    rename: func [new-name] [
        x-self/name: new-name
    ]
]

>> document/rename "This changed name will print"
print document/name

Un "sé" creato dall'utente come x-self può ottenere un po 'di (2) con PROTECT, ma il SELF di oggi appare immune a UNPROTECT:

>> test make object! [unprotect 'self self: 10]
** Script error: cannot set/unset self - it is protected

I valori utente non possono farlo, quindi se fosse considerato auspicabile ci dovrebbe essere qualcosa che ha reso permanente la protezione.

Per l'automaticità di (3), puoi spostare la cosa auto-simile in un generatore. Quindi, andando con la teoria che SELF non è più speciale e chiamiamo quel generatore OBJECT (come generatore di oggi):

object: func [body [block!]] [
    make object! compose [
       self: bind? 'self
       (body)
    ]
]

How would this propagate to derivative objects without requiring a special word to keep tabs?

Quindi questo è (4). Se qualcuno non usa il generatore OBJECT, cosa mantiene la convenzione SELF andando in passi ereditari? Una risposta è semplicemente usare un altro generatore, ad es. un INHERIT che coordina:

inherit: func [parent [object!] body [block!]] [
    make parent compose [
        self: bind? 'self
        (body)
    ]
]

Un'idea migliore sarebbe probabilmente quella di riutilizzare il generatore OBJECT se avesse un modo di comportarsi come INHERIT basato su un altro segnale. Qualche parola chiave nella specifica o nel corpo che indica il genitore, quindi potrebbe fare l'ereditarietà in quel caso.

Nota: Affinché queste funzioni, qualcosa su SELF deve consentirgli di essere sovrascritto dalla classe base nonostante (2).

Per quanto riguarda la possibilità di nascondere il SELF nello spazio utente in (5), l'unico modo che è possibile ottenere oggi è con PROTECT / HIDE. Ma HIDE come attualmente implementato non si limita a bloccarlo dalla visualizzazione nelle enumerazioni, ma anche dai nuovi collegamenti. In questo modo viene suggerita un'altra sfumatura di significato da proteggere per discernere tra se qualcosa non è mostrato o non associabile.

Ciò solleva ulteriormente la questione sulla persistenza tra le serializzazioni. Se stampi un oggetto e SELF è invisibile, quando LOAD lo carica non ne avrebbe uno. D'altra parte, era visibile ed era un riferimento a un oggetto, hai a che fare con la serializzazione di riferimenti a oggetti nel testo. Poiché si tratta di un riferimento all'oggetto serializzato, potrebbe essere eseguito specialmente nella sintassi dello stampo rispetto a un riferimento arbitrario a un oggetto, ma poi diventa speciale di nuovo.

TL; DR - Nel caso in cui il comportamento di SELF venga relegato ai generatori, la serializzazione e la deserializzazione sono probabilmente il punto più difficile - ad es. come farlo funzionare dove il generatore non è nella foto. Tuttavia, potrebbe essere che il bisogno di un Sé non sia affatto diverso dal bisogno di PARENT, dove si presenterebbero tutti gli stessi problemi. Quindi non lascerei che ciò uccida l'idea, vale la pena pensarci.

(Come per RETURN ... gli stessi problemi di base, tranne che le persone non provano a modellare le funzioni come metodo di serializzazione ... di solito.)