No, I think devildog is the right target for this. We have a working
solution for JS1 already, so we just need to add this to the js2 back
end. As we do, we may decide to restrict what you can do with a mixin
to what is easy to implement, which would mean tightening up the js1
implementation.
On 2008-01-07, at 17:30 EST, Donald Anderson wrote:
It was already filed in JIRA as:
http://www.openlaszlo.org/jira/browse/LPP-5266
It's marked for Devildog, possibly it needs to be more encompassing
than that.
I just added the recent emails as comments to the JIRA.
On Jan 7, 2008, at 4:31 PM, P T Withington 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]
--
Don Anderson
Java/C/C++, Berkeley DB, systems consultant
voice: 617-547-7881
email: [EMAIL PROTECTED]
www: http://www.ddanderson.com