[fpc-devel] Functors

[Michael Van Canneyt]

On Sun, 26 Dec 2021, Blaise--- via fpc-devel wrote:

> On 26.12.2021 11:50, Michael Van Canneyt via fpc-devel wrote:
>> Please explain what's the point or benefit of this.
>
> Do you mean "in general", or "specifically to FPC"?
>
> A) In general: I reckon that the article covers the matter quite well; I have 
> nothing to add.
> B) Specifically for FPC: it is up to the users to decide whether they find 
> this useful; I am impartial.

Specifically to FPC.

>
> Personally for me, specifically for FPC, the points are:
> 1) A variant of that patch is already a part of the Closures -- it makes 
> sense to expose that to the users and get another feature (Functors) for 
> "half the price";
> 2) Orthogonality -- I would rather implement a proper feature instead of 
> employing a specific "hack" for a single case (translating an interface 
> reference into a call).
>
>> As I see it, it's just shorthand syntax to allow skipping the name 
> 'Invoke'.
>> None of what is shown below cannot be handled by ordinary methods
>
> Well, yes. But, following your reasoning, the same should be said about 
> overloading most of the operators: "why is aC+aD better than aC.Add(aD)"?

No. Operators are clearly expressions. ac.Add(aD) is a statement.

>> I find the resulting code aC(33) more confusing than anything else
>
> It should be less confusing if you think of aC as a routine (which is the 
> point of Functors). Would aCallback(33) look less confusing?

But it is not a routine. It is a class, and it is declared as one.

Pascal is very explicit about the constructs and classes it uses. 
It's a 'Strongly typed language' for a reason.

Blurring the line between functions and classes goes against this, in my
opinion.

>
>> I think the idea is overly complicated and can be achieved simply by the 
> mechanism used by default array properties:
>>     function Add9(const N: Integer): Integer; default;
>
> That could be an alternative /syntax/ for denoting the special method, but I 
> do not see how that would "uncomplicate" the /idea/. To me, that is exactly 
> the same idea with the same level of complication.

I was strictly speaking of syntax. 
The idea: I personally don't see the use, but that does not mean I would torpedo the idea.

>
> Likewise, conceptually, "default array properties" /is/ "operator []" with a 
> clunkier syntax and a benefit of being able to access such property by name.

We clearly disagree on what constitutes a clunkier syntax.

I would reject your proposal using Invoke.

Reusing "default" - it's just reusing an existing keyword as another modifier for methods.
The impact on syntax is negligible.

It also leaves you free to choose your identifiers. For backwards compatibility
alone the use of Invoke is a bad idea, specially since the RTTI invoke method
is prominently a part of RTTI.

As a second option the "call operator" would be acceptable. 
So from my perspective these are OK (one or both):

- Allow use of default
- Introduce 'Call' operator.

For me, the use of a specific method name is not acceptable for backwards compatibility.

Michael.