Re: static class inheritance, generalized

Ben Voigt [C++ MVP] wrote:

[snip]

Though why not specify the class in which the method is defined in
front of the method? Math.Cos() instead of Cos() ?

Don't you mean global::System.Math.Cos()? Or do also you see a need
for not always using the fully-qualified name?

I write a lot of C# code and I've never ever have to use global::. I
also hardly have to use full qualified namespaces in front of types.
Perhaps I write code no-one else writes, but that's my experience.

You've missed my entire point that class members don't all fall into
the categories of (instance method/field/property/event) and (static
method/field/property/event). There are also nested classes, and
these are quite possibly a more important use of the feature than all
others combined. So even in a pure OO environment, where everything
is a class, there is still value in adding class members to the
search scope.

So, you suggest this kind of code is good?
public class Foo
{
private Bar _bar;
private string _val;

private class Bar
{
private Foo _container;

internal Bar(Foo container)
{
_container = container;
}

public string GetVal()
{
return "Bar" + _container._val;
}
}

public Foo()
{
_bar = new Bar(this);
_val = "Foo";
}

public string Do()
{
return _bar.GetVal();
}
}

where bar accesses private members of Foo?

why go that route? Isn't that asking for trouble? Sure, it's possible
but why not create properties and access Foo's code through that? It's
not as if Bar is placed elsewhere, the code is inside Foo anyway.

Sure, in these kind of cross-referencing code, just having to refrence
to '_val' instead of _container._val, can be less typing, but I find it
obscure. Just because a nested type is inside the surrounding type
doesn't make the code (IMHO) semantically part of the surrounding type.
At least, I find it leaky. Sure it's possible, but that doesn't make it
more readable.

There is a huge need for being able to omit or shorten the name of
the containing class, whether you are referring to a member field,
event, property, method, or class. Specifically, when the parent
class name is quite long, which is quite common in the presence of
generics. And, the existing "using" (alias) directive cannot be used
inside a class, so it doesn't fully support generics.

using the keyword 'using' just to save some keystrokes is IMHO not the
way to go. Similar to what some people think is logical to use typedefs
all over the place just because it makes the code mode 'readable' to
them.. :X

A program's control flow can be controlled with a lot of delegates. It
will work, and probably be 'very' flexible. THe downside is that
readability (== the reader understands what's written and going on)
goes out the window, simply because the only way to understand what the
code does is stepping through it in a debugger. well.. Hurray... :-/

Here is a really quick example of the shortcomings of the existing
"using" directive:

Non-generic:

class LinkedListNode { ... }

using Node = LinkedListNode; // of dubious value, not saving much
typing

class LinkedList { /* use Node here */ }

Generic:

class LinkedListNode<TValue> { ... }

using Node = LinkedListNode<TValue>; // error, not in scope of TValue

class LinkedList<TValue>
{
using Node = LinkedListNode<TValue>; // error: here TValue is
available, but the using directive isn't allowed /* use Node here
*/ }

using 'using' in this kind of code is IMHO only useful if you can
reword a type to another name, like when the same piece of code has to
use be compiled against two different oracle providers (ODP.NET and MS
Oracle client) and the only difference is the enum type name with the
type definitions to create parameters for example. then using the same
code with both providers can save a lot of time in maintenance.

Because, often people forget what the biggest pile of work is with a
piece of software: maintenance. Software maintenance will become
horrible the more readability and clarity of the code goes out the
window. Redefinining type names with using is IMHO doing that, unless
you can't otherwise. To do it just by 'saving some typing' is IMHO not
an excuse to introduce it, simply because where does it end? ANd will
maintainability be BETTER after it? I seriously doubt it will.

We soon reach the point where there will be more software applications
on this planet than engineers to maintain them. Introducing more
problems for maintainability is IMHO only increasing that problem we're
soon facing.

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

Relevant Pages
Quantcast