I think this is a reasonable idea since, as you say, setters is supposed to be non-null. But setAttribute is specially inlined by the compiler right now, so why don't you just make a bug for me to take care of this?
On 2006-08-01, at 00:04 EDT, Henry Minsky wrote: > I came across an error in DHTML which is hard to reproduce but > seems like it might have been due > to an animator calling setAttribute on a node which had already had > destroy() called on it. > At least, that was the only way I could see that the 'setters' slot > could be null on an LzNode. > > http://www.openlaszlo.org/jira/browse/LPP-2447 > > So I'm proposing putting a check into setAttribute which checks if > setters is null, and gives a warning in debug > mode. Anyone think this is a good or bad idea? > > > LzNode.prototype.setAttribute = function(prop, val) { What are these doc strings doing here? > //@field String name: The name for this subnode. If given, then > this node's > //parent and immediate parent will use store a pointer to this > node as the > //given name value > > //@field String id: A global identifer for this node. If given, > a pointer > //to this node with the given value will be placed in the > global namespace > > //@field String datapath: The string to use as this node's > datapath. This > //usually creates a datapath that attaches to the node. You want to split your conditional so that it will be elided by the compiler in non-debug mode. In which case, you might as well make it a pre-condition: var setters = this.setters; if ($debug) { if (! setters) { Debug.warn("%w.setAttribute: setters is null", this); } } > if ( this.setters == null || null == this.setters[ prop ] ){ > if ( $debug && this.setters == null){ > Debug.warn( "setAttribute called on destroy()'ed node: > ", prop, val, this ); > } > this[ prop ] = val; > var evt = ("on" + prop); > if (evt in this) { > this[ evt ].sendEvent( val ); > } > } else { > this[ this.setters [ prop ] ] ( val ); > } > } > > -- > 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
