{solved} Is it possible to overload functions to have different result types

[Kraig]

I just thought of another approach but haven’t tried it yet
Since I’m trying to find a good way to store and retrieve values of different types from an ini file.
How about something like

Code: Pascal  [Select][+][-]

1. Function ini (const default:tcaption):tcaption;
2. Function ini (const default:boolean):boolean;
3. Function ini (const default:integer):integer;
4. Procedure ini (const avalue:tcaption);
5. Procedure ini (const avalue:boolean);
6. Procedure ini (const avalue:integer);
7.  

As a replacement for

Code: Pascal  [Select][+][-]

1. Property ini:tcaption read getini write setini ;
2.  

Which can only handle one data type. It seems easy to override setini to accept any value but the same cannot be said for getini

[Zvoni]

What about generics?

[cdbc]

Hi
How about "TVarRec"? ...the datatype used in this construct"const Args: array of const".
There you have the "VType" field to test...
Just my 2 cents
Regards Benny

[jamie]

I just thought of another approach but haven’t tried it yet
Since I’m trying to find a good way to store and retrieve values of different types from an ini file.
How about something like

Code: Pascal  [Select][+][-]

1. Function ini (const default:tcaption):tcaption;
2. Function ini (const default:boolean):boolean;
3. Function ini (const default:integer):integer;
4. Procedure ini (const avalue:tcaption);
5. Procedure ini (const avalue:boolean);
6. Procedure ini (const avalue:integer);
7.  

As a replacement for

Code: Pascal  [Select][+][-]

1. Property ini:tcaption read getini write setini ;
2.  

Which can only handle one data type. It seems easy to override setini to accept any value but the same cannot be said for getini

Is there something wrong with TIniFile ? located in inifile unit.

[Kraig]

Is there something wrong with TIniFile ? located in inifile unit

Not that I know of

Also I don’t really understand how generics would work with inifile..

Are variants used something like this ?

Property ini :variant read get_ini write set_ini

[TRon]

Since I’m trying to find a good way to store and retrieve values of different types from an ini file.

See https://wiki.freepascal.org/Using_INI_Files

Is there something wrong with TIniFile ? located in inifile unit

Not that I know of

In which case it begs the question as of why you are trying to re-invent the wheel.

Don't get me wrong, you might have perfect valid reasons to be wanting to do so but as for most others that replied so far it eludes us of what those reasons might be. So any advise is just a crystal ball trying to match your expectations without having made those expectations clear.

[Kraig]

Thanks everyone for the answers. I will study which option will work best

[PascalDragon]

I’m a bit confused about the syntax of the solutions.

It is a fairly new feature called operator (overloading).

If you consider at least 24 years as “fairly new”, then yes, operator overloading is new

No the read and write family of functions (as well as some others) are not functions at all and don't follow any rule for function parameters. They are just compiler magic. There is no way, not with array of const, nor with generics or any other in language feature of Pascal to write a function that behaved like read or write(ln)

I'll take your word for it.

Warfly is right about that. A Write(Ln/Str) or Read(Ln/Str) call is decomposed into multiple different calls which is what allows it an essentially infinite number of parameters without it being declared as such anywhere. Not to mention support for the <IDENTIFIER>:<NUMCHARS>:<DECIMALS> syntax (which is also supported by the Str intrinsic).

OTOH, if i remember correctly, in assembly a Function is still a "procedure" with the "difference" being that the result-value is passed as the "last" parameter as an "out"-param (in a special (?) register)
(i don't know the "words" to describe it better)

There is a certain ABI one is expected to follow in assembly language that is also followed by higher level languages. This allows interoperability between languages. In general there is a single register that is designated as a result register. For i386 that's the EAX register, for x86_64 RAX, for ARM it's R0, for Aarch64 X0 and so on. out (or var) parameters on the other hand are essentially passed as pointers to the passed in variable. So, yes, there is a difference between functions and procedures with out/var parameters.

[TRon]

I’m a bit confused about the syntax of the solutions.

It is a fairly new feature called operator (overloading).

If you consider at least 24 years as “fairly new”, then yes, operator overloading is new

You have a point (though, I would not have expected otherwise) 

My point of view for my remark was made in the grant scheme of things (50+ years and current/previous marketing) and considering the fact that TS mentions being confused by the syntax.

The latter usually means that TS has never seen the syntax before and therefor I assume(d) old school Pascal user. TP, BP and (first nine or ten version of ?) Delphi did not support user defined assignment overloading either and no matter how sad it is for people to not have known FPC earlier, fact is that most people mean Delphi (or even BP) when they refer to Pascal. I am not aware of another Pascal implementation that offered the feature earlier (but my knowledge on other Pascal compilers is not noteworthy).

Besides that I wanted to soften the blow by not explicitly stating that someone missed a feature for almost a quarter of a century