On 14/08/2012 02:01 AM, Darren New wrote:
> 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".

So what happens if you say "override" on a method that isn't virtual?

>> (Not that I can find any definitive word on this, mind
>> you...)
>
> I'm pretty sure it would be in the spec.

Heh. And I thought Haskell was the only language stupid enough to claim 
that the reading the formal language specification is a good way to 
learn how to program with it...

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

It actually does that?

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

I guess it makes sense once you realise it means OR, not AND.

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

O RLY?

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

   module Foobar (Foo (..), foobar) where

   data Foo = Foo Int deriving Show
   data Bar = Bar Int deriving Show

   foobar :: Foo -> Bar
   foobar (Foo x) = Bar x

Notice how Bar is not exported, yet foobar is exported, and its return 
type is Bar.

Remember, Haskell functions deal with known types ALL THE TIME. Any time 
you call id :: x -> x, it takes a value of unknown type, and returns it 
unchanged. So for Haskell, having some data of a type that you can't 
"see" is no big deal at all. (With the minor detail that you now can't 
declare anything as returning Bar as its result, because that name is 
not in scope.)

More usually, of course, you would export the /name/, but not its 
/definition/. But you /can/ decide to not export the type at all, and 
still return it as a result, or take it as an argument.

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

Except that no, no it isn't. Apparently only values of reference types 
are considered "objects". :-P

You could /almost/ say "everything's a class", except that no, we have 
enums and stuff which aren't considered "classes".

What you /can/ say is that at least these 5 different things all behave 
rather more consistently than they do in Java...

>> 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". :-)

Right. So enumerations aren't integers, and that's why you define the 
corresponding integer value of each case right there in the definition? :-P

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

If you have real enumerations, why do you need a special-case for bool? 
To be, that just suggests that enumerations don't work properly.

(The same argument applies to Haskell: Why the HELL did they 
special-case the list type, when you can trivially define it manually? 
What there they thinking??)

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

OK, whatever. I haven't really explored it all that much yet, but it 
doesn't appear to compare well to Eiffel.

Post a reply to this message