On 13/08/2012 03:50 PM, Darren New wrote:
> 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.

I know that's what C++ does. But I got the impression that in C# this is 
a compile-time error. (Not that I can find any definitive word on this, 
mind you...)

>> It's true that having non-virtual methods introduces a tiny performance
>> benefit.
>
> 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.

Does that actually work? Given that you can load arbitrary new 
subclasses at any moment?

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

You have "internal", which means "everything else in this assembly". You 
also have "protected internal", which means protected OR internal. 
(Because protected AND internal would just be nonsensical...) I'm still 
trying to wrap my brain around that last... but presumably you almost 
never need it anyway. After all, most things are just public or private.

No, wait! >_< Damnit, I meant protected...

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

Haskell lets you do exactly that, yes.

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

The rules are set up to make the obvious things work. My complaint is 
that due to the complexity of the system, "the obvious thing" is 
actually very difficult to codify precisely. Which is usually the sign 
of a bad design.

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

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

I guess I'm just spoiled. In Haskell, there are precisely 2 sorts of 
type; everything is either an algebraic data type or a function type. C# 
has 5 of fundamentally different sorts of type, all with different 
semantics.

I especially love how enumerations are a different type but no, not 
really, because obviously they're actually just integers... Or how 
"bool" isn't an enumeration, it's hard-coded. Or how you can make 
primitive types nullable, but you can't make reference types 
non-nullable. Or...

> It's an excellent language in its class.

I SEE WHAT YOU DID THERE.

Post a reply to this message