2013/10/31 Sven Barth <pascaldra...@googlemail.com>
> Am 31.10.2013 12:38, schrieb Frederic Da Vitoria:
>
> 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?
>
> 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
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
