Am 14.08.2012 10:31, schrieb Invisible:
> 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?

Haven't done much C# programming lately, so currently I'm not that firm 
on the various keywords, but if "override" is that keyword used to do 
virtual method override and "new" is that keyword used to do static 
method override, then you'd surely get a compile-time error, because 
what you tell the compiler about your derived class doesn't fit what the 
compiler knows about the parent class.

Makes a lot of sense, because trying to perform virtual method override 
on a non-virtual method is a strong indicator that you don't know what 
you're doing.


You need to get used to all those keywords, that's all.


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

You've proven us wrong: We named a wrong reason for why the following 
construct doesn't make any sense:

     class Foobar
     {
         private class Bar;    // (1)
         public Bar foobar();  // (2)
     }

Read this carefully, trying to understand it not just syntactically but 
also what it means in the OO concept:

In (1), the "class Bar" tells us (and the compiler) that there is a 
class named "Foobar::Bar", and the "private" keyword tells us (and the 
compiler) that the mere /existance/ of this type is part of Foobar's 
"hidden" implementation details, not to exposed to anything else.

In (2), the "Bar foobar()" tells us (and the compiler) that every Foobar 
object provides an operation named "Foobar::foobar()" returning a value 
of type "Bar", with the "public" keyword telling us (and the compiler) 
that the operation is part of the official interface of the class, to be 
exposed to the whole world.

Notice how (2) implies that the mere /existence/ of a class named 
"Foobar::Bar" must also be part of the official interface. If the 
implementation of Foobar is ever changed, the class "Foobar::Bar" must 
still be retained in order to not break existing code using the class. 
But in (1) we already specified that even the existence of the 
"Foobar::Bar" class is just an implementation detail.


Of course it's perfectly possible to expose the existence of an inner 
class without exposing its details. You just need to use the proper 
keyword on the members of the inner class. (Not sure off the top of my 
hat which one that is.)


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

That's quite a stupid thing to do, because you then can't tell at 
compile-time whether some other function expecting a parameter of type 
"Bar" actually gets passed such a type when using (in C++ style pseudocode):

     Foobar f;
     ANY_TYPE x;

     x = f.foobar();
     ...
     f.barfoo(x);

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

In C#, it might have something to do that enums are far more powerful 
than in other languages, possibly creating some overhead; you really 
want to avoid that for the ubiquitous bool type. (Matter of fact, C# 
enums are more like syntactical sugar for classes employing the Atom 
design pattern, rather than a collection of integer constants.)


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

I don't know Eiffel, but I'd be surprised if Eiffel could compete with 
C# in what C# was designed for: Being a mainstream language for 
mainstream PC desktop applications, running on a VM and providing decent 
performance.

Of course, if you expect C# to be fit for stuff way outside this 
ballpark, it's no surprise you'll be disappointed.

Post a reply to this message