[lazarus] classesh.inc change required

[Florian Klaempfl]

Marc Weustink wrote:
> 
> + From: Florian Klaempfl [mailto:Florian.Klaempfl at gmx.de]
> 
> <snip>
> 
> +
> + One important point is overloading, consider the following:
> +
> + type
> +    tf = function : integer;
> +
> + function f : integer;
> + procedure p(i : integer);
> + procedure p(f : tf);
> +
> + In Delphi mode you would write:
> +
> + p(f);
> +
> + but what should the compiler do? Call f and using the first
> + version p or
> + using the second one and passing the address of f?
> 
> As I wrote earlier this thread:
>   It is pretty clear if you take the following rule into
>   account:
> 
>   If a function/procedure matches the type of the var,
>   the adress of this function/procedure is passed.
>   In all other cases the evaluation of function/procedure(?).

What about a function returning a procedure variable? Here you get really
lost with Delphi :)

> 
> So in your example procedure p(f : tf) gets called.
> 
> Thats the same Delphi does. If you want to get f evaluated you should call p
> like: p((f)) so f gets evaluated first (bracket rule). Its still clear.

This is not pascal this is nonsense (to avoid explicit language). A bracket is in this
case a syntactical element and it shouldn't change the semantic of an expression!!!!

> 
> + In FPC mode it's clear:
> + p(f);
> + means calling f and using the integer version of p
> + while
> + p(@f);
> + calls the second one
> 
> + It even works if you've a third version of p:
> + procedure p(p : pointer);
> +
> + p(@f);
> + still calls the second version because the last one would
> + require an (implicit) type cast,
> + if you
> + want to call the last one you have to write
> +
> + p(pointer(@f));
> 
> ??? That is IMHO dependig of the result of the @ operator is
> typed or untyped (depending on the T derective)

I'am always assuming @ returns a typed pointer :).


Besides that, FPC lets choose what you want.