A C# Event Primer (for iago!)

[MyndFyre]

This was for iago!!!

[Joe]

I don't have time to read it right now (late for work -- damn you x86!), but a big TIA goes out to you for when I finally do.

[while1]

Sweet.

Thanks Mynd.  Although I'm not in a situation where I'm required to familiarize myself with C# for a job or school, as a hobby I always enjoy expanding my scripting and programming language repertoire.

Reading the first couple of paragraphs, it seems like this primer is great for someone like myself too because I'm in the same boat as you when you first started with C# (AP CS and one semester of Java at university, but not any advanced or extensive use of Java).

Thanks again, now I have some reading material for my two hour backseat drive to university.

[Camel]

Always remember to check for nullility!

[iago]

Incidentally, thanks for writing that. I'll read it soon!

[iago]

All righty!

I started reading it, and realized I was somewhat over my head. So I went and read this tutorial and read it again. Much better the second time around!

The part of the tutorial about events confused me, but after reading your primer I understood. Woohoo!

[MyndFyre]

Awesome, glad to hear it! Are you a convert yet?

[iago]

From what I've seen, definitely not. Everything about the language feels icky and hackish. The whole "We need to do this" "We can't" "Find a way!" mindset. I don't like it at all. I hate overloaded operators a lot, and the "properties" thing has the same icky feeling to it that I don't like in overloaded operators.

So yeah, overall, I hate it. I think they had some good ideas, but they made the mistake of trying to make it look like C++. I don't know how I would have done it, but I don't like how they did.

[Camel]

Agreed!

Java is, syntactically, beautiful. As for its implementation, well, that's another story.

[abc]

Agreed!

Java is, syntactically, beautiful. As for its implementation, well, that's another story.

Funny, I hate Java, but I love C#.

[iago]

Agreed!

Java is, syntactically, beautiful. As for its implementation, well, that's another story.

Funny, I hate Java, but I love C#.

C# has a lot of nice ideas, but I don't like how they were implemented at all.

[Warrior]

Agreed!

Java is, syntactically, beautiful. As for its implementation, well, that's another story.

Funny, I hate Java, but I love C#.

C# has a lot of nice ideas, but I don't like how they were implemented at all.

What do you mean specifically?

[iago]

A lot of different things. But I know better than to get into a discussion about anything Microsoft-related with you, so I'm not going to bite.

[Warrior]

A lot of different things. But I know better than to get into a discussion about anything Microsoft-related with you, so I'm not going to bite.

I won't jump, promise. I genuinely want to know

[iago]

A lot of different things. But I know better than to get into a discussion about anything Microsoft-related with you, so I'm not going to bite.

I won't jump, promise. I genuinely want to know

Fine, since you promised. These are just the things that bug me most.

My least favorite thing so far is pointers, though. Having to declare variables as "fixed" indicates a fundamental problem: they're trying to add a low-level paradigm to a high-level language, and end up with ugly constructs like that. It doesn't have a good feeling to me.

I also hate operator overloading. To me, a + should always add and a << should always left-shift. C# provides operator overloading, which is something I can get over. However, when using, for example, delegates, you add all your events to your delegate with + and remove them with -. That kind of thing just isn't right, to me. Then when you want to find out if it's empty, you compare it to null. That's just confusing, it took me awhile to figure out how a non-reference variable could be null. In my opinion, it's exactly why operator overloading is bad.

Another thing I don't like is that they .. damnit, I got an email and left for 10 minutes, so I totally forget what I was writing. Ohwell.

[MyndFyre]

Fine, since you promised. These are just the things that bug me most.

My least favorite thing so far is pointers, though. Having to declare variables as "fixed" indicates a fundamental problem: they're trying to add a low-level paradigm to a high-level language, and end up with ugly constructs like that. It doesn't have a good feeling to me.

I also hate operator overloading. To me, a + should always add and a << should always left-shift. C# provides operator overloading, which is something I can get over. However, when using, for example, delegates, you add all your events to your delegate with + and remove them with -. That kind of thing just isn't right, to me. Then when you want to find out if it's empty, you compare it to null. That's just confusing, it took me awhile to figure out how a non-reference variable could be null. In my opinion, it's exactly why operator overloading is bad.

Another thing I don't like is that they .. damnit, I got an email and left for 10 minutes, so I totally forget what I was writing. Ohwell.

Muwahahahaha, I didn't promise!

For the record, C# pointers don't always work with the fixed keyword.  They only are used when you need to obtain a pointer to a heap-allocated, garbage-collected object.  Arrays are heap-allocated except when using the stackalloc keyword:

Code: [Select]

unsafe void PointMe()
{
    byte* ptr = stackalloc byte[80];
}
Stack-allocated memory is intrinsically cleaned up at the end of a function scope.  The fixed keyword exists to inform the garbage collector not to automatically relocate an object during a garbage collection pass.  As I've gone farther in my C# use, I do what I can to avoid using fixed in favor of other constructs (Marshal.AllocHGlobal, Marshal.AllocCoTaskMem, and stackalloc - as far as I'm concerned, Marshal.AllocHGlobal and AllocCoTaskMem are the same as using malloc).

For operator overloading, best practices indicate that the overloaded operators should be used only for the mathematical functions they represent.  For instance, MBNCSUtil's BigInteger has overloaded operators for all of its numeric functions.  Best practices further dicate that there should be named functions (such as Add()) for any overloaded operators.

As for delegates and events, I suppose it's a matter of preference:

Code: [Select]

this.btnOK.Click += new EventHandler(this.btnOK_Click);
// vs.
this.btnOK.addActionListener(new ButtonActionListener(this));
To me, += and .addXXX() pretty much equate to the same thing.  I think of += as syntactic sugar - I can say

Code: [Select]

Delegate.Join(btnOK.Click, new EventHandler(btnOK_Click));

And you're mistaken about delegates and events - they *are* reference types.  That's why you need to check for nullility.

I agree with you - I don't like e-mail.  Particularly work things are notorious for pulling me away from important things like posting on the forums.  I think we should make e-mail illegal immediately!

[Camel]

I've got to agree with iago. In Java, the delegates issue is solved by storing a List of a particular type of interface. Additionally, you can declare anonymous classes, which means you can do cool things like this:

Code: [Select]

tray.addMouseListener(new MouseListener() {
public void mouseClicked(MouseEvent e) {
if(e.getButton() == MouseEvent.BUTTON1) {
setVisible(!isVisible());
if(isVisible())
toFront();
}
}
public void mouseEntered(MouseEvent e) {}
public void mouseExited(MouseEvent e) {}
public void mousePressed(MouseEvent e) {}
public void mouseReleased(MouseEvent e) {}
});
The implementation code is quite elegant:

Code: [Select]

public class SomethingWithEvents {
List<EventHandlingInterface> delegates = new ArrayList<EventHandlingInterface>();

public boolean addDelegate(EventHandlingInterface ehi) {
return delegates.add(ehi);
}

private void doEvent(...) {
for(EventHandlingInterface ehi : delegates)
ehi.eventName(...);
}
}

I think MyndFyre said something about this coming to .NET in 3.0?

[Camel]

And you're mistaken about delegates and events - they *are* reference types.  That's why you need to check for nullility.

What? In Java, an empty list is not null, they are a reference to a List object that happens to have no contents. I think this is what iago was pointing out.

[iago]

Muwahahahaha, I didn't promise!

Luckily, it's mostly preference stuff, so I can't really argue any of your points. Plus, I don't like the idea of being on the same side as Camel.

But it's really hard to explain, things just feel hackish to me. *shrug*

[Camel]

Plus, I don't like the idea of being on the same side as Camel.

That's a wise position to take.

[MyndFyre]

I've got to agree with iago. In Java, the delegates issue is solved by storing a List of a particular type of interface. Additionally, you can declare anonymous classes, which means you can do cool things like this:

Code: [Select]

tray.addMouseListener(new MouseListener() {
public void mouseClicked(MouseEvent e) {
if(e.getButton() == MouseEvent.BUTTON1) {
setVisible(!isVisible());
if(isVisible())
toFront();
}
}
public void mouseEntered(MouseEvent e) {}
public void mouseExited(MouseEvent e) {}
public void mousePressed(MouseEvent e) {}
public void mouseReleased(MouseEvent e) {}
});

See, the difficulty there is that you're still creating an entire type to handle a signal, when a function will do.

C# 2.0 (2005) introduced anonymous methods so that function definitions wouldn't need to be class members:

Code: [Select]

btnClickMe.Click += delegate { MessageBox.Show("*GASP!* You clicked me!"); };
Anonymous methods also support parameters:

Code: [Select]

btnClickMe.MouseDown += delegate(object sender, MouseEventArgs e) { MessageBox.Show(string.Format("({0}, {1})", e.X, e.Y)); };


The implementation code is quite elegant:

Code: [Select]

public class SomethingWithEvents {
List<EventHandlingInterface> delegates = new ArrayList<EventHandlingInterface>();

public boolean addDelegate(EventHandlingInterface ehi) {
return delegates.add(ehi);
}

private void doEvent(...) {
for(EventHandlingInterface ehi : delegates)
ehi.eventName(...);
}
}

I think MyndFyre said something about this coming to .NET in 3.0?

This has actually been part of .NET since the beginning.  A little-known (because it's really not used much) feature of C# (and actually, VB too) is that you can manually provide event backing fields for events:

Code: [Select]

private EventHandler handlers;
public event EventHandler Clicked
{
    add(EventHandler eh)
    {
        Delegate.Combine(this.handlers, eh);
    }
    remove(EventHandler eh)
    {
        Delegate.Remove(this.handlers, eh);
    }
}
Invocation is then done:

Code: [Select]

if (handlers != null)
  handlers(this, EventArgs.Empty);

Though, I still think that from an OO standpoint, the fact that an object posesses properties and events, and that other objects listen to those events by registering for them, is more clear than registration via a behavior (which is what a method is supposed to represent - a behavior).

Incidentally, this is (more or less) what the compiler does when you create:

Code: [Select]

public event EventHandler Clicked;


[Camel]

See, the difficulty there is that you're still creating an entire type to handle a signal, when a function will do.

If your quarrel is with the bulky code, I agree with you. However, your concerns are mostly unwarranted because hotspot will optimize this down beyond an anonymous method if possible. I say mostly because hotspot does this optimization at runtime, not compile time. The bytecode in the class files still has the extra info.

There's no way to say that either Java or C# is inherently better than the other, however, the preference always seems to come back to the same thing: what OO means to you. In Java, it means everything is an instance of an <Object>. This makes the language intrinsically simpler to learn, and, in my opinion, more elegant.

[MyndFyre]

There's no way to say that either Java or C# is inherently better than the other, however, the preference always seems to come back to the same thing: what OO means to you. In Java, it means everything is an instance of an <Object>. This makes the language intrinsically simpler to learn, and, in my opinion, more elegant.

But see, in Java, everything *isn't* an instance of <Object>.

Code: [Select]

int i = 5;

i isn't an Object.  It is in C#, though!

[Joe]

Agreed!

Java is, syntactically, beautiful. As for its implementation, well, that's another story.

You missed something: Java and C# syntax are 99.9% the same. I've copy/pasted hundreds of lines of my Java code into C#, fixed the API references, and then ran them with zero syntax conversion.

[Camel]

There's no way to say that either Java or C# is inherently better than the other, however, the preference always seems to come back to the same thing: what OO means to you. In Java, it means everything is an instance of an <Object>. This makes the language intrinsically simpler to learn, and, in my opinion, more elegant.

But see, in Java, everything *isn't* an instance of <Object>.

Code: [Select]

int i = 5;

i isn't an Object.  It is in C#, though!

Java will automatically cast an int to an <Integer> if you try to use it as an object, and you're splitting hairs.

Agreed!

Java is, syntactically, beautiful. As for its implementation, well, that's another story.

You missed something: Java and C# syntax are 99.9% the same. I've copy/pasted hundreds of lines of my Java code into C#, fixed the API references, and then ran them with zero syntax conversion.

I was clearly talking about corner cases: enums, anonymous types, delegates, etc.

[MyndFyre]

Java will automatically cast an int to an <Integer> if you try to use it as an object, and you're splitting hairs.

You still need to allocate a heap object.  It's not so much a splitting-hairs thing so much as a "here's a big difference between the runtimes."

[Chavo]

Speaking of split hairs, I'm thinking about trying a new shampoo.  What do you think?

[Camel]

Java will automatically cast an int to an <Integer> if you try to use it as an object, and you're splitting hairs.

You still need to allocate a heap object.  It's not so much a splitting-hairs thing so much as a "here's a big difference between the runtimes."

I don't know how .NET handles this situation; could you enlighten me?

FWIW though, your point seems to be moot, since all objects in all languages exist in the heap. Maybe I missed your point?

[MyndFyre]

FWIW though, your point seems to be moot, since all objects in all languages exist in the heap. Maybe I missed your point?

Hmm, maybe you don't know how all languages work?

In .NET, value-types (everything declared with the struct keyword instead of the class keyword, as well as enums) live on the stack instead of on the heap.  The .NET stack, like the x86 stack, is a place for temporary variables.  So let's say I have a class that holds 12 bytes of information; we'll push the stack by 12 bytes and say that the memory space between that push is where the variable lives.  When a function is called referencing the variable, the variable is copied to the new stack.  So for example:

Code: [Select]

// C#
public struct Point
{
  public int X, Y;
}
public class CPoint
{
  public int X, Y;
}
void Test()
{
  Point p = new Point() { X = 10, Y = 20 };
  ModifyPoint(p);
  Console.WriteLine("({0}, {1})", p.X, p.Y);
  CPoint cp = new CPoint() { X = 15, Y = 30 };
  ModifyPoint(cp);
  Console.WriteLine("({0}, {1})", cp.X, cp.Y);
}
void ModifyPoint(Point p)
{
  p.X *= 2;
  p.Y *= 2;
}
void ModifyPoint(CPoint p)
{
  p.X *= 2;
  p.Y *= 2;
}

The output of this is:

Code: [Select]

(10, 20)
(30, 60)

This is similar to C and C++:

Code: [Select]

typedef struct tagPOINT
{
  int X;
  int Y;
} Point;
void ModifyPoint(Point p)
{
  p.X *= 2;
  p.Y *= 2;
}
void ModifyPPoint(Point *p)
{
  p->X *= 2;
  p->Y *= 2;
}
void ModifyRPoint(Point& p)
{
  p.X *= 2;
  p.Y *= 2;
}
Now, C++ gives you a little more flexibility:

Code: [Select]

Point p; // allocates 8 bytes on the stack
Point* p = new Point; // allocates 8 bytes on the heap and the machine pointer size on the stack
You can use all 3 modify-point functions on the first one (since you can get a pointer to a stack variable as well), but you can only use the ModifyPPoint function on the heap object.

Incidentally, this is the way Java treats primitive types too.  You just can't expect them to change when they get back to the original function.  If I have an int in Java, and I call toString() on it, the compiler implicitly creates a new Integer object on the heap and calls the function on that.  IMO that's a bit of a hack.  OTOH, .NET calls .ToString() directly on the int on the stack.

[Camel]

Objects are instances of classes. In most languages, they are created with the new keyword (which is equivalent to a malloc() call plus a call to the constructor), and therefore can only exist on the stack as a pointer to the heap.

Java's elegance comes from its purity. There speed advantage of keeping an object on the stack (avoiding references to "far" memory locations) is so negligible that it isn't worth justifying in such a high level language. KISS is a founding principle of Java.

[MyndFyre]

Objects are instances of classes. In most languages, they are created with the new keyword (which is equivalent to a malloc() call plus a call to the constructor), and therefore can only exist on the stack as a pointer to the heap.

Except, in C++, you can create an object on the stack.  It'll still have its vtable and all its methods.  I demonstrated how this is done in my previous post.  Which "most" languages are you referring to?

Java's elegance comes from its purity. There speed advantage of keeping an object on the stack (avoiding references to "far" memory locations) is so negligible that it isn't worth justifying in such a high level language. KISS is a founding principle of Java.

It's not a speed advantage for object maintenance.  The real speed advantage is to prevent heap fragmentation.  If you have to allocate a lot of small, short-lived objects frequently, it's better to allocate them on the stack instead of the heap.  In garbage-collected languages this is even more true, because the memory won't be freed until a GC pass, whereas stack-allocated objects are freed as soon as you pop a method from the call stack.

[Camel]

Objects are instances of classes. In most languages, they are created with the new keyword (which is equivalent to a malloc() call plus a call to the constructor), and therefore can only exist on the stack as a pointer to the heap.

Except, in C++, you can create an object on the stack.  It'll still have its vtable and all its methods.  I demonstrated how this is done in my previous post.  Which "most" languages are you referring to?

Structs are not objects! They're groups of variables packed together. The ability of many C compilers to add methods to a struct is a non-ANSI compliant hack.

[edit] Also, in the Java world, if an object is not stored by reference in the heap, it is destroyed marked for destruction when its scope ends. Memory fragmentation is irrelevant; computers are fast, and if you allocate from the heap in a round-robbin fashion, you won't run in to any serious speed pitfalls.

[Camel]

We settled this on AIM. We decided that both languages need a delete operator. Also, x86 should have free pie whenever iago's server goes down.

[Joe]

We settled this on AIM. We decided that both languages need a delete operator. Also, x86 should have free pie whenever iago's server goes down.

And pizza and ice cream.

And soda.

And turkey!

[MyndFyre]

We settled this on AIM. We decided that both languages need a delete operator*. Also, x86 should have free pie whenever iago's server goes down.

*that MyndFyre was correct.

[Camel]

Oh no you didn't!

[iago]

Eww @ how the "new" operator has been redefined. Now it can allocate on the stack or the heap depending on the context. That feels icky. :-/ Now if you need to know how an object is allocated, you have to look up information about the object (whether it's a struct or class), and if it's the wrong one you're outta luck. Doesn't seem right...

[Camel]

That's not even the worst part, iago. They had to overload the new operator to do it!

[MyndFyre]

That's not even the worst part, iago. They had to overload the new operator to do it!

Wait, what?  You can't overload the new operator!  It's not supported!  New operator only exists to invoke the constructor!

Eww @ how the "new" operator has been redefined. Now it can allocate on the stack or the heap depending on the context. That feels icky. :-/ Now if you need to know how an object is allocated, you have to look up information about the object (whether it's a struct or class), and if it's the wrong one you're outta luck. Doesn't seem right...

How often do you need to know how an object is allocated? 

In practice (and I have a lot of it), you rarely define structs.  They have their purpose, but you know when you're using them what you're getting.  They have an enormous speed advantage when it comes to allocation (if I recall my speed tests, a couple orders of magnitude), but they're limited in utility because they're passed by value, unless you explicitly pass them by reference (using ref or out), but then they might as well be classes.

[Camel]

IF YOU LOVE THEM SO MUCH WHY DON'T YOU MARRY THEM?

[edit] Yes, it did take me all of fourth grade to come up with that one.

[iago]

How often do you need to know how an object is allocated? 

Unrelevant! If they're going to make it possible to know where objects are, they should make it consistent. Besides, you do need to know when you're passing it as a parameter. Depending on what the variable type is (whether it's a struct or a class or a base type (int, double)), a variable is passed to a function differently. The only way you can know how (I think?) is by looking up the declaration for that variable type. That's all very icky, there's little consistency!

In practice (and I have a lot of it), you rarely define structs.  They have their purpose, but you know when you're using them what you're getting.  They have an enormous speed advantage when it comes to allocation (if I recall my speed tests, a couple orders of magnitude), but they're limited in utility because they're passed by value, unless you explicitly pass them by reference (using ref or out), but then they might as well be classes.

structs in general feel like a hack.

[MyndFyre]

structs in general feel like a hack.

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

[iago]

structs in general feel like a hack.

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

You just said they're useless!

The difference between a struct in C# and a potential class in Java: the struct is faster and passed by value. Big deal!

[MyndFyre]

You just said they're useless!

Nuh uh!

They have their purpose

[iago]

You just said they're useless!

Nuh uh!

They have their purpose

Yeah, after "you rarely define structs"!

Either way, I think I make a good point.

[MyndFyre]

Either way, I think I make a good point.

So did Hitler. 

[iago]

Either way, I think I make a good point.

So did Hitler. 

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

[Blaze]

Either way, I think I make a good point.

So did Hitler. 

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]

structs in general feel like a hack.

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

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]

structs in general feel like a hack.

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

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]

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]

Integer i = (int)2;
Java also has automatic unboxing:

Code: [Select]

int i = new Integer(2);
If you switch down to a Java 1.4 compiler, and try to compile the following:

Code: [Select]

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?

[Camel]

If you pass a struct to a method in C#, the instance passed to the method is not the originating instance, because it is copied on to the stack. That means if you modify its state, the original object does not reflect the changes. Since this isn't how objects work in C#, even though structs are objects, it's confusing, breaks OOD, and is a hack.

[MyndFyre]

If you pass a struct to a method in C#, the instance passed to the method is not the originating instance, because it is copied on to the stack. That means if you modify its state, the original object does not reflect the changes. Since this isn't how objects work in C#, even though structs are objects, it's confusing, breaks OOD, and is a hack.

But you're not invoking the behavior on the object.  You're invoking the behavior of another object using the state of the object in question.  And you're still confusing an object behavior with a semantic language behavior.  When you modify its state, you're modifying a new copy.

You say it breaks OOD.  Name six examples.

[Camel]

If structs are going to outright violate the rules defined for a System.Object, but they are still defined as a subclass of System.Object, that's a clear violation of OOD. If you are seriously going to sit here and tell me that behavior is restricted to state transitions of the instance, you should consider giving some of those certifications back.

Here are the six examples you asked for:

Code: [Select]

int i = 1;

Code: [Select]

long l = 1234567890;

Code: [Select]

double d = 42.1;

Code: [Select]

float f = 0.5;

Code: [Select]

byte b = 127;

Code: [Select]

char c = 'X';