setters in swf9

Hi Henry,

What is the "new" way to handle setters in swf9? The solution you're 
using in LaszloView looks like,

static var setters = new LzInheritedHash(LFCNode.setters);
...
LFCView.setters.clip = -1;

Should I use this same approach with the files I'm porting?

Thanks!

Phil

For Review: Change 20080201-lou-b Summary: add text.format() to the Text chapter of the dguide

Change 20080201-lou-b by lou <at> loumac.local on 2008-02-01 11:31:08 AST
     in /Users/lou/src/svn/openlaszlo/trunk
     for http://svn.openlaszlo.org/openlaszlo/trunk

Summary: add text.format() to the Text chapter of the dguide

Bugs Fixed: LPP-5400

Technical Reviewer: (ptw)
QA Reviewer: (pending)
Doc Reviewer: (pending)

Documentation:

Release Notes:

Details:
added new section
http://localhost:8080/trunk/docs/developers/text.html#textformat

Files:
M      docs/src/developers/text.dbk
A      docs/src/developers/programs/textformat.lzx

Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20080201-lou- 
b.tar

For Review: Change 20080201-lou-v Summary: update copyright to 2008 for dguide and reference

Change 20080201-lou-v by lou <at> loumac.local on 2008-02-01 12:07:52 AST
     in /Users/lou/src/svn/openlaszlo/trunk
     for http://svn.openlaszlo.org/openlaszlo/trunk

Summary: update copyright to 2008 for dguide and reference

Bugs Fixed: LPP-5377

Technical Reviewer: (pending)
QA Reviewer: (pending)
Doc Reviewer: (pending)

Files:
M      docs/src/reference/book-info.dbk
M      docs/src/build.xml
M      docs/src/deployers/deployers-index.dbk
M      docs/src/xsl/common-html.xsl
M      docs/src/developers/book-info.dbk
M      quick-index.xslt

Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20080201-lou- 
v.tar

Re: setters in swf9

Yes, look at LaszloView.js or LzText.js for examples what I've been
doing. I declare static class vars like  this, which make copies of
the superclass's setters vars

    static var getters = new LzInheritedHash(LFCNode.getters);
    static var defaultattrs = new LzInheritedHash(LFCNode.defaultattrs);
    static var options = new LzInheritedHash(LFCNode.options);
    static var setters = new LzInheritedHash(LFCNode.setters);
    static var __LZdelayedSetters:* = new
LzInheritedHash(LFCNode.__LZdelayedSetters);
    static var earlySetters:* = new LzInheritedHash(LFCNode.earlySetters);

And the base constructor in LFCNode (which is the 'static' version of
LzNode, see core/LzNode.js) automatically copies these class vars to
the corresponding instance vars when a node is constructed.

Note, there's an issue at runtime that comes up if you have code which
tries to set arbitrary properties on
a class which have not been declared at compile time. To allow this,
the class has to be declared 'dynamic'.
Eventually we're going to make <attribute> declarations cause
compile-time declarations of instance vars, but we don't do that yet
so I've been doing the following thing:

I have an idiom I am using in LzNode and LzView whereby I have an
"internal" class, LFCNode, or LFCView, which is not declared
'dynamic', and then I have a kind of 'wrapper' class which I declare
as 'dynamic', (e.g., LzNode, LzView). This is to get the (hoped for)
benefit of the as3 compiler making more efficient
code for  accessors to methods and instance vars of  these

Re: setters in swf9

Re: setters in swf9

We don't have anything that calls the  static  class initialize method
at all , actually, because we're
not using Tucker's class system anymore. So if we come across any
static initialize method,  we need to do whatever it is doing some
other way.
In this case it looks like it's just adding entries to the setters list.

The way I've been doing setters is to declare at the top level of the
class a static class var 'setters' which gets initialized with a new
copy of the superclass setters list (via new
LzInheritedHash(SUPERCLASS.setters)).

Then I just have statements that add stuff to this var

setters.blah = "setBlah"

So in this case, we need to initialize the setters var from the parent
class. So what are the setters
in the superclass? LzDataText extends LzMiniNode_DataNode , so I guess
we should declare, but I
don't see any setters in that class or in LzMiniNode, so we can just
declare a setters
var in LzDataText I think

static var setters = new LzInheritedHash();
setters.ownerDocument = "setOwnerDocument";

Or more compactly

static var setters = new LzInheritedHash({ownerDocument: "setOwnerDocument"});

For LzMiniNode_DataNode_DOM, we need to do the same thing, get rid of
that static initialize method, and
just declare the setters the same way

    static var setters:* =new LzInheritedHash({name1: val1, etc});

Then in any subclass you need to use the idiom of

    static var setters = new LzInheritedHash(SUPERCLASS.setters);
to inherit the setters.

I haven't figured out a more automagic way to do this.

On Fri, Feb 1, 2008 at 11:37 AM, Philip Romanik
<promanik <at> laszlosystems.com> wrote:
>
>  Hi Henry,
>
>  There is code in the data classes that specify setters. For example, this
> code is in LzDataText.lzs:
>
>  setters.data = "setData";
>
>
>  Can this be done in a static initializer? The original traits use this
> method to install setters. The code compiles in swf9 but I don't know if it
> works. For example, in the class LzMiniNode_DataNode_DOM (my manually
> instantiated class):
>
>      static function initialize (prototype) {
>        // There will be no setters property in the trait prototype,
>        // (and you don't want one there! as it would shadow the one
>        // from LzNode) but it will be there after LzNode.initialize
>        // runs
>        if (prototype.hasOwnProperty('setters')) {
>          // since you can't assign directly to these slots...
>          // until LzNode.initialize has run
>          prototype.setters.attributes = "setAttrs";
>          prototype.setters.childNodes = "setChildNodes";
>          prototype.setters.nodeName = "setNodeName";
>          // Shouldn't be directly settable
>          prototype.setters.ownerDocument = "setOwnerDocument";
>
>
>        }
>      }
>
>
>
>
> Yes, look at LaszloView.js or LzText.js for examples what I've been doing. I
> declare static class vars like  this, which make copies of the superclass's
> setters vars
>
>      static var getters = new LzInheritedHash(LFCNode.getters);
>      static var defaultattrs = new LzInheritedHash(LFCNode.defaultattrs);
>      static var options = new LzInheritedHash(LFCNode.options);
>      static var setters = new LzInheritedHash(LFCNode.setters);
>      static var __LZdelayedSetters:* = new
> LzInheritedHash(LFCNode.__LZdelayedSetters);
>      static var earlySetters:* = new LzInheritedHash(LFCNode.earlySetters);
>
>  And the base constructor in LFCNode (which is the 'static' version of
> LzNode, see core/LzNode.js) automatically copies these class vars to the
> corresponding instance vars when a node is constructed.
>
>
>  Note, there's an issue at runtime that comes up if you have code which
> tries to set arbitrary properties on a class which have not been declared at
> compile time. To allow this, the class has to be declared 'dynamic'.
>  Eventually we're going to make <attribute> declarations cause compile-time
> declarations of instance vars, but we don't do that yet so I've been doing
> the following thing:
>
>  I have an idiom I am using in LzNode and LzView whereby I have an
> "internal" class, LFCNode, or LFCView, which is not declared 'dynamic', and
> then I have a kind of 'wrapper' class which I declare as 'dynamic', (e.g.,
> LzNode, LzView). This is to get the (hoped for) benefit of the as3 compiler
> making more efficient code for  accessors to methods and instance vars of
> these superclasses because they are not declared dynamic.
>
>  For the data classes, I think they can all just be left as they are, and
> not declare them dynamic, and see if we can get them to compile.
>  For now if something subclasses LzNode, just leave it doing that.
>  Eventually we may want to make that subclass LFCNode instead. At runtime,
> if we discover that there are classes where code which is adding properties
> dynamically at runtime, we can see about making a 'dynamic' subclass for
> those classes, or just declare them dynamic, or something.
>
>
>
>
>  On Fri, Feb 1, 2008 at 10:27 AM, Philip Romanik <
> promanik <at> laszlosystems.com> wrote:
>  > Hi Henry,
>  >
>  >  What is the "new" way to handle setters in swf9? The solution you're
>  > using in LaszloView looks like,
>  >
>  >  static var setters = new LzInheritedHash(LFCNode.setters);  ...
>  >  LFCView.setters.clip = -1;
>  >
>  >
>  >  Should I use this same approach with the files I'm porting?
>  >
>  >  Thanks!
>  >
>  >  Phil
>  >
>  >
>
>
>
>  --
>  Henry Minsky
>  Software Architect
>  hminsky <at> laszlosystems.com

--

-- 
Henry Minsky
Software Architect
hminsky <at> laszlosystems.com

Re: For Review: Change 20080201-lou-b Summary: add text.format() to the Text chapter of the dguide

approved

On 2008-02-01, at 10:43 EST, Lou Iorio wrote:

> Change 20080201-lou-b by lou <at> loumac.local on 2008-02-01 11:31:08 AST
>    in /Users/lou/src/svn/openlaszlo/trunk
>    for http://svn.openlaszlo.org/openlaszlo/trunk
>
> Summary: add text.format() to the Text chapter of the dguide
>
> Bugs Fixed: LPP-5400
>
> Technical Reviewer: (ptw)
> QA Reviewer: (pending)
> Doc Reviewer: (pending)
>
> Documentation:
>
> Release Notes:
>
> Details:
> added new section
> http://localhost:8080/trunk/docs/developers/text.html#textformat
>
>
> Files:
> M      docs/src/developers/text.dbk
> A      docs/src/developers/programs/textformat.lzx
>
>
> Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20080201-lou-b.tar

Some questions about mixins (LPP-5266)

1) Do we allow forward references:

   class X with M1 { .... }
   mixin M1 { .... }

I expect yes - this wouldn't be hard since we get the whole source
tree at one time.

2) When compiling an app, do we allow references to traits in included  
libraries/LFC?
I want to say yes, but this would certainly make things tougher.
Right now, the LFC is compiled into a .swc, so there isn't
any readily accessible source information about
the mixins it contains.  I could think of some hacks to accomplish
that, but I'd rather not go there.

3) Is there any real work here that needs to be done for JS/SWF8?
Is it just deprecating keyword 'trait' to prefer 'mixin'?

4) Is this work in devildog only?

--

Don Anderson
Java/C/C++, Berkeley DB, systems consultant

voice: 617-547-7881
email: dda <at> ddanderson.com
www: http://www.ddanderson.com

Re: Some questions about mixins (LPP-5266)

On 2008-02-01, at 15:40 EST, Donald Anderson wrote:

> 1) Do we allow forward references:
>
>  class X with M1 { .... }
>  mixin M1 { .... }

We haven't in the past, but it is a common request, so IWBN.

> I expect yes - this wouldn't be hard since we get the whole source
> tree at one time.
>
> 2) When compiling an app, do we allow references to traitsXXXXXX

mixins

> in included libraries/LFC?
> I want to say yes, but this would certainly make things tougher.
> Right now, the LFC is compiled into a .swc, so there isn't
> any readily accessible source information about
> the mixins it contains.  I could think of some hacks to accomplish
> that, but I'd rather not go there.

In and ideal world, but not for now -- there is no need at present.   
(It would mean saving the compiler database of mixins out on the side  
as 'linkage' information.)

> 3) Is there any real work here that needs to be done for JS/SWF8?
> Is it just deprecating keyword 'trait' to prefer 'mixin'?

You don't _have_ to do anything for swf8 (or DHTML).  OTOH, swf8/DHTML  
(i.e., JS1) would make a good testbed, since it is known to be  
working.  Essentially you would be moving to compile-time what is  
currently done at run-time by lfc/compiler/Class.lzs#Trait (in  
particular Trait.makeInterstitial).  This might be beneficial for JS1  
because it will remove some runtime overhead, but we can make the  
decision to take the change or not based on measurement.  (N.B.: There  
is one tricky bit you will have to worry about since there are no  
interfaces in JS1, you will have to provide an implementation of Trait. 
$lzsc$isa, the runtime support for `is` on a mixin.)

> 4) Is this work in devildog only?

I would prototype it in devildog, in the common path for JS1/2.  You  
can test/debug in JS1 (swf8 and/or DHTML, where you have Firebug to  
help you) if that is helpful.  If JS1 benchmarks equal or better with  
the change, let's take it to trunk, on the theory it is better to have  
fewer different paths through the compiler.  If for some unforseen  
reason JS1 benchmarks worse, we can push the code down into the JS2- 
only path.

Re: [Laszlo-checkins] r7919 - in openlaszlo/trunk: WEB-INF/lps/lfc/compiler docs/src/nav

It should probably be noted in this doc:

1. You don't _have_ to include the <debug> tag.  By default, the debug  
window will be sized to fit the lower 1/2 of the canvas, and can be  
resized as necessary.

2. The easiest way to enable debugging is with the Debug checkbox in  
the developer console (q.v.).

3. (quibble) Is 'hotlink' the best term?  The point is that objects  
displayed by the debugger are 'inspectable', and we are trying to  
convey that in a simple example.

Feel free to file this as a doc bug if you don't want to address it now.

On 2008-01-29, at 16:38 EST, dda <at> openlaszlo.org wrote:

> Author: dda
> Date: 2008-01-29 13:38:11 -0800 (Tue, 29 Jan 2008)
> New Revision: 7919
>
> Modified:
>   openlaszlo/trunk/WEB-INF/lps/lfc/compiler/LzRuntime.lzs
>   openlaszlo/trunk/docs/src/nav/toc.xml
> Log:
> Change 20080129-dda-v by dda <at> lester.local on 2008-01-29 15:11:33 EST
>    in /Users/dda/laszlo/src/svn/openlaszlo/trunk-doc
>    for http://svn.openlaszlo.org/openlaszlo/trunk
>
> Summary: doc: brought 3.0 material into <debug> reference page
>
> New Features:
>
> Bugs Fixed: LPP-4636
>
> Technical Reviewer: promanik (pending)
> QA Reviewer: (pending)
> Doc Reviewer: liorio (pending)
>
> Documentation:
>
> Release Notes:
>
> Details:
>    Added the text and the example from the old refguide into the  
> javadoc for Debug.
>    Removed the TODO from the toc.
>
> Tests:
>
>
>
> Modified: openlaszlo/trunk/WEB-INF/lps/lfc/compiler/LzRuntime.lzs
> ===================================================================
> --- openlaszlo/trunk/WEB-INF/lps/lfc/compiler/LzRuntime.lzs	 
> 2008-01-29 21:19:35 UTC (rev 7918)
> +++ openlaszlo/trunk/WEB-INF/lps/lfc/compiler/LzRuntime.lzs	 
> 2008-01-29 21:38:11 UTC (rev 7919)
> @@ -1,7 +1,7 @@
> /* -*- mode: JavaScript; c-basic-offset: 2; -*- */
>
> /**
> -  * @copyright Copyright 2001-2007 Laszlo Systems, Inc.  All Rights  
> Reserved.
> +  * @copyright Copyright 2001-2008 Laszlo Systems, Inc.  All Rights  
> Reserved.
>   *            Use is subject to license terms.
>   *
>   * @access private
> @@ -80,11 +80,32 @@
>   var Debug;
>
>   /**
> -    * Automatically created when an application is
> -    * compiled in debug mode (requested by either using the
> -    * <xref linkend="LzCanvas"/> <code>debug='true'</code>  
> attribute or by loading the
> -    * application using the <code>?debug=true</code> option).
> +    * The <tagname>debug</tagname> tag controls the initial  
> appearance
> +    * and options of the debugger when debugging is enabled.   
> Debugging is
> +    * enabled either by including the <code>debug="true"</code>  
> option on
> +    * the <xref linkend="LzCanvas"><tagname>canvas</tagname></xref>  
> tag,
> +    * or adding the <code>?debug=true</code> query argument to the
> +    * application's URL.
>     *
> +    * <example title="debug tag"><programlisting><![CDATA[
> +    * <canvas debug="true" height="120">
> +    *   <debug width="300" height="50" x="5" y="5" fontsize="8"/>
> +    *   <script>
> +    *   Debug.write("Hello world!");
> +    *   Debug.warn('This is a hotlink: %w', {a: 1, b: 2});
> +    *   </script>
> +    * </canvas>]]>
> +    * </programlisting></example>
> +    *
> +    *
> +    * The debug tag controls the appearance of the debugger when
> +    * debugging is on. It does not cause the application to be
> +    * compiled with debugging mode enabled. Only the debug option on
> +    * the canvas and the debug query parameter of the URL do this.
> +    *
> +    * For more information, see the
> +    * <a href="${dguide}debugging.html">Debugging</a> chapter of  
> the Guide.
> +    *
>     * @shortdesc The Laszlo debugger
>     * @keywords private_constructor
>     * @access public
>
> Modified: openlaszlo/trunk/docs/src/nav/toc.xml
> ===================================================================
> --- openlaszlo/trunk/docs/src/nav/toc.xml	2008-01-29 21:19:35 UTC  
> (rev 7918)
> +++ openlaszlo/trunk/docs/src/nav/toc.xml	2008-01-29 21:38:11 UTC  
> (rev 7919)
> @@ -237,7 +237,7 @@
>     </category>
>
>     <category title="Development">
> -        <item title="debug (Debug) [LPP-4936]" href="Debug 
> +debug.html"/>
> +        <item title="debug (Debug)" href="Debug+debug.html"/>
>         <item title="SyncTester" href="lz.SyncTester.html" />
>         <item title="Test" href="lz.Test.html" />
>         <item title="TestCase" href="lz.TestCase.html" />
>
>
> _______________________________________________
> Laszlo-checkins mailing list
> Laszlo-checkins <at> openlaszlo.org
> http://www.openlaszlo.org/mailman/listinfo/laszlo-checkins