objects: replace the OpenQM description with its actual syntax
The page described OpenQM "in shape only" because its documentation site
was down, and second-hand accounts turned out to be wrong in ways that
mattered. Read out of its GPL source instead (ScarletDME, the maintained
fork of the Ladybridge release, GPL-2.0 -- the same licence as MVX):
CLASS name [MAX.ARGS n] [INHERITS class1, class2, ...]
PUBLIC FUNCTION / SUB / SUBROUTINE, and PRIVATE
GET and SET give properties -- the compiler treats GET as a public
function and SET as a public subroutine
CREATE.OBJECT is the constructor, and must be a PUBLIC SUBROUTINE
ME is the self-reference, with its own opcode
OBJECT(name, args...) instantiates
-> is member access, tokenised TKN_OBJREF from '-' followed by '>'
INHERITS takes a LIST, so inheritance is multiple
Three of those change the note rather than decorate it:
- GET/SET is a real answer to the second failure in section 1, and a
better one than the public slot this note sketches. Recorded as the
first thing to decide if this ever becomes a proposal, with its cost
named: every property access becomes a dispatch.
- INHERITS disproves what section 7 claimed. That section rejected
inheritance because it "forces a vtable and a linker-visible class
graph"; OpenQM implements MULTIPLE inheritance by giving each
inherited class a private variable of its own name -- delegation, no
vtable. The claim is withdrawn in the text and the narrower honest
reason put in its place, because a design note that leaves a
disproved claim standing is worth less than one that says so.
- '->' was derived here from MVX's own lexer before OpenQM's source
could be read, and OpenQM tokenises the same two characters. Now
stated as convergence from the same constraint rather than left to
read as a borrowed convention.
objects: bind the theory page to its tracking issue (#195)
The page said 'no issue is open'. One is now: mvx#195 tracks the
question -- whether the language should name what MV already builds by
hand -- not any work, and the status line says so rather than implying
something is scheduled.
Matches how open-dict.md carries (spike, #25) in its H1.
Classes and objects: a theory page
An experimental design note on what classes would mean in Pick BASIC.
Nothing is built and no issue is open; the page exists so the design can
be argued before anyone commits to it.
The thesis is that MV already builds objects by hand -- a catalogued
subroutine, a named COMMON block and a dynamic array -- and what is
missing is instances and a boundary, not classes as such.
Prior art was checked rather than recalled: UniVerse BASIC 11.2 has ZERO
occurrences of CLASS and UniData's reference has zero, so the comparison
is not UV-classes against QM-classes. It is the UV/Pick idiom against
OpenQM's class module, and the page weighs both. OpenQM's own syntax is
described in shape only, said out loud, because its reference could not
be reached.
Every claim about MVX cites a file, and each was checked before it was
written -- there are no measurements here, so that is the page's only
credential. Two of those checks changed the design:
- '.' is an identifier character, so ORD.TOTAL is a legal variable name
and dot-notation fails the extension bar outright. '->' lexes as
Minus Gt, which cannot occur in valid classic code -- the same
argument DECISIONS.md already accepted for C-style comments.
- mv_copy and mv_clear guard on tag == MV_STR and nothing else, so an
object that IS a string is refcounted and released with no runtime
change at all, and serialises, prints and diffs for free. That is
what makes the value-semantics design cheaper than a new tag, and the
rejected alternative says what it costs.
Registered in _Sidebar.md under the language page, labelled (theory)
there as well as in the H1, so nobody arriving from the nav mistakes it
for shipped behaviour.