Phlip said:
Why can't the compiler just detect the use of class& and morph it into the
template expansion system currently used for template<class>?
(Because something could call the function that the compiler can't see yet,
unlike templates which have a fixed instantiation point, etc...)
The outer problem here is simply flexibility. I think having two redundant
systems to pass things into functions (either types or objects) is _less_
flexible than one unified system. Such unifications tend to force us to
invent the _weakest_ possible primitives, which then can be assembled in
new, emergent ways that language designers never thought of.
While whether flexibility can be improved by making classes objects is
largely a subject of debate, I would point out that flexibility give way
to program correctness when they conflict.
The inner problem is your unit tests should catch the error. ;-)
Why put an error to unit test while you could have eliminate it in the
first place?
And how are you so confident that your tests could catch all the errors?
I am not. And aren't you frustrated every time your browser pops up a
warning telling you some object doesn't support certain method? I am!
Can you do the Prototype Pattern with templates? The general point here is
that letting classes be objects makes many design patterns get shorter and
more trivial.
What does prototype pattern have to do with template? It can, of course,
be done in C++ with or without templates.
Type safety is a C++ feature. It is designed to restrict you from doing
something silly or inconsiderate in the first place. If you want to by
pass the type system you have to be explicit (so that you know what you
are doing)
As I said, flexibility gives way to correctness.
Regards,
Ben