On 4/7/10 1:52 PM, P T Withington wrote:
On 2010-04-07, at 16:23, Max Carlson wrote:
On 4/7/10 12:58 PM, P T Withington wrote:
As with any little bit of OL that you start poking your nose into, it's always
more complex than you imagine.
I started tackling http://jira.openlaszlo.org/jira/browse/LPP-7344 thinking
that all I would need to do is take away the type declarations on LzDelegate
and enable the runtime warnings that are used in lieu of type declarations for
the non-typed runtimes.
Well, that was a start. That covers the case of someone trying to constrain to
a property of an object that is not an LzEventable. But the case in
http://jira.openlaszlo.org/jira/browse/LPP-7958 which is related, is actually
because someone is trying to constrain to a method of a non-dynamic object. In
as3, this results in a type error, because the code that is looking for the
dependency function will fail on a sealed object, rather than just returning
null.
Great!
To fix this issue, I propose moving the function dependency calculation into a
runtime support routine that will catch the type error.
I wonder what the overhead will be? Can we do this just for debug mode?
It's a time-space tradeoff. I suggest moving it 'out of line' into a function,
because I'm concerned about inserting a try-block around every inline function
dependency computation.
I think the out-of-line is the right choice because a) function dependencies
are rare, and b) these dependency methods only get evaluated once at applyArgs
time, not over and over.
Okay, sounds good - we'll see how it affects things. FWIW, here's a
list of the dependencies in the LFC:
./data/LzDataElement.lzs:249:function $lzc$getAttr_dependencies (who ,
self) :Array {
./data/LzDataElement.lzs:306:function $lzc$hasAttr_dependencies (who:*,
self:*) :Array {
./data/LzDataElement.lzs:318:function $lzc$getFirstChild_dependencies
(who:*, self:*) :Array {
./data/LzDataElement.lzs:330:function $lzc$getLastChild_dependencies
(who:*, self:*) :Array {
./data/LzDataNode.lzs:174:function $lzc$getPreviousSibling_dependencies
(who:*, self:*) :Array {
./data/LzDataNode.lzs:189:function $lzc$getNextSibling_dependencies
(who:*, self:*) :Array {
./data/LzDatapointer.lzs:306:function $lzc$xpathQuery_dependencies (who,
self, p) :Array {
./views/LaszloView.lzs:2183:function $lzc$getBounds_dependencies ( who ,
self ){
./views/LaszloView.lzs:2559:function
$lzc$setAttributeRelative_dependencies ( who,self, prop ,
./views/LaszloView.lzs:2625:function
$lzc$getAttributeRelative_dependencies( who,self, prop ,
./views/LaszloView.lzs:2718:function
$lzc$getMouse_dependencies(...ignore ) {
./views/LaszloView.lzs:3112:function $lzc$getCurrentTime_dependencies (
who, self ) :Array {
./views/LaszloView.lzs:3130:function $lzc$getTotalTime_dependencies (
who, self ) :Array {
./views/LaszloView.lzs:3697:function
$lzc$isMouseOver_dependencies(...ignore ) {
./views/LzText.lzs:1166: function $lzc$getTextWidth_dependencies ( who
, self){
./views/LzText.lzs:1177: function $lzc$getTextHeight_dependencies ( who
, self){
./views/LzText.lzs:1211: function $lzc$getMaxScroll_dependencies ( who
, self){
./views/LzText.lzs:1418: function $lzc$getText_dependencies ( who , self){
Finally, we can't do it only for debug mode unless you want the situation that
started me down this path -- the user who complained that his app works in
debug mode (which catches and neuters all errors) but fails when he turns off
debugging. I think we want to always catch and ignore these errors (because
that is the LZX way, inherited from swf8). We just need to decide if we
_always_ want to warn about these, or if we want a special 'debug constraints'
mode that turns on these warnings.
Right, got it.
The question is: when you constrain to function that does not have a
dependencies method, should you get a warning (because you might wonder why
your constraint does not update) or should it silently succeed (because that is
what happens in swf8 and DHTML right now)?
It seems like you might want to be able to constraint to arbitrary functions
and have the event system default to lz.Idle.onidle as a dependency. There
should still be a warning in debug mode, so folks know to update this for
efficiency.
I would rather make there be a way for people to write the dependency method
for an arbitrary function.
Sounds fair. I'll file an improvement for this.
Also, while trying to make the error message that you get more useful (by telling you
which constraint it is that is not getting its dependencies right), I notice that we get
a pile of "failed" dependencies already, that are just silently ignored. These
seem to come from dependencies that perhaps are evaluated too soon and hence the context
of the event they want to listen to does not yet exist. It seems we might want to get a
warning on those too?
That would be great!
Again, the question is whether we want to do this always, or have a mode for it.
It sounds like there should be a mode for this to keep from being
flooded by warnings - but that could be added as an improvement later,
perhaps with the special 'debug constraints' mode you mentioned above.
