Am 31.10.2013 12:38, schrieb Frederic Da Vitoria:
2013/10/31 Sven Barth <pascaldra...@googlemail.com <mailto:pascaldra...@googlemail.com>>

    Am 31.10.2013 02:45, schrieb Xiangrong Fang:
    2013/10/30 Jonas Maebe <jonas.ma...@elis.ugent.be
    <mailto: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.

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Reply via email to