 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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".
> (Not that I can find any definitive word on this, mind
> you...)
I'm pretty sure it would be in the spec.
> 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.
> 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.
>> 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. 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.
>> When you see the formal definitions of what you can and can't do, think
>> about what it *means* and it will be clearer.
>
> The rules are set up to make the obvious things work. My complaint is that
> due to the complexity of the system, "the obvious thing" is actually very
> difficult to codify precisely. Which is usually the sign of a bad design.
No it isn't difficult. It's right in the spec. Sure, there's a lot of steps
to making the decision, but it's not difficult to codify.
> 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.
> 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". :-)
> 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?
>> It's an excellent language in its class.
>
> I SEE WHAT YOU DID THERE.
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.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
> And it's not like diamond inheritance is forbidden with interfaces (AFAIK,
> although I haven't checked this.)
It doesn't matter there, because the problem with diamond inheritance is
differing implementations and member variables, not the actual methods.
Eiffel did a nice job, but even there they never (AFAIK) actually
implemented the spec.
> But you should be liking C#. It doesn't leak memory and if it crashes, it
> tells you where and why. Probably.
Yep. Unless you explicitly use an unsafe construct.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/13/2012 9:22, Orchid Win7 v1 wrote:
> Weirdly, both Java and C# actually /allow/ interfaces to inherit, thus
> defeating the whole point of the exercise.
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?
> It makes little to no sense in C#, a language which is already doomed to be
> horrifyingly inefficient before you've even written a single line of code.
It's becuase C# is a component-oriented language. It's designed to let
people write code and release the object code and have others use it without
recompiling.
It's also not intrinsically inefficient. For example, Singularity uses it to
write its kernels in.
> Arguably you could have the compiler detect where dynamic binding is and is
> not needed. That requires whole-program analysis, however.
That's what Eiffel does.
> No problem for
> Haskell, but C# explicitly supports run-time loading of additional code, so
> there's no telling at compile-time what external code might do.
Sure there is, because you recompile the code while it's running.
> 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...
I kind of like where Go went: static duck typing.
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> You can override it. You just don't get virtual dispatch.
>>
>> I know that's what C++ does. But I got the impression that in C# this is
>> a compile-time error. (Not that I can find any definitive word on this,
>> mind you...)
>
> AFAIK it is a compile-time error, unless you explicitly specify that you
> DO want to override it.
Yeah, that's what I thought.
> C# has a lot of these "if you DO mean it, say so in the code" things.
> Which I, personally, think is pretty smart.
If by "pretty smart" you mean "how /every/ programming language should
work in the first place", then yes.
>>> 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.
>
> I /think/ you should avoid trying to compare maintream languages'
> features to those of Haskell.
My point being that everybody acts like "oh, of /course/ you can't
possibly do that", when in fact you can.
Besides, why should I avoid comparing things to Haskell? It's true that
almost nobody has heard of it. But does that mean that it's OK for
mainstream languages to be poor quality? I think not...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 13/08/2012 07:44 PM, Le_Forgeron wrote:
> Le 13/08/2012 18:22, Orchid Win7 v1 nous fit lire :
>>>
>>> Is there actually a version of Windows out there that does not come with
>>> the .NET libraries out-of-the-box? (I mean newer than 10 years.)
>>
>> How about "the version that ALL of our production systems and every
>> customer-facing system in every commercial setting I've ever seen uses"?
>> You know, *that* version. :-P
>
> Yep. You have the sames as me. 2000& XP. Now only XP. Everywhere. Some
> SP3, not all...
Actually, I've never seen Windows 2000 used anywhere, ever. Not in
people's homes, not in places of work. Indeed, if it weren't for that
course my employer sent me on, I wouldn't even know it /exists/... It
never seemed to be really popular.
> At least itanium is dead (or might... Oracle has been ordered to
> continue software support, for HP...), so Windows on itanium is dead.
It's a shame, really. AMD64 has /way/ too much old backwards
compatibility cruft in it. In fact, the same could be said for the
entire IBM PC-compatible platform. (Flip address line 20 to enable
protected-mode? WTF is *that* about??)
> Vista, 7, 8... who cares, XP runs!
Well, if all you need the OS to do is run your EPOS system, you probably
don't give a **** about Aero, video authoring, DirectX 11, PC sync, or
the bazillion and one new features in those newer OSes.
I still see commercial systems running MS-DOS, FFS! o_O
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 14/08/2012 02:03 AM, Darren New wrote:
> Eiffel did a nice job, but even there they never (AFAIK) actually
> implemented the spec.
FWIW, I thought they did. I don't have proof, however...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 14/08/2012 02:08 AM, Darren New wrote:
> On 8/13/2012 9:22, Orchid Win7 v1 wrote:
>> Weirdly, both Java and C# actually /allow/ interfaces to inherit, thus
>> defeating the whole point of the exercise.
>
> 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?
>> It makes little to no sense in C#, a language which is already doomed
>> to be
>> horrifyingly inefficient before you've even written a single line of
>> code.
>
> It's becuase C# is a component-oriented language. It's designed to let
> people write code and release the object code and have others use it
> without recompiling.
>
> It's also not intrinsically inefficient. For example, Singularity uses
> it to write its kernels in.
According to the Great Language Shootout, C# Mono is 3x slower than C.
(Then again, Haskell is 2x slower...)
>> Arguably you could have the compiler detect where dynamic binding is
>> and is
>> not needed. That requires whole-program analysis, however.
>
> That's what Eiffel does.
Sure. Because Eiffel doesn't support dynamic linking.
>> No problem for
>> Haskell, but C# explicitly supports run-time loading of additional
>> code, so
>> there's no telling at compile-time what external code might do.
>
> Sure there is, because you recompile the code while it's running.
That sounds remarkably hard to get right...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.08.2012 10:06, schrieb Invisible:
>> C# has a lot of these "if you DO mean it, say so in the code" things.
>> Which I, personally, think is pretty smart.
>
> If by "pretty smart" you mean "how /every/ programming language should
> work in the first place", then yes.
So, how many (mainstream) programming languages have you seen that
actually /do/ work this way?
C# is pretty "innovative" in that respect.
>>>> 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.
>>
>> I /think/ you should avoid trying to compare maintream languages'
>> features to those of Haskell.
>
> 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.
> Besides, why should I avoid comparing things to Haskell? It's true that
> almost nobody has heard of it. But does that mean that it's OK for
> mainstream languages to be poor quality? I think not...
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".
I'd dare say C# is actually pretty /high/ quality (at least the language
per se; one might argue about its standard libraries); there's something
to the claim that it's kind of "Java done right".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
