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]
