We'd need more annotation in script, since you can't (easily) tell
which class properties represent internal implementation and which
represent schema properties. We'd also have to get cracking with
allowing type declarations and optional arguments in script
(something the schema currently encodes). And, we'd have to come up
with a way of declaring which attributes can appear in the open tag
vs. only in the body (or eliminate that distinction).
In short, I think this is a nobel goal, but there is a huge gap
between schema and script.
OTOH, we already have a mechanism (as Henry describes) for deriving
schema from LZX, so perhaps an interim goal is to describe the built-
in classes in LZX for building the schema (even though their
implementation is in script). My analogy is a C function whose body
is asm();, we should have a way to write an LXZ class interface with
a body that is pure script.
On 2006-10-30, at 16:25 EST, Jim Grandy wrote:
Right, but my supposition is that there's enough information in the
LFC sources to create (most of) the in-core DOM tree using the same
mechanism. If <node> is in the base schema, then the schema rules
for <view> can be built by parsing the LFC. This would eliminate a
class of bugs and simplify the base schema enormously.
But I'm ready to believe I'm missing some fundamental gotcha that
prevents this from being feasible.
On Oct 30, 2006, at 1:20 PM, Henry Minsky wrote:
If I recall correctly, the way that the tag compiler works now,
when it sees a <class> tag, it
1) detemines the superclass name
2) looks in the schema DOM and finds the definition element that
represents the superclass
3) deep copies it
4) extends it with any new attributes that the new class declares
So the schema in-core DOM tree is dynamically extended with each
user class <class> tag
So to "bootstrap" the system, the schema has to be seeded with
some definition of each class that
you want to be able to extend in LZX.
'node' and 'view' are the most popular things to extend, but the
tag compiler can extend anything
that is declared in the base schema, since it just looks for the
superclass definition and clones it.
