Thanks André. So Henry, we need to know if an as3 interface can have
static properties. Or, we need an idea of how to emulate that. Maybe
these just become static properties of the class that uses the mixin?
That's slightly more work for the js2 back-end than my previous
scheme, though.
On 2008-01-08, at 03:54 EST, André Bargull wrote:
These two traits/mixins have got static vars resp. functions:
"LzDataNode" and "LzDataElementTrait"
- "LzDataElementTrait.valueToElement(..)"
- "LzDataElementTrait.__LZv2E(..)"
- "LzDataNode.ELEMENT_NODE, TEXT_NODE, DOCUMENT_NODE"
- "LzDataNode.__LZescapechars"
- "LzDataNode.stringToLzData(..)"
- "LzDataNode.whitespaceChars"
- "LzDataNode.trim(..)"
I haven't come across it used yet in any of our LFC code, just wanted
to watch out in case it showed up.
On Jan 7, 2008 4:54 PM, P T Withington <[EMAIL PROTECTED] wrote:
In our (ill-defined) mixin's, we allow both static vars and
functions. Not sure how we would implement that in JS2 though,
because I don't think and interface allows either. If an interface
does, we are all set. Perhaps you should try it?
Do we use this feature? If we do, we'll have to figure out a way to
support it, I guess.
On 2008-01-07, at 16:40 EST, Henry Minsky wrote:
Can you have static "class variables" declared on a mixin?
On Jan 7, 2008 4:31 PM, P T Withington <[EMAIL PROTECTED] wrote:
We have a plan!
A _mixin_ (we need to update our terminology) is really just an
_interface_ with implementation. The JS2 back end, when it
sees a
mixin has to remember the implementation, and has to emit an
interface
declaration (i.e., copy the declaration through, stripping out
any
implementation -- actually, initially, it could leave out the
body
altogether I think). Then, for each class that uses that mixin:
mixin amixin { <body of amixin };
mixin bmixin { <body of bmixin };
class aclass extends anotherclass with amixin, bmixin
{ <body of
aclass };
the compiler has to emit 'interstitial' classes:
interface bmixin {};
class lzsc::bmixin$anotherclass extends anotherclass
implements
bmixin {
<body of bmixin
};
interface amixin {};
class lzsc::amixin$bmixin$anotherclass extends lzsc::bmixin
$anotherclass implements amixin {
<body of amixin
}
class aclass extends lzsc::amixin$bmixin$anotherclass
implements
amixin, bmixin { <body of aclass }
Don, if we don't have a task filed for this, please file one.
On 2008-01-07, at 16:08 EST, Henry Minsky wrote:
So what should we do with traits, I wonder.
On Jan 7, 2008 3:36 PM, P T Withington <[EMAIL PROTECTED] wrote:
Remember Class.lzs is really just the runtime support for JS2
class
semantics in a JS1 runtime. So the goal is to have that be
unused in
a JS2 runtime (like swf9).
On 2008-01-07, at 15:34 EST, P T Withington wrote:
I agree.
I'm just not sure if we need a UserClass (that is a
subclass of
view) that these classes inherit from, or if they can just
directly
inherit from view (or some other lfc class). There is some
stuff
that happens in UserClass that is different from node.
On 2008-01-07, at 15:30 EST, Henry Minsky wrote:
I think the most pragmatic thing to do is to bite the bullet,
so to
speak, and make
the tag compiler emit class { .... } declarations for user-
defined
classes. It seems like
the alternative would be to use our Class.lzs in swf9 for
user-
defined classes
at runtime, which seems like it would cause all sorts of
confusion.
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
-- Henry Minsky Software Architect [EMAIL PROTECTED]
