- From: Allen Wirfs-Brock <allen@wirfs-brock.com>
- Date: Sat, 11 Aug 2012 18:48:38 -0700
- To: Brendan Eich <brendan@mozilla.org>
- Cc: Boris Zbarsky <bzbarsky@MIT.EDU>, public-script-coord@w3.org, es-discuss@mozilla.org
On Aug 11, 2012, at 12:21 PM, Brendan Eich wrote:
> Allen Wirfs-Brock wrote:
>> On Aug 10, 2012, at 11:14 PM, Brendan Eich wrote:
>>>> In this case, firing the setter is perhaps what the programmer wanted, even if it is a terrible way to accomplish that end.
>>>
>>> It's not that bad if you start from the DOM level 0, especially window.onload being the same binding as function onload() {}.
>>>
>>
>> There seems to be a contradiction between what you describe above for primordial and what ES1-3 said:
>
> There was no contradiction in the old days. Writing
>
> function onload() {}
>
> did not run a proto-setter to add an event listener. Rather, a load event fired by trying any function named by window.onload.
>
> At some point this stopped working. Not sure when, but it's how JS + DOM level 0 worked in Netscape 2 when they debuted, and I believe for a long while after.
I see, this makes perfect sense when onload is viewed simply as a passive property. It is turning into an active side-effecting registration mechanism that conceptually clashed with function declarations. I wonder why that was necessary. Could it be as something as simple as WebIDL (and its predecessors) lacking the concept of interfaces with dynamically extensible properties?
Allen
Received on Sunday, 12 August 2012 01:49:06 UTC