On Feb 18, 11:02 pm, David Mark <dmark.cins...@gmail.comwrote:
On Feb 19, 1:14 am, Peter Michaux <petermich...@gmail.comwrote:
Actually I think that FORK_addListener is less likely to be clobbered
than FORK. It's all a crap shoot with this single global namespace
But if you have hundreds of targets instead of one, then theI've been thinking about this more for a library API.
probability of collisions is increased. I do see your point that
"FORKINGLEAVETHISALONE" would be a less likely candidate for an
overwrite.
prefix namespacing
FORK_addListener
vs.
object namespacing
FORK.addListener
It seems only one level of namespacing is every necessary for a
library. If that is the case why use an object for this namespacing
than just a prefix? Are there any useful benefits?
Accessing FORK_addListener is faster than accessing FORK.addListener.
I did do some tests on this sort of thing and I can resurrect the
results if anyone is interested. The important impression I was left
with was that doing tens or hundreds of thousands of identifier
resolutions were in the range of 40 to 60 ms. I would say speed is not
really a deciding factor.
Looping over the API properties of the library is easier but I don't
know why I would need to do that. I never have done that. With the
prefix version it is possible to loop over the properties of the
global object and do a regexp test on the property name. It wouldn't
be quite as fast but it wouldn't be brutal.
I suppose it does simulate Java namespacing syntax but that is hardly
a reason to do anything.
How did the object namespacing become so popular? Is it because the
MM_ functions were so badly written and prefix namespacing got a bad
reputation?
Peter