The "not needed" part is certainly not beside the point[/b]. It absolutely [i]is the point. The point is that you can completely avoid some $isstarting identifier by simply using the events as they are meant to be used.

Moreover, the fact that there has yet to be a real world use case for this shows that the benefit to such an id is really just hypothetical. The examples so far have been purposefully contrived, and that is my point. Of course you can have some arbitrary scenario where you could have ON START used for everything but script load, but where is the value in that? If there is some real value, show it, it matters. Because if not, why should it be added?

It should be reiterated that the original scenario was not actually meant to be done with ON START. That's why it looks super awkward with 2 event handlers. If the goal was to show something ON LOAD, then ON LOAD should be used. I'd question the scenario where "show something except during script load" is needed-- and even if such a case existed, your script probably has some kind of install flag that can be used to detect this already.

Ultimately what it comes down to is that every possible scenario I can think of can either be done with ON LOAD and/or is probably meant to be done with ON LOAD, not ON START. We should encourage users to use events as they are meant to be used. Is there really a consensus around adding bloat to the language just to give users another way to do the exact same thing in a less proper way? I can't get behind that.

If someone (hopefully pball, since this is his thread, so I assume there was a reason why he requested this) can explain what scenario would rely on this feature, and cannot "easily" be implemented with ON LOAD, I'm all ears.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"