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. 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)"?
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?
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. Likewise, conceptually, "default array properties" /is/ "operator []" with a clunkier syntax and a benefit of being able to access such property by name.
I think the idea of using a fixed member identifier for special purposes is really stupid design.
I would agree in general, but you did see that using the OPERATOR keyword is part of the proposal, right? "operator Add" is not necessarily worse than "operator +". -- βþ _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
