denisgolovan wrote 5 lines
And generics are complex because they lead to more accidental complexity
for reasons given earlier.
The Golang approach is to use interfaces, similar to freepascal's VARARGS but a bit different.. and more powerful. Interfaces, an overloaded term, not to be confused with COM/Corba interfaces...
i.e. a function that can take multiple types of "stuff".. without ever using generics or templates.
Someone on this list (maybe even me) mentioned that writing functions for arrays requires writing code multiple times that does basically the same thing but for different types...
You might be interested in this article:
http://wiki.c2.com/?IncludeFileParametricPolymorphism
I was able to make FPC compile code that took in multiple types to a function, without using generics, but just using fps's include file system. I believe golang's interfaces solve the issue more elegantly than using include file tricks, as the include file trick was just a prototype to prove it was possible..
A general purpose function that handles multiple types of arrays without rewriting the code for each array type looks like this:
procedure AddItemToArray(
const item: {$I T.inc}; var arr: {$I TArr.inc}); overload;
var len: integer;
begin
// below is the same for EVERY type! Reuse, Reuse!
len:= length(arr);
setlength(arr, len+1);
arr[len]:= item;
end;
Where $I T.inc defines the type being used.
Maybe I reinvented generics. Advantage of this, is no OOP (object orientation) required and it therefore works on any procedural code or OOP code, not just OOP code alone. One reason I dislike generics in modern languages is that it almost always requires object orientation to be used and you cannot program "generally" using procedural style coding. My include file parametric polymorphism allows procedural code to be written (such as dealing with simple arrays) generally.
Golang does it via interfaces..
Dynamic typed languages like php and python can do it because of dynamic typing allowing any type to be passed in "generally" without the compiler checking.. which IMO is a bug, not a feature.
VARARGS sort of allow one to program generally, by allowing a multi type to be passed in, then you check it at run time... That's similar to golang's interfaces but golang interface more powerful than a vararg.
By vararg I mean:
CallSomeCode([arbitrary, amount, of, parameters, of, any, type]);
Where the square brackets allow you to pass in sort of an "array of any type"
It is interesting that golang has been able to create an interface that can be sent in to a function/procedure, "generally", without resorting to any generics or c++ tempting tricks.. But the disadvantage is you have to check some things at run time, similar to RTTI or vararg checks...
if vararg.type = integer then..
if vararg.type = string then..
Whereas template systems tend to do these checks at compile time to save the run time checks...
My include file parametric polymorphism trick, does all the checks at compile time with no run time overhead. But it's an include file trick, not a language feature built in. I may have invented a general purpose generic way of writing code procedurally, which I find fascinating.. but I'm tooting my own horn.
