Robert Klemme wrote:
> 2010/8/31 Philipp Kempgen <lists / kempgen.net>:
>> Iain Barnett wrote:

>>> Going back in time would be cool if it was in a time machine, but throwing out the good things learned over the years about things in computing seems the wrong way to do it. It's why I don't use PHP ;)
>>
>> Actually one of the few nice things about namespaces in PHP is the
>> ability to import namespaces/classes using an alias.
>>
>> use \foovendor\system\Shell as Sh;
>>
>> Sh::exec( 'ls' );
> 
> Well, you can do the same in Ruby.  Either use a constant or a local variable:
> 
> Sh = ::FooVendor::System::Shell
> Sh.exec 'ls'
> 
> sh = ::FooVendor::System::Shell
> sh.exec 'ls'

Sure.
I guess I'll do some benchmarks. :-)

>> A::B::C or as ::A::B::C to make it obvious that this refers to
>> A::B::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::B::X or ::A::B::X. :-)

Oops. Typo.

> If you have many
> classes and modules in your namespace it's probably best to anchor
> lookups in the global namespace to avoid issues.  Generally though
> people seem to be using unprefixed names - especially for frequently
> used classes like String and Hash.
> 
> What seems to be an issue for you (or for people coming from PHP) does
> not seem to be an issue for most Ruby developers (at least if my
> feeble memory of discussions here does not fail me).  It's
> understandable but it might be easier to stuff PHP experience in the
> 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