Re: static class inheritance, generalized

Ben Voigt [C++ MVP] wrote:

I find the class with static methods not pretty, but it has an
advantage over a bucket with routines forming a library: the class
name gives the reader hints where the method is implemented:
Calculator.Add() might be hurting for the eye when it comes to true
OO, however it's IMHO better than having 'Add()' alone, and the
reader then has to GUESS in which module Add is implemented.


Then you'd better outlaw "using namespace". After all, how can you
know what constructor "new Timer()" calls?

Oh, yes, you would look at the using namespace directives at the top
of the file or namespace. And with this suggested feature, you would
also look at the "using static" directives at the top of the file,
namespace, or class, to determine where 'Add()' came from.

So, because that set of using statements makes it already less clear,
you're perfectly OK with making it VERY unclear for the reader with
further scope increases?

double d = Sqrt(foo);

where does 'Sqrt(foo)' live? I have NO idea. Sure, with fancy tooling
I might find the place where this is. But reliance on tooling to READ
and UNDERSTAND code is IMHO a slippery slope I at least don't want to
be on. Code should be understandable and clear for the reader who reads
it. ANY degration to that is IMHO bad. Sure your suggestion might save
a few keystrokes, but it also introduces degration of the clarity of
code written. I simply fail to understand how you can ignore that fact.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
.

Loading