[fpc-pascal] private type and type compatibility

[Frederic Da Vitoria]

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

>  Am 31.10.2013 12:38, schrieb 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?
>
> 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.
>

Ah, you mean that this is too much intricately mixed with the compiler code
and it would be much too much work to change? OK, this I understand :-)

-- 
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/d0b16ea2/attachment.html>