[fpc-pascal] List of integers? Any class available in RTL or FCL to help?

Lars noreply at z505.com
Wed Dec 14 08:09:11 CET 2016

On Mon, December 5, 2016 7:05 am, denisgolovan wrote:
> 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:

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;
      // below is the same for EVERY type! Reuse, Reuse!
      len:= length(arr);
      setlength(arr, len+1);
      arr[len]:= item;

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.

More information about the fpc-pascal mailing list