Er, in case it is not obvious, it does not do that presently in the
LFC because warnings are disabled by default in the LFC. You can use
the pragma to selectively enable them, as we go over it, and
eventually we should have them always on, so the code does not rot.
The compiler is _reasonably_ smart about not checking locals that it
can prove have to be defined, so the overhead is not horrible.
There's room for improvement here, when we know type information.
On 2006-04-12, at 12:58 EDT, 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
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
