 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/14/2012 4:52, clipka wrote:
> I guess you've heard of code re-use through delegation, no?
Then every type of screen item has to delegate that call to something else,
and every time the superclass adds a function, then all subclasses have to
write code to delegate it properly.
If you automate that process, guess what you just invented?
> I do agree that at least inheritance among interfaces would be nice to have,
I don't know of any language that implements inheritance and interfaces that
doesn't allow interfaces to inherit. Quite honestly, that would make almost
no sense.
--
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/14/2012 4:15, Warp wrote:
> clipka<ano### [at] anonymous org> 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.
I might have asked this before, but do you have any good (hopefully generic)
examples of where MI really helps out?
--
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/14/2012 1:40, Invisible wrote:
> 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?
That depends on your language. Java? I don't think so. C#? Definitely. But
then you can't invoke the interface call without specifying which one you
mean, so there's no ambiguity.
> According to the Great Language Shootout, C# Mono is 3x slower than C. (Then
> again, Haskell is 2x slower...)
So, an open source clone is slow, thus the version Microsoft uses that
compiles down to optimized native code must be also?
>>> 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.
Yep. That's what (for example) Sing# does too.
>> Sure there is, because you recompile the code while it's running.
> That sounds remarkably hard to get right...
No harder than compiling it in the first place while it's running. Why is it
harder to re-JIT than to JIT?
--
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/14/2012 4:20, Warp wrote:
> Does Object contain member variables? If not, then I don't see the problem.
Good point. I don't know.
> 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.
You could, but then it's getting weird.
--
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/14/2012 7:42, Invisible wrote:
> - "As of C# 2.0, it is also possible to have an array in a structure." (Erm,
> why the HELL would it not be possible to do that before??)
Because structs are fixed size determined by the compiler (and stored in the
stack generally speaking), and arrays are variable sized and stored in the
heap. You can share references to arrays but not to structs, so what happens
when you pass a reference to the array inside a struct and then discard the
variable holding the struct?
> - "x & y" performs a Boolean-OR if the arguments are Bools, and a bitwise-OR
> if they are integers. The same goes for all the other logical operators.
> Except NOT, which has "!x" for Bools and "~x" for integers. WTF?
Makes sense if you think about where those symbols came from, namely C.
> - "x + y" performs addition. Unless either argument is a string, in which
> case the other is converted to a string as well (if not a string already)
> and the strings are concatenated. Unless both arguments are delegates, in
> which case they are concatenated. (I guess there's a /reason/ the Java guys
> claim that operator overloading is evil!)
If you don't know what types you're adding together, you're already in trouble.
> - Goto? Seriously? Well, I suppose /technically/ that's not actually a WTF...
Useful for generated code like state machines.
> - Anonymous delegates /and/ lambda functions?
Yes?
> - A delegate is a thing which is called when an event is fired, but an event
> /is/ a delegate?? (In fairness, this is probably a Wikibooks WTF rather than
> anything to do with the design of C#.)
A delegate is basically a function pointer you can invoke. An event is
basically a delegate with only certain operators (+= and -=) exposed outside
the class that declares the delegate. So think of "event" like "restricted
interface to a delegate".
"firing an event" is exactly the same thing as "invoking a delegate."
> - Extension methods. Just... what??
Useful for LINQ. Useful in general for readability.
> - A non-generic queue is called Queue, and a generic queue is called
> Queue<T>. And yet, for the other container types, the generic and
> non-generic versions have completely different, unrelated names. (I guess
> that's backwards compatibility for you... oh, wait.)
Yep. Generics didn't show up until V3 or so, I think.
--
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/14/2012 14:06, Orchid Win7 v1 wrote:
> However, char, the type of a single character, apparently covers the BMP
> only. If you're going to go to all the trouble of actually supporting
> Unicode, why not support the whole thing?
You do know that unicode has evolved too, right?
> Yeah, sounds like more the sort of thing you'd expect in a scripting language.
No. It's perfectly reasonable rules based on static types.
> OTOH, it appears that it's the only autoconversion that can happen.
Not at all. Indeed, you can declare your own implicit conversions for your
own types.
> Pop quiz: if x is a string and y is a delegate, does it do delegate
> concatenation or string concatenation?
It fails to compile, because there's no implicit conversion between the two.
--
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/15/2012 4:08, Invisible wrote:
> I guess I'm used to using a programming language where a Char is... well...
> any valid Unicode code-point,
You mean, you only use languages invented after Unicode had more than 65536
code points defined.
--
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/15/2012 4:52, clipka wrote:
> You're right there. I guess it's to provide support for bitfield-style use
> of enums.
That too. They're just conveniently-named integers.
I far prefer Java's enums, which are basically a full-blown class (with
member variables and static and instance functions and everything), but with
all valid instances of the class being declared in the enum at program
start-up time. So, basically, a full class plus a bunch of "static BLAH =
new ..." sorts of operations.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 16.08.2012 01:40, schrieb Darren New:
> On 8/14/2012 4:52, clipka wrote:
>> I guess you've heard of code re-use through delegation, no?
>
> Then every type of screen item has to delegate that call to something
> else, and every time the superclass adds a function, then all subclasses
> have to write code to delegate it properly.
You're presuming here that GUI item superclasses keep growing new
functions. That's not a necessary prerequisite for a GUI library though.
>> I do agree that at least inheritance among interfaces would be nice to
>> have,
>
> I don't know of any language that implements inheritance and interfaces
> that doesn't allow interfaces to inherit. Quite honestly, that would
> make almost no sense.
I totally agree that it's a good choice to not design a language that
way. But still, even with such a language you /could/ write a GUI library.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 16.08.2012 01:58, schrieb Darren New:
> I far prefer Java's enums, which are basically a full-blown class (with
> member variables and static and instance functions and everything), but
> with all valid instances of the class being declared in the enum at
> program start-up time. So, basically, a full class plus a bunch of
> "static BLAH = new ..." sorts of operations.
Strangely enough, I imagined to remember that it was C# that did enums
that way. Don't know where and when I mixed that up.
Yeah, I really do like that approach as well.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
