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]

Reply via email to