On 14/08/2012 11:17 AM, clipka wrote:

> So, how many (mainstream) programming languages have you seen that
> actually /do/ work this way?
>
> C# is pretty "innovative" in that respect.

If doing things right rather than copying the old kludges that everybody 
else uses is "innovative", then sure...

>> My point being that everybody acts like "oh, of /course/ you can't
>> possibly do that", when in fact you can.
>
> You can't with the conceptual approach used by C#. You know, the "I can
> verify at compile time that the object referenced by variable X can do
> A, B, C and D."
>
> If you want to give such guarantees, you can't handle variables of types
> for which you have no declaration, because obviously you can't tell
> whether they can do A, B, C and D or not.

...and yet, in my Haskell snippet, a type is not exported, yet still you 
can convert it to a string, because that interface is implemented.

Obviously /the compiler/ must be able to see the declaration for the 
type. But that doesn't mean that /the programmer/ needs to.

> Andy, be fair. The fact that there's /someting/ programming language X
> can't do that Haskell can doesn't mean that programming language X is
> "poor quality".

No, that's true. I was really point pointing out that somebody says "X 
*must* work this way", and, er, no, it doesn't. It could work 
differently if you wanted it to. I guess it's a silly thing to argue 
about though.

My real concerns about C# are that they seem to have added a feature for 
everything, rather than step back and look for a simpler, more elegant 
design that solves everything, not just the things they added specific 
features for.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 13.08.2012 19:26, schrieb Warp:

> >> Yeah, I don't know. I'm slowly coming around to the idea that maybe we
> >> should forget about all this "inheritance" stuff and focus on interfaces
> >> as the primary thing of interest...
> >
> > How would you implement a GUI library without using any kind of inheritance?

> By using /interfaces/ maybe?

Given that interfaces cannot contain member variables nor function
implementations (at least not in any language I know of), it would make
the GUI library *really* annoying to use because of all the required code
repetition. (For example, every time the library needs to know the
coordinates of the object on screen, it would have to call a function
declared in the interface, which the user would have to implement in his
own code to return those coordinates. It would also cripple any possibility
of using eg. a screen element that contains other screen elements, because
such an object would just be an interface and cannot contain anything.)

> You can argue that a class that implements an interface effectively 
> "inherits" from it, but you can also argue against it. It's a matter of 
> how exactly you define "inheritance".

Inheritance implements the OO concept of an "is-a" relationship. If a class
implements an interface, then it effectively has an "is-a" relationship to
it. (For example, if the interface is named, let's say, ButtonListener,
and you implement it, then your class "is-a" ButtonListener. You can give
an object of your class to anything that expects a ButtonListener. It doesn't
get any more straightforward and clear inheritance than that.)

-- 
                                                          - Warp

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> >> I have to admit, Eiffel /does/ make the solution look very, very 
> >> complicated. (I can't actually remember off-hand how the heck C++ does 
> >> it...)
> > 
> > Does what?

> Manage inheritances, including multiple inheritances.

In a single inheritance case the compiler simply internally builds a
data structure with all the data members of the entire inheritance
hierarchy one after another. The base class portion of the structure
looks identical to the one that would exist if you instantiated the
base class directly (and hence any function that deals with the base
class members can deal directly with the inherited class object).

If the class contains any virtual functions, then a virtual table pointer
will be added to the data structure (typically, though not necessarily,
at the beginning of it).

(If the base class did not contain any virtual functions but the derived
function does, it's perfectly possible for the 'this' pointer to change
in value when a base class method is called, in order to point to the
base class part of the structure. The base class member function will be
none the wiser, and work just right.)

In a (non-diamond) multiple inheritance case the same thing is done,
basically. The data of the base classes is just put one after the other
in the derived class' data structure (and the 'this' pointer is changed
as necessary when calling the base class member functions).

In a diamond inheritance situation you have a choice to make: Do you want
each of the multiple parents to be "independent" of each other (which
means that the data from the common parent class is kept separately),
or do you want them to share the data from the common parent class?

In the latter case the data from the common parent class is stored only
once in the most-derived class' data structure, and virtual table trickery
is used to make the in-between class methods to change the 'this' pointer
appropriately when calling the base class methods (or if the in-between
classes want to read/change the base class member variables directly).

(In the former case the in-between classes behave just like there was
no multiple inheritance at all, handling their own "local copy" of the
common base class.)

> >> I would have thought the indirect code jump is probably far more 
> >> expensive than the space overhead.
> > 
> > The additional space consumption is significant if you have eg. a class
> > that would otherwise be the size of a pointer (and you need to instantiate
> > millions of them). If you had forced virtual functions, it would double in
> > size.

> IIRC, C++ does not duplicates the class function members (not even
> pointers to them) in each instance. Only the actual class (as 1 pointer)
> is stored within each instance. The virtual function is just an index.
> The first virtual/inheritance cost a pointer in the class. The next are
> free.(in fact, with RTTI, even without inheritance, you might already
> have that pointer: so no additional cost)

But if your class were eg. the size of one pointer, then adding any virtual
functions would double its size.

-- 
                                                          - Warp

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> Vista, 7, 8... who cares, XP runs!

Not a good gaming platform anymore. (Microsoft wants XP to die, so they
refuse to update DirectX for it.)

-- 
                                                          - Warp

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> As current widespread belief is that virtually all multiple inheritance 
> use cases can be covered with the interface approach, it seems to make 
> sense to avoid this extra overhead.

Only if you don't mind the need for code repetition with interfaces.

-- 
                                                          - Warp

Post a reply to this message

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

Darren New <dne### [at] sanrrcom> wrote:
> On 8/13/2012 7:53, Warp wrote:
> > If diamond inheritance is the problem, then forbid diamond inheritance.

> It turns out that having everything descend from Object (and other tricks 
> like that) turn out to be more useful than multiple inheritance.

Does Object contain member variables? If not, then I don't see the problem.

Even if it does, then the language could implicitly do with it what C++'s
virtual inheritance does. You can still forbid all other types of diamond
inheritance if you so wish.

-- 
                                                          - Warp

Post a reply to this message

Am 14.08.2012 10:32, schrieb Invisible:
> On 14/08/2012 02:01 AM, Darren New wrote:
>> It's an excellent OO language that expects to have runtime and OS
>> support around.
>
> ...and yet, they claim it can be used for embedded systems, which don't
> even /have/ an OS?

You'd be surprised how many embedded systems /do/ have an OS.

Post a reply to this message

On 14/08/2012 12:13 PM, Warp wrote:
> Le_Forgeron<jgr### [at] freefr>  wrote:
>> Vista, 7, 8... who cares, XP runs!
>
> Not a good gaming platform anymore. (Microsoft wants XP to die, so they
> refuse to update DirectX for it.)

Valid point. But in a commercial setting, pretty irrelevant.

(Unless you happen to be a games developer, I suppose...)

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> On 14/08/2012 12:13 PM, Warp wrote:
> > Le_Forgeron<jgr### [at] freefr>  wrote:
> >> Vista, 7, 8... who cares, XP runs!
> >
> > Not a good gaming platform anymore. (Microsoft wants XP to die, so they
> > refuse to update DirectX for it.)

> Valid point. But in a commercial setting, pretty irrelevant.

It will become relevant when Microsoft inevitably stops supporting XP.

It might not happen next month, or even next year, but the clock is
ticking.

-- 
                                                          - Warp

Post a reply to this message