Robert K. wrote:
2010/8/31 Philipp K. [email protected]:
Iain B. wrote:
Sh = ::FooVendor::System::Shell
Sh.exec ‘ls’
sh = ::FooVendor::System::Shell
sh.exec ‘ls’
Sure.
I guess I’ll do some benchmarks.
A::C or as ::C to make it obvious that this refers to
A::C in the top-level scope (: and to avoid a lookup in the
local scope. (What are the best practices?)
Neither - you would reference via A::X or ::X.
Oops. Typo.
closet and try to approach Ruby with less historic baggage.
Yes, Ruby folks seem to prefer unprefixed identifiers.
The same thing is true for PHP developers.
But then again if a simple “::” prefix can make my code x % faster
by skipping unnecessary lookups in the local scope – well I guess
it depends on x whether I’m willing to trade conciseness for speed.
And apart from that I still think that fully-qualified, anchored
identifiers (“::…”) in a library can make that library more
robust (without affecting the consumers of that library) and less
prone to problems concerning namespace resolution which could
potentially be both hard to track down and boring.
That has nothing to do with porting the PHP way of thinking into
the Ruby world.
Hardly anyone seems to care though.
Actually I suppose most developers don’t even make an “informed
decision” not to use anchored identifiers, and that worries me.
I guess all I want is to make an informed decision a la “anchored
identifiers don’t buy me that much and the extra robustness does
not compensate for the additional clutter in my code”.
My benchmarks show no significant performance improvement though
(whereas there is a noticable improvement in PHP).
Actually if you want the maximum performance out of PHP you end up
using fully qualified identifiers everywhere, e.g. \strlen instead
of strlen and \true instead of true (oh boy).
My goodness!
Crazy, right? It’s particularly strange since you can’t override
the special constants true, false and null in a namespace anyway.
And while we’re at it: true is faster than TRUE in PHP.
I don’t think I should optimize for speed at all costs but that’s a
good example of where optimization comes for free. It does not cost
anything to write true instead of TRUE.
And it does not cost much to replace strlen() by \strlen() in a
tight loop while in general avoiding the clutter that is introduced
by anchored names.
Philipp