On 8/13/2012 4:56, Invisible wrote:
> OTOH, C# does that thing that C++ does where it's impossible to override a
> method, unless you manually declare it as "virtual".

You can override it. You just don't get virtual dispatch. In other words, 
someone expecting the superclass's behavior to apply to a variable of the 
superclass's type won't see unexpected behavior without being warned.

> This violates one of
> the ideas behind OO, which is that if you've got a class that does nearly
> what you want, but not quite, you can subclass it and change it to make it
> do what you want. Well, no you can't, not if some of its methods can't be
> overridden.

You *can* do this.

class A {
    public x() { yadda1(); }
}

class B : A {
    new public x() { yadda2(); }
}

Now B is just like A, except x() calls a different yadda.

The only trick is that if you declare a variable of type A and invoke x() on 
it, you get A's x(), not B's. Unless A declares x() to be virtual, so 
callers of A.x() know they might be getting something different.

> It's true that having non-virtual methods introduces a tiny performance
> benefit. It's true that inheritance is over-used anyway, and you can usually
> get the same effect or better using collaboration instead. But still, the
> objection stands.

That has nothing to do with why it was done that way, since the JIT removes 
the virtual dispatch from virtual functions you don't override. It's because 
of what I said above, which is that A.x() will call A.x()'s code unless A 
says otherwise.

> And then we get into access specifications. Java has public, private,
> protected and package-local (which is implicit, and cannot be written
> explicitly). C++ has... well, I'm not even sure /what/ the hell C++ has! And
> C# has the whole cake shop.

Really, I think that's pretty much it. The same as Java, except instead of 
"package" you have "assembly". Oh, and you can put two of the 
somewhat-private declarations together. (protected assembly or something?)

> Not only can you declare the accessibility of a thing, but there are
> restrictions on what you can do. A subclass can't make stuff more secret
> than its superclass (because clients might be using that interface instead).
> You can't make something public if it refers to private types. And so on.

Yes. Well, what would you expect? A public method that returns a value of a 
type you can't see the declaration of?

When you see the formal definitions of what you can and can't do, think 
about what it *means* and it will be clearer.

> As I sit here and listen to all these complicated rules about what can and
> can't be public and the convoluted rules for resolving a method call to an
> actual block of code, I can't help thinking... Did you guys ever thing that
> maybe if it ends up being this complicated, you're doing it wrong?

Admittedly the resolution rules are pretty complicated. In practice, it 
almost never comes into play, just like in practice people don't declare the 
same name to mean different things in similar classes.

> People have criticised OOP for being ad hoc and lacking a coherent
> theoretical foundation many times, of course. There was a time (around about
> 1998 or so) when I thought that OOP was the ultimate answer to every
> possible coding problem, and it was the way of the future. Today, it just
> looks overly complex and ill thought out. Especially when looking at
> something like C#.

C# has the hindsight of a bunch of OOP development. It's really not that 
complex, unless you try to learn the rules without understanding them. If 
you study the resolution rules as if they're math, instead of asking "why 
did the designers decide *this* would override *that*", then it's going to 
be confusing. Just like the visibility rules are complex if you don't think 
"well, what would it mean if I broke those rules? What would it do?"

> Still, not liking C# isn't going to change the fact that it is (apparently)
> the most popular programming language now... :-P

It's an excellent language in its class.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message