Just an experiment, and temp solution because we don't have the cycles
to fix the compiler to do it right just now. But your comments are
important -- made us realize this is not the way to go, so we will
just do the mixin by hand for now.
On Jan 22, 2008, at 15:35, André Bargull <[EMAIL PROTECTED]> wrote:
That approach will be quite confusing for an average developer:
Through LzDataElement(Trait) you would give LzNode methods like
"appendChild", "removeChild" etc.
So what will that developer try to do: "canvas.appendChild( new
lz.view() )"
-> hey, it's "append a child", so that must work!?
If you have got a base single class "MiniNode/DataElementTrait/
DataElement", what about LzDataText, will it also subclass that
class?. So, "appendChild", "removeChild" etc. for LzDataText?
Or did I misunderstand something and this is just a temporary
solution until traits are implemented in swf9?
On 1/22/2008, P T Withington wrote:
I wanted to add this to the bug, but Jira is out for now:
Expanding on that:
we want: LzMiniNode->LzDataElement(Trait)->LzNode->LzDataSet
Probably MiniNode/DataElementTrait/DataElement become a single
class DataNode.
On 2008-01-21, at 16:50 EST, Philip Romanik wrote:
Sure. I'll let you know what I find
We just had a little brainstorm about how to get the data
classes working in swf9. Tucker can chime in here
if I say something bogus below, but here's my view of what to do:
There's a problem right now because LzDataElement is implemented
using a "trait" to mix in some behavior,
and we don't have traits implemented in the compiler for swf9.
The issue is that LzDataElement mixes in a class called
"LzDataNode", and "LzMiniNode".
There's a proposal to rearrange things a little in the base
classes so that everyone inherits from LzDataNode.
So LzDataElement and other data classes would subclass
LzDataNode, and
LzNode would also subclass LzDataNode. LzDataset could then
inherit from LzDataElement. We can get rid of
LzMiniNode.
<http://www.openlaszlo.org/jira/browse/LPP-2736>http://www.openlaszlo.org/jira/browse/LPP-2736
We wanted to do some kind of benchmarking before we commit to
this, in case having this structure of classes
somehow slows down data performance. So if there were some way
you could make this change and see if the
code still works and if it doesn't slow down, then we would
proceed with this reorganization and then try to make the
code compile cleanly in swf9/devildog.
--
