Sloppy me.  The compiler inserts runtime checks.  I'm not saying the  
compiler could detect this at compile time.  (So if we enabled those  
checks and ran in swf where the error is non-fatal we could find  
these, perhaps more quickly than in DHTML).

On 2006-04-12, at 13:01 EDT, Jim Grandy wrote:

> Forgive me, but how does the compiler know in this case? This could  
> only found using call chain analysis or at runtime. Statically, the  
> attribute is a function -- it was declared to have a function  
> value. It is only in certain runtime conditions that the attribute  
> is reset to null.
>
> On Apr 12, 2006, at 9:58 AM, P T Withington wrote:
>
>> In debug mode, the compiler will emit a warning if you try to call  
>> a non-function.
>>
>> On 2006-04-12, at 12:43 EDT, Jim Grandy wrote:
>>
>>> I haven't checked, but would the compiler really catch this  
>>> technique?
>>>
>>> LzView.prototype.__LZcheckwidth = function () { ... }
>>>
>>> then later, in a separate method:
>>>
>>>     this.__LZcheckwidth = null;
>>>
>>> And then later:
>>>
>>>     __LZcheckwidth();
>>>
>>> We're masking out a method declared in the prototype by putting a  
>>> null attribute value in front of it. But the method has been  
>>> properly declared.
>>>
>>> jim
>>>
>>> On Apr 12, 2006, at 9:10 AM, P T Withington wrote:
>>>
>>>> I'm working on making the translator work in debug mode.  My  
>>>> hope is to make these kinds of errors easier to find and fix in  
>>>> dhtml.  You should already be able to do that in swf though, if  
>>>> you just turn on warnings in the piece of the LFC you are  
>>>> working on.  Just put
>>>>
>>>> {
>>>>           #pragma 'warnUndefinedReferences=true'
>>>>  ...
>>>>
>>>> }
>>>>
>>>> around the code you are working on.  Eventually we want to be  
>>>> able to do this for the whole LFC.
>>>>
>>>> On 2006-04-12, at 11:45 EDT, Jim Grandy wrote:
>>>>
>>>>> We don't just use this technique here. In LaszloView.as, we  
>>>>> clear __LZcheckwidth and __LZcheckheight to null in certain  
>>>>> situations, and then call them without checking for null.
>>>>>
>>>>> On Apr 12, 2006, at 5:50 AM, Henry Minsky wrote:
>>>>>
>>>>>> OK will do.
>>>>>>
>>>>>>
>>>>>> On 4/12/06, P T Withington <[EMAIL PROTECTED]> wrote:
>>>>>> This looks like a 'stupid AS trick' to me.  Don't try this at  
>>>>>> home.
>>>>>>
>>>>>> I would just change the loop to test d.enabled, and change
>>>>>> LzDelegate.disable to just set the flag and not muck with the  
>>>>>> innards
>>>>>> of the delegate.
>>>>>>
>>>>>> [This is why nullable types suck.]
>>>>>>
>>>>>> On 2006-04-11, at 11:50 EDT, Henry Minsky wrote:
>>>>>>
>>>>>> > There is a method for disabling a delegate which is currently
>>>>>> > implemented as
>>>>>> >
>>>>>> > LzDelegate.prototype.disable = function (){
>>>>>> >     if ( !this.enabled ) return;
>>>>>> >     this.enabled = false;
>>>>>> >     this.disc = this.c;
>>>>>> >     this.c = null;
>>>>>> > }
>>>>>> >
>>>>>> > This has the unfortunate side effect of causing an error in  
>>>>>> DHTML
>>>>>> > runtime if
>>>>>> > you then try to call
>>>>>> > this delegate, because the inner loop of LzEvent.sendEvent does
>>>>>> >
>>>>>> >     for (var i = dll; i >= 0; i--){
>>>>>> >         d = this.delegateList[ i ];
>>>>>> >         //pointer may be bad due to deletions
>>>>>> >         if ( d && ! d.event_called){
>>>>>> >             d.event_called = true; //this delegate has been  
>>>>>> called
>>>>>> >             calledDelegates.push( d );
>>>>>> >             // d.execute( sd ); inlined
>>>>>> >             // We don't worry about deleted contexts here,  
>>>>>> because
>>>>>> >             // we assume that delegates registered on events  
>>>>>> are
>>>>>> >             // properly managed
>>>>>> >             d.c[d.f]( sd );
>>>>>> >         }
>>>>>> >     }
>>>>>> >
>>>>>> > And d.c will be null, causing an error in 'real' javascript.  
>>>>>> Should
>>>>>> > I put a
>>>>>> > check here for the disabled flag,
>>>>>> > or should we bind d.c in LzDelegate to some inert event  
>>>>>> while it is
>>>>>> > disabled?
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > Henry Minsky
>>>>>> > Software Architect
>>>>>> > [EMAIL PROTECTED]
>>>>>> > _______________________________________________
>>>>>> > Laszlo-dev mailing list
>>>>>> > [email protected]
>>>>>> > http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Henry Minsky
>>>>>> Software Architect
>>>>>> [EMAIL PROTECTED]
>>>>>>
>>>>>> _______________________________________________
>>>>>> Laszlo-dev mailing list
>>>>>> [email protected]
>>>>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>>>>
>>>>
>>>
>>
>

_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev

Reply via email to