 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] anonymous org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.08.2012 10:40, schrieb Invisible:
>> Diamond inheritance isn't a problem if you don't have implementations.
>>
>> OK, so Thread declares void run(), and DistressedDamsel declares void
>> run(). Why would those declarations conflict?
>
> So if a class tries to implement both interfaces, it can't provide
> different implementations for these two distinct methods merely because
> their names clash?
Depends on the language. You could, for instance, have a syntax to
define a Thread::run() and a separate DistressedDamsel::run(); don't
know whether C# can do that though. Maybe, maybe not. I'd just make a
guess that Java can't do it.
> According to the Great Language Shootout, C# Mono is 3x slower than C.
> (Then again, Haskell is 2x slower...)
A factor of 3x compared to what is probably the fastest
more-or-less-high level language doesn't sound that bad to me, given how
much easier it is to program anything serious in it. (You don't want to
write a GUI program in C, do you?! You'd at least want C++)
>> Sure there is, because you recompile the code while it's running.
>
> That sounds remarkably hard to get right...
Ever heard of JIT-compilers?
All you need to do is mark the corresponding classes as not-yet-compiled
again.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> OK, so Thread declares void run(), and DistressedDamsel declares void
>>> run(). Why would those declarations conflict?
>>
>> So if a class tries to implement both interfaces, it can't provide
>> different implementations for these two distinct methods merely because
>> their names clash?
>
> Depends on the language. You could, for instance, have a syntax to
> define a Thread::run() and a separate DistressedDamsel::run(); don't
> know whether C# can do that though. Maybe, maybe not. I'd just make a
> guess that Java can't do it.
Is there /anything/ Java does right? ;-)
>> According to the Great Language Shootout, C# Mono is 3x slower than C.
>> (Then again, Haskell is 2x slower...)
>
> A factor of 3x compared to what is probably the fastest
> more-or-less-high level language doesn't sound that bad to me, given how
> much easier it is to program anything serious in it. (You don't want to
> write a GUI program in C, do you?! You'd at least want C++)
My point is, adding a low-level feature to shave off 0.02% runtime
overheard in a language which already has 200% overhead seems... odd.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.08.2012 13:59, schrieb Invisible:
> 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.
The C# design /is/ pretty solid for a modern language. Much more solid
at least than the current Java language (which has added tons of kludgy
stuff because they found their initial elegang solution wasn't that
elegant after all for plenty of use cases), or the newest C++
incarnation (which has added badly needed stuff - like smart pointers,
to name just one example - via templates, leading to a somewhat
cumbersome syntax for everyday stuff).
The reason for C# being pretty solid is precisely that they did /not/
aim for an elegant core language to add the other features on top, but
rather designed a language that provides all the features out of the
box, with a somewhat consistent syntax and all.
>> Besides, there's no such thing as as an elegant design that solves
>> everything [with reasonable effort for the language user].
>
> I disagree.
You're free to do that. Still, do you happen to know any counterexample?
(And if so, why aren't you using that language?)
>> 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.
Again, a few counterexamples might give your disagreement a /bit/ more
weight.
Oh, and don't bother to mention Haskell in this context; you've done a
fair share of ranting about that language already to disqualify it for
the position of "an elegant design that solves everything [without
accumulating non-elegant layers of additional features]".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
