2013/10/31 Sven Barth <pascaldra...@googlemail.com>
> Am 31.10.2013 02:45, schrieb Xiangrong Fang:
>
> 2013/10/30 Jonas Maebe <jonas.ma...@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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
