Well, actually, in C# struct instances ARE objects allocated on the stack, instead of the heap.

A parallel can be drawn with C++ in which the user of a class decides on declaration/initialization where to store the object (either on the stack, or on the heap). The difference with C++ is that in C# the author of the class decides where instances of it should be stored, so this decision happens when the class is declared, not when it's used.

Otherwise there are few differences between structs and classes and all differences stem from the differences in storage. For example struct instances must be passed by value and not reference, because by definition stack-allocated values are short-lived and playing with references to stack-allocated values is dangerous. Structs must also have an implicit constructor because stack-allocated values cannot be NULL (logically, you need a reference to represent NULL).

In my experience, all discussions about what is or isn't an object are counter-productive.

What really bugs me about Java is that you cannot build your own types that behave just like the built-in types. For instance you cannot override operators like "+" (which works for primitives or Strings), you cannot override [] (which works for arrays), you cannot declare other stack-allocated structures, arrays are reified and yet you cannot declare your own reified data-structures and so on. The presence of primitives doesn't bother me as much as lacking the means to build my own primitives.

>In C# primitives are not objects

http://msdn.microsoft.com/en-us/library/system.valuetype(v=V...

>Data types are separated into value types and reference types. Value types are either stack-allocated or allocated inline in a structure. Reference types are heap-allocated. Both reference and value types are derived from the ultimate base class Object.

No, a class's methods are not instances of java.lang.reflect.Method. The latter is simply a 'reflection', per the package name, of first class JVM construct e.g. a reflection on a method.

An inner class is the ugly half-brother of a closure. 99% of the time they're used they define just one method.

When they are used for more than 1 method implementations, well ... they shouldn't be inner classes.

They just exist to fill the gap of having no closures. I say this as a long time and affectionate java user but project lambda in JDK8 is long overdue.

I think the experience of Haskell is relevant here. Once Haskell introduced first class functions, everyone stopped using typeclasses.

[edit: apparently my sarcasm was too subtle. HOF and typeclasses are both vitally important pieces of Haskell, which are orthogonal to each other. I'm pretty sure both were in Haskell from day 1. Some code for which both are essential:

    class Monad m where
      (>>=) :: m a -> (a -> m b) -> m b
      (>>) :: m a -> m b -> m b
      return :: a -> m a
      fail :: String -> m a

]

Not sure I agree with the GP's point, but I believe he's arguing that when fulfilling the contract of a fictional MouseClickListener:

  interface MouseClickListener {
    void mouseClicked(MouseEvent e);
  }

one often uses an anonymous class to do so:

  void init() {
    mouse.setClickListener(new MouseClickListener() {
      void mouseClicked(MouseEvent e) {
        println(e);
      }
    });
  }

the exact effect could be achieved with a reference to a named function (if Java supported them, which presumably it will once "everything is an object"):

  void init() {
    void mouseClick(MouseEvent e) { println(e); }
    mouse.setClickListener(mouseClick);
  }

given that interfaces are simply syntax for function routing, when you have the ability to reference functions by first-class types (i.e. you have the ability to determine function routing yourself), the set of things that you can only sensibly do with interfaces is a lot smaller.

This is how C# delegates work, right? Any Java -> C# programmer want to comment on whether they rely less on interfaces now and what they use them for?

Clojure, Golang, Scala and Rust all implement similar interface.