[fpc-pascal] private type and type compatibility

[Sven Barth]

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.

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