[fpc-devel] Functors

[Blaise at blaise.ru]

On 26.12.2021 19:33, Michael Van Canneyt via fpc-devel wrote:
> On Sun, 26 Dec 2021, Blaise--- via fpc-devel wrote:
>> On 26.12.2021 11:50, Michael Van Canneyt via fpc-devel wrote:
>>> 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.

How can you tell just from that? :) If Add is a function (which is clearly implied by the comparison with the operator Add), then "aC.Add(aD)" is an expression, just like "aC+aD".

Let me offer another comparison and rephrase my quote: following your reasoning, the same should be said about default array properties: "why is aC[42] better than aC.Items[42]"?

>> 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.

Imagine it is 1995, Delphi introduces default array properties, and my response is: "But a class is not an array. It is a class, and it is declared as one. Blurring the line between arrays and classes goes against Pascal being a 'Strongly typed language', in my opinion."
Even further: "What is this thing -- array property?! It is clearly invoking methods behind its back! A method call should not be masquerading as array indexing! It is not BASIC, Pascal has different brackets for calls and array indexing for a reason!

I understand when you say that you do not find functors useful; that is the matter of personal opinion and style. But to say that they are inconsistent with the modern Object Pascal as implemented by DCC and FPC?

> I would reject your proposal using Invoke.

Let us be precise here. You mean "procedure/function Invoke", right? Because "operator Invoke" (which is part of my proposal) would not clash with other entities named Invoke.

> Reusing "default"

As I wrote in my response to Ryan, I actually quite like that, except for one reservation: should the support for default interface methods be ever added to FPC, the DEFAULT directive would fit there better, IMO.
A dedicated directive would be fine with me, and it could be used to designate any compatible method as any operator:
-------8<-------
type R = record
	procedure Foo(...); operator ();
	function Bar(const A, B: R): R; operator +;
end;
-------8<-------

How about another approach, albeit more complex: does FPC support method aliasing? Personally, many times, I wished DCC had that.
-------8<-------
type R = record
	procedure Foo(...);
	operator () = Foo; // routine alias
	// OR: operator Invoke = Foo;
end;
-------8<-------
Routine aliasing is a more general (hence, more useful) feature on its own; and with it, even inherited methods can be designated as operators in derived classes.

-- 
βþ