You can definitely have heterogeneous lists in typed languages. They're almost always an anti-pattern, but you can do it in a few ways.
In Java, you could have a LinkedList<Object>. You'll need to cast to do any operations on the objects; but, it's a heterogeneous list anyway, so why would you?
There could be a reason, though.
Let's say they all have the same function, then, but they're different objects. Well, for that, you could write a wrapper object that all inherit from the same class, say:
interface Clicker { public void click(); }
public class ClickerWidget implements Clicker {
Widget w;
public void click() { w.click(with_parameters); }
}
Alternatively, Go supports "use the same function" in a different way by having an interface just define a set of functions, no matter their parent class, and as long as the type has that function, it works.
Please read my comment again. I didn't say no statically typed languages support them.
But your Java example isn't a true heterogeneous lists, very close but not really. You cannot put instances of value types into it.
Even if it were a true heterogeneous list. You have given up on static typing with such a list and defer it to runtime. Which is exactly the dynamic typing approach.
If you want to do tricky pointer stuff, the Java hack around that is an array that holds the pointer to the value instead; and, autoboxing allows ints into it. It’s a heterogeneous list.
The List<Object> cannot hold int, double etc. It can only hold the boxed variants. Auto boxing takes some of the pain away but it's still not a heterogeneous list which has the requirement that it can hold values of any type.
I'd wager that the up and coming inline classes in java also can't be put into a List<Object> but maybe I'm wrong.
No I don't think so. The main requirement of a heterogeneous list is that it can hold any type. In addition in a statically typed language I'd say to truly qualify as a heterogeneous list it should actually be typesafe. Java fullfills neither requirement.
Seems like the rub is "The main requirement of a heterogeneous list is that it can hold any type." when I think I would colloquially say, and use as a working definition, that they need to hold different types.
Also the rub is that "type" means two things: what a variable can have OR a class (that inherits from `Object`).
Like, chances are, the individual is going to say that Ruby provides that power; but, by the time you've reached Ruby levels of abstraction, the odds of any argument about performance and data marshalling go out the window.
It's a difference without a meaning, as far as I can tell.
In Java, you could have a LinkedList<Object>. You'll need to cast to do any operations on the objects; but, it's a heterogeneous list anyway, so why would you?
There could be a reason, though.
Let's say they all have the same function, then, but they're different objects. Well, for that, you could write a wrapper object that all inherit from the same class, say:
Alternatively, Go supports "use the same function" in a different way by having an interface just define a set of functions, no matter their parent class, and as long as the type has that function, it works.