Re: Namespaces too looooooong

2010/8/31 Philipp Kempgen <[e-mail]>:
> Robert Klemme wrote:
>> 2010/8/31 Philipp Kempgen <[e-mail]>:
>>> Iain Barnett wrote:
>
>>>> Going back in time would be cool if it was in a time machine, but thro=
wing out the good things learned over the years about things in computing s=
eems 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. =A0Either use a constant or a local v=
ariable:
>>
>> Sh =3D ::FooVendor::System::Shell
>> Sh.exec 'ls'
>>
>> sh =3D ::FooVendor::System::Shell
>> sh.exec 'ls'
>
> Sure.
> I guess I'll do some benchmarks. :-)

I don't expect much differences.  Please share the outcome of the benchmark=
.

>>> 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.

Hehe.

>> If you have many
>> classes and modules in your namespace it's probably best to anchor
>> lookups in the global namespace to avoid issues. =A0Generally 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). =A0It'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.

A language that can be significantly sped up by doing this feels quite
broken to me.

> 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.

Right.  At least in theory.

> That has nothing to do with porting the PHP way of thinking into
> the Ruby world. :-)
>
> Hardly anyone seems to care though.

Probably because the bugs you mentioned above happen too infrequently
(or not at all) in practice.  Ruby folks are usually very pragmatic
and use whatever works (although I would readily agree that this a)
isn't always good and b) is an oversimplification).

> 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".

If there is no experience you can build on you'll have to gather it
yourself, I'm afraid.  The good news is that you can advance the
community by sharing what you found.

>>> 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?

"Crazy" sounds about right - if not too mild.

Kind regards

robert


--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/