[fpc-pascal] private type and type compatibility

[Frederic Da Vitoria]

2013/10/31 Sven Barth <pascaldragon at googlemail.com>

>  Am 31.10.2013 02:45, schrieb Xiangrong Fang:
>
>  2013/10/30 Jonas Maebe <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?

-- 
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20131031/b1309375/attachment.html>