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.
--
βþ
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
