[Laszlo-dev] lzBrowser.getInitArg swf9 issue or confusion?

[Sarah Allen]

Earlier in the thread, Henry said he was going to file a bug on this.   
Did this get resolved?  Does anyone have the bug #?

Thanks,
Sarah

On Mar 22, 2009, at 5:02 PM, P T Withington wrote:

> Actually, here is what I think might be a better idea:  the compiler  
> should generate a single method that takes an additional argument,  
> the method name you want dependencies for, and computes the  
> dependencies for that method. I.e., it would be a switch with the  
> bodies of what are currently individual methods. The default would  
> call the super method. I think this could reduce code size with  
> little penalty, since the dependency computation is infrequent.
>
> On Mar 22, 2009, at 19:31, P T Withington <ptw at pobox.com> wrote:
>
>> I like that idea.
>>
>> On Mar 22, 2009, at 17:40, André Bargull <andre.bargull at udo.edu>  
>> wrote:
>>
>>> Or add an interface to LzEventable to return the dependency- 
>>> function (resp. the dependencies array) for a given method.
>>>
>>>
>>>> We could have a global object, maybe use a Class , like this, and  
>>>> just
>>>> add the dependency functions
>>>> to it as properties
>>>>
>>>>
>>>>  dynamic class LzDependencies {
>>>>  }
>>>>
>>>>  class Foo {
>>>>   function getBounds () { }
>>>>   static function $lzc$getBounds_dependencies (who, self) {
>>>>      return [ self, 'rotation' , self, 'x' , self , 'y' , self ,
>>>> 'width' , self , 'height' ];
>>>>   }
>>>>  }
>>>>
>>>>  LzDependencies['Foo.getBounds'] =  Foo.$lzc 
>>>> $getBounds_dependencies;
>>>>
>>>> And the compiler would build references to dependency functions of
>>>> class.methodname as LzDependencies['class.methodname']
>>>>
>>>> So you'd have to manually enter the dependency functions into the
>>>> table, at the end of
>>>> each LFC file, like we do with the tag names now for each LFC class
>>>>
>>>> lz[LzView.tagname] = LzView;
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Mar 22, 2009 at 12:32 PM, P T Withington <ptw at  
>>>> pobox.com <http://www.openlaszlo.org/mailman/listinfo/laszlo- 
>>>> dev>> wrote:
>>>> >/ Hm. Or create a separate structure that maps methods to their  
>>>> dependency
>>>> />/ method. Presumably we'd like to eventually NOT have to  
>>>> declare everything
>>>> />/ dynamic.
>>>> />/
>>>> />/ On Mar 22, 2009, at 11:56, Sarah Allen <sarah at  
>>>> ultrasaurus.com <http://www.openlaszlo.org/mailman/listinfo/laszlo-dev 
>>>> >> wrote:
>>>> />/
>>>> />>/ yay!  thanks for the quick response on a Sunday morning...  
>>>> we'll get all
>>>> />>/ these bugs shaken out yet!
>>>> />>/
>>>> />>/ On Mar 22, 2009, at 8:53 AM, Henry Minsky wrote:
>>>> />>/
>>>> />>>/ Oh I see the bug is that the LzBrowserService class in the  
>>>> LFC is not
>>>> />>>/ declared 'dynamic', so the
>>>> />>>/ check for the dependency function gives a runtime error
>>>> />>>/
>>>> />>>/ return [].concat(lz.Browser["$lzc$getInitArg_dependencies"] ?
>>>> />>>/ lz.Browser["$lzc$getInitArg_dependencies"](this,  
>>>> lz.Browser, "url") :
>>>> />>>/ [])
>>>> />>>/
>>>> />>>/ I'll fix this, and we should look for any other LFC classes  
>>>> that are
>>>> />>>/ not declared dynamic but might be
>>>> />>>/ the target of a constraint...
>>>> /

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20090330/07f13309/attachment.html