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

Am 14.08.2012 12:46, schrieb Invisible:
> 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...

That's exactly my ppint.

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

C# was never meant to win a design contest. It was meant to be a decent 
everyday programming language.

Besides, there's no such thing as as an elegant design that solves 
everything [with reasonable effort for the language user]. Many tasks 
require certain common design patterns you don't want to re-implement 
over and over again, so one way or another you'd end up adding layers on 
top of that elegant design, which - because the elegant design doesn't 
provide them out of the box - will often be far from elegant to use.

Post a reply to this message

Am 14.08.2012 13:00, schrieb Warp:
> 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.

I guess you've heard of code re-use through delegation, no?


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

I have no idea what you're saying there. If you're saying what I'm 
reading, it's plain nonsense.


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

In common parlance, "inheritance" means "multi-level inheritance" though 
(and in the OP quoted above it was obviously meant that way), and a 
single tier of interfaces and a single tier of implementing classes 
doesn't really cut it.


I do agree that at least inheritance among interfaces would be nice to 
have, but it's not entirely impossible to implement a GUI library even 
without that.

Post a reply to this message

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

What do you mean "when"? This has already happened.

http://en.wikipedia.org/wiki/Windows_XP

"Mainstream support ended 14 April 2009."

Post a reply to this message

Am 13.08.2012 23:00, schrieb Le_Forgeron:
> Le 13/08/2012 22:22, clipka nous fit lire :
>>
>> 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.
>
> When all you have is a hammer, everything is a nail.
>
> When you make the conception, once you know there can be only one true
> linear hierarchy of classes and interfaces on the side, you integrate it
> in your problem. You might even forbid yourself of thinking about
> multiple inheritances.

As I said, it's "current widespread belief"; I won't dare to make any 
claims about its boolean value, but on the basis of this belief, the 
decision to restrict multiple inheritance to interfaces is perfectly 
logical.

Post a reply to this message

On 14/08/2012 12:33 PM, clipka wrote:
> C# was never meant to win a design contest. It was meant to be a decent
> everyday programming language.

And surely starting with a solid design is the best way to do that.

> Besides, there's no such thing as as an elegant design that solves
> everything [with reasonable effort for the language user].

I disagree.

> Many tasks
> require certain common design patterns you don't want to re-implement
> over and over again, so one way or another you'd end up adding layers on
> top of that elegant design, which - because the elegant design doesn't
> provide them out of the box - will often be far from elegant to use.

Again, I do not agree.

Post a reply to this message

Am 14.08.2012 00:17, schrieb andrel:

>> When all you have is a hammer, everything is a nail.
>
> or a plank. You need planks too.
> or a thumb. Hammers are great to remind one of thumbs.

LOL!

Post a reply to this message

On 13/08/2012 11:17 PM, andrel wrote:
> or a thumb. Hammers are great to remind one of thumbs.

My thumb almost hurts now...

Post a reply to this message