[fpc-pascal] private type and type compatibility

[Frederic Da Vitoria]

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

>  Am 31.10.2013 14:42, schrieb 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.:
>>>
>>       ...
>
>        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 :-)
>
>   It's not about being mixed with the compiler code it's about too many
> legacy code relying on this behavior, because it's a given since TP times.
>

...and this modification would only become relevant for new code, so quite
probably not worth the compiler extra code. Yes, I can understand this too.
But my question was not about changing the behavior of fpc (not any more).
This was a theoretical question. In other words, if you had been in a
position to create TP back in nineteen something, and if one of your main
concerns had been about respecting the Pascal philosophy, how would you
have handled this? The way it has been done? Or do you agree this was not
quite orthodox (although efficient)?

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