On 2011-03-14, at 11:29, Donald Anderson wrote:

> Tucker and Henry,
> 
> lfc-undeclared.lzx has this:
> 
>  <interface name="node" extends="Instance">
> 
>      <!-- The comma-separated list of mixins, applied in order -->
>      <attribute name="with" type="string"/>
> 
> So we've introduced an attribute called 'with' into the LzNode schema.  And 
> when we produce reference classes, we get the illegal code: 'var 
> with:string;'.  If this is unused, I'll remove it from the schema, and I can 
> remove the cleanid code in ScriptClass.

There are at least 3 issues here:

1) Someday we want to auto-generate .rnc (and .dtd) files from the schema for 
syntax-aware editors

2) We need to have an accurate schema for them, and for the compiler to 
validate as it parses

3) LZX has a concept of 'instance-first programming' which means "anything you 
can do with a class, you can do with an instance".

The last is probably why that attribute is there on `node`, because you are 
allowed to add a mixin to a node.  But this is really a meta-attribute that 
comes (or should come) from the meta-class for node.  It's not stored as a var, 
but the schema needs to know that it is a valid attribute.  The schema language 
is probably not rich enough to really describe these meta-classes accurately 
(although we try, as you point out below).

So that's the 'deeper issue':  these attributes are not true attributes, so 
they should not be getting modeled as var slots, so you shouldn't need to 
rename them.

A klugey way around this might be to simply declare a setter for `with`.

> Everything in lfc-undeclared.lzx is a little suspect.  As you might remember, 
> it's all the random stuff that was in the original lfc.lzx (and presumed to 
> be correct).  The new auto-generated lfc.lzx needed a way to graft these 
> extra symbols not found by running js2doc.

It's less suspect than you imagine.  We've been trying to clean it up and make 
it more accurate as we go along.  Today it represents mostly information about 
special forms that can't be derived from the runtime.

> Let me know what you think.  For now, I'm removing it and see how it goes.  
> There are also these classes in lfc-undeclared.lzx:
> 
>    <interface name="interface" extends="MetaClass">
>      <attribute name="name" type="string" required="true" />
>      <attribute name="extends" type="token" value="view"/>
>      <attribute name="implements" type="token"/>
>    </interface>
> 
>    <interface name="class" extends="interface">
>      <attribute name="with" type="token"/>
>    </interface>
> 
> But since we're only generating reference classes that are in the inheritance 
> chain, I don't think these will ever be seen by the JS compiler.

They should not be.  They should only be seen by the schema compiler.

I suppose we should have a tag <metaclass> for describing these, rather than 
trying to wedge them into <interface>.

> - Don
> 
> On Mar 8, 2011, at 3:35 PM, P T Withington wrote:
> 
>> 8. ScriptClass:  I don't understand what is going on here.  If you are 
>> renaming these variables only here, it seems they must not be referenced in 
>> the first place, so I wonder why we are emitting these.  It seems there must 
>> be a deeper issue that this is papering over?
> 
> 
> --
> 
> Don Anderson
> Java/C/C++, Berkeley DB, systems consultant
> 
> voice: 617-306-2057
> email: [email protected]
> www: http://www.ddanderson.com
> blog: http://libdb.wordpress.com
> 
> 
> 
> 
> 


Reply via email to