[fpc-pascal] private type and type compatibility

[Sven Barth]

Am 31.10.2013 12:38, schrieb Frederic Da Vitoria:
> 2013/10/31 Sven Barth <pascaldragon at googlemail.com 
> <mailto:pascaldragon at googlemail.com>>
>
>     Am 31.10.2013 02:45, schrieb Xiangrong Fang:
>>     2013/10/30 Jonas Maebe <jonas.maebe at elis.ugent.be
>>     <mailto:jonas.maebe at elis.ugent.be>>
>>
>>
>>         This is not equivalent. A private type declaration in a class
>>         adds a new identifier that is visible inside that class. You
>>         then use it, still in that class, to declare the return type
>>         of a function. Next, in a scope where that type identifier is
>>         no longer visible, you call the function.
>>
>>         My example is a complete match to that scenario as far as
>>         identifier visibility is concerned (you use a type in a scope
>>         where it is visible to declare a function return type, and
>>         then call the function in a scope where it is not visible).
>>         In your example, the type is not visible in the place where
>>         the function is declared but only where it is defined
>>         .
>>
>>
>>     This is logically WRONG. Because to the machine, any function
>>     return value can be seen as an array of bytes, for example, a
>>     pointer is array[0..3] of Byte on a 32-bit machine.  The purpose
>>     of type system is to explain what these bytes stands for. So, if
>>     a type is out-of-scope, how do you interpret the data?
>>
>>     The current "delphi compatible" implementation IS using the type
>>     information to compile the program, i.e. although it is not
>>     visible, it is indeed used by the compile, which, in my opinion,
>>     violates visibility rules.
>>
>>     Standing on your view point, if a type is no longer visible, but
>>     a variable (function return value) of that type is in current
>>     scope, and understood by the program, this means, this value
>>     itself carries type information!  Is is kind of meta data
>>     available in Pascal? If so, I think RTTI should work for ANY kind
>>     of primitive data types.
>>
>     For unit interfaces there is indeed the point that if unit A uses
>     unit B then the program which uses unit A will be able to access
>     types used by unit A. E.g.:
>
>     === unit A ===
>
>     unit A;
>
>     interface
>
>     type
>       TTest = class
>         procedure Test;
>       end;
>
>     implementation
>
>     procedure TTest.Test;
>     begin
>       Writeln('Foobar');
>     end;
>
>     end.
>
>     === unit A ===
>
>     === unit B ===
>
>     unit B;
>
>     interface
>
>     uses
>       A;
>
>     function SomeTest: TTest;
>
>     implementation
>
>     function SomeTest: TTest;
>     begin
>       Result := TTest.Create;
>     end;
>
>     end.
>
>     === unit B ===
>
>     === program ===
>
>     program test;
>
>     uses
>       B;
>
>     begin
>       // there won't be an error here
>       SomeTest.Test;
>     end.
>
>     === program ===
>
>     It's this way at least since Turbo Pascal (though without classes
>     then ;) ).
>
>
> Yes, I agree this is the TP/Delphi way, and as such should be kept at 
> least in DELPHI mode. But is this really good? Doesn't this contradict 
> the Pascal philosophy? Borland did a few questionable things (look at 
> how you used the semicolons in you examples above ;-) ), and it took 
> some decisions when implementing units. But how is this handled in Modula?
Undoing this even for only non-TP/Delphi modes would mean adjusting very 
much code out there. So no, this is how Object Pascal works.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20131031/e20f24a8/attachment.html>