On 8/13/2012 9:31, Orchid Win7 v1 wrote:
> I know that's what C++ does. But I got the impression that in C# this is a
> compile-time error.

No. You just need to say "new" like I showed in the example. It's probably 
an error or warning or something if you're recompiling a subclass, 
overriding a superclass method that already exists, and you don't say "new".

 > (Not that I can find any definitive word on this, mind
> you...)

I'm pretty sure it would be in the spec.

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

Sure. When you load the subclass, it just re-JITs the superclass.

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

I'm not sure why you'd find it confusing if you understand "internal" and 
"protected."

Basically, subclasses or anything compiled at the same time as this class.

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

No it doesn't. It probably lets you return an opaque reference to something 
you can't see the type of, but I doubt it lets you return a type that you 
can't see.

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

No it isn't difficult. It's right in the spec. Sure, there's a lot of steps 
to making the decision, but it's not difficult to codify.

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

Well, actually, everything's an object.

> I especially love how enumerations are a different type but no, not really,
> because obviously they're actually just integers...

No they aren't. Especially not the way Haskell defined "type". :-)

> 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 a little complex, but it really isn't difficult. Why would you care 
that bool isn't an enumeration?

>> It's an excellent language in its class.
>
> I SEE WHAT YOU DID THERE.

It's an excellent OO language that expects to have runtime and OS support 
around. It's a pretty crappy safety-critical realtime functional language.

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