[fpc-pascal] private type and type compatibility

[Sven Barth]

Am 31.10.2013 15:41, schrieb Frederic Da Vitoria:
> 2013/10/31 Sven Barth <pascaldragon at googlemail.com 
> <mailto:pascaldragon at googlemail.com>>
>
>     Am 31.10.2013 14:42, schrieb Frederic Da Vitoria:
>>     2013/10/31 Sven Barth <pascaldragon at googlemail.com
>>     <mailto:pascaldragon at googlemail.com>>
>>
>>         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.:
>>>
>     ...
>
>>>             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)?
I honestly don't know what I would have done...

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