A C# Event Primer (for iago!)

[MyndFyre]

Either way, I think I make a good point. :P

So did Hitler.  :P

[iago]

x86/64] link=topic=10484.msg135456#msg135456 date=1194645092]

Either way, I think I make a good point. :P

So did Hitler.  :P

If Hitler was alive, he'd probably like C#. So you must be wrong.

[Blaze]

x86/64] link=topic=10484.msg135456#msg135456 date=1194645092]

Either way, I think I make a good point. :P

So did Hitler.  :P

If Hitler was alive, he'd probably like C#. So you must be wrong.

Obviously!  Also, Stalin would still be boasting about how QBasic is the best.

[iago]

Incidentally, shame on Myndy for invoking Godin's Law! :)

[MyndFyre]

Incidentally, shame on Myndy for invoking Godin's Law! :)

Hahahahahahaha.  <3!

[Camel]

x86/64] link=topic=10484.msg135440#msg135440 date=1194634884]

structs in general feel like a hack. :)

Only because they do something useful that Java doesn't. :P

The reason I structs seem hacky to me is that they are subclasses of Objects, but their behavior is completely different. You can't even do that in C#, which definitely makes it a framework hack.

[Joe]

x86/64] link=topic=10484.msg135440#msg135440 date=1194634884]

structs in general feel like a hack. :)

Only because they do something useful that Java doesn't. :P

You just said they're useless!

The difference between .. C# and .. Java: [C#] is faster. .. Big deal!

[MyndFyre]

The reason I structs seem hacky to me is that they are subclasses of Objects, but their behavior is completely different. You can't even do that in C#, which definitely makes it a framework hack.

Wait, what?  I just described how you do it in C#....  You declare it as a "struct" instead of a "class."

C#'s type system is unified such that a value of any type can be treated as an object. Every type in C# directly or indirectly derives from the object class type, and object is the ultimate base class of all types.

.....

However, unlike classes, structs are value types and do not require heap allocation. Struct types do not support user-specified inheritance, and all struct types implicitly inherit from type object.

[Camel]

Structs are classes, but instances of structs do not behave the same as instances of classes. How is that not hacky? Behavior is supposed to be inherited, not arbitrarily redefined.

[MyndFyre]

Structs are classes, but instances of structs do not behave the same as instances of classes. How is that not hacky? Behavior is supposed to be inherited, not arbitrarily redefined.

It's not "arbitrarily" redefined - it's formally defined.  See: the C# language reference.

That's like saying that floats are numbers, and integers are numbers, but they do not behave the same.

[iago]

x86/64] link=topic=10484.msg135605#msg135605 date=1194829428]

Structs are classes, but instances of structs do not behave the same as instances of classes. How is that not hacky? Behavior is supposed to be inherited, not arbitrarily redefined.

It's not "arbitrarily" redefined - it's formally defined.  See: the C# language reference.

That's like saying that floats are numbers, and integers are numbers, but they do not behave the same.

It's formally defined, but, as much as it hurts to agree with Camel, I think it feels like a hack. floats and integers behave the same way (or, at least, consistently) when you perform the same operations on them, which isn't something that can be said for structs (in my opinion).

[MyndFyre]

So, int can behave both ways in Java too, right?  So it's a hack too?

Or how about the way that autoboxing was hacked into the Java compiler but doesn't have intrinsic support in the runtime?

[iago]

I don't believe that int can behave both ways. The base type (int) behaves like a base type, and the class (Integer) behaves another way. There are things in Java that feel hackish, but that's not one of them.

I have no idea what autoboxing is. I don't have a whole lot of formal training in languages except for C, so I don't know the terms for a lot of things.

[Camel]

When did agreeing with me become inherently tabu?

In Java, ints do not behave both ways. Ints are base types, and are passed, as all base types are, by value. Integers are Objects, and are passed, as all Objects are, by pointer-value. There are no Java Objects that revert to being passed as the sum of their fields (with the exception of uboxed numbers, which doesn't count).

Autoboxing is the silent up-conversion of a base type to an Object. Ex:

Code Select Expand

Integer i = (int)2;

Java also has automatic unboxing:

Code Select Expand

int i = new Integer(2);

If you switch down to a Java 1.4 compiler, and try to compile the following:

Code Select Expand


Integer x = new Integer(1);
Integer y = new Integer(2);
Integer z = x + y;


You will get an error indicating that two Objects can not be added together. In Java 5, this was solved by adding autoboxing/unboxing; the third line will unbox the Integers to ints, add them, and autobox them back in to an Integer.

It isn't hacky because it's intuitive, and it isn't in the runtime for two reasons: one, for backwards compatibility. Two, you can't overload operators in Java. As we've already discussed, Java doesn't believe in operator overloading, with the exception of number objects (because they're being used to do math on numbers which is intuitive) and java.lang.Strings (because typing out .concat is tedious and is less intuitive than using +). There simply aren't any other conditions where the + operator, or any operator for that matter, can be used intuitively.

C# structs are hacky because they aren't intuitive, and because they don't inherit behavior from their parent class, System.Object.



If you really are going to insist that autoboxing is hacky, you should also complain about the automatic import of java.lang.*, because it's equally as hacky, and less intuitive.

[MyndFyre]

C# structs are hacky because they aren't intuitive, and because they don't inherit behavior from their parent class, System.Object.

Do you understand what "behavior" means in an object-orientation sense?

Behavior in OO land is the type of behaviors an object exhibits to the outside world - ways to change state.  Whether an object lives on the heap or the stack is not part of OO, nor is whether an object is copied by value or reference - it's entirely a semantic part of the language.  The fact that a language enables you to define it indicates that it's rather expressive, instead of hackish, don't you think?