The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,423 other followers

Delphi inner scoping is undefined. Please Embarcadero/Idera, come up with a formal language definition for Delphi

Posted by jpluimers on 2018/01/04

[WayBack] Hi there, this is pure curiosity only; but this compiler behaviour seems odd to me. What do you think?… – Agustin Ortu – Google+

The problems start when you prefix the outer class which you have to when using inner consts ([WayBack] Oh nice. Feel free to QP. Fails at least in Delphi XE8. … – Jeroen Wiert Pluimers – Google+).

The big problem in both cases is a formal language specification. The lack of a formal language specification makes it very hard to predict the effect of use cases or generate them for testing.

So this post is yet another request: Please Embarcadero/Idera, come up with a formal language definition for Delphi.

unit ParentUnit;

interface

type
  TParent = class
  // section can be strict protected, protected, public, published or nothing
  const
    InitialBooleanValue = False;
    InitialIntegerValue = -1;
  end;

implementation

end.

The below the ChildUnit doesn’t compile at all:

unit ChildUnit;

interface

uses
  ParentUnit;

type
  TChild = class(TParent)
  // section can be strict protected, protected, public, published or nothing
  const
    // Initial and final values need to be different to test the behaviour
    FinalBooleanValue = not InitialBooleanValue;
    FinalIntegerValue = InitialIntegerValue + 1;
    //[dcc32 Error] ChildUnit.pas(13): E2003 Undeclared identifier: 'InitialBooleanValue'
    //[dcc32 Error] ChildUnit.pas(14): E2003 Undeclared identifier: 'InitialIntegerValue'
    //[dcc32 Error] ChildUnit.pas(14): E2026 Constant expression expected
end;

implementation

end.

This does compile but requires the parent class specified explicitly:

unit ChildUnit;

interface

uses
  ParentUnit;

type
  TChild = class(TParent)
  // section can be strict protected, protected, public, published or nothing
  const
    // Initial and final values need to be different to test the behaviour
    FinalBooleanValue = not TParent.InitialBooleanValue;
    FinalIntegerValue = TParent.InitialIntegerValue + 1;
end;

implementation

end.

Back to the usage of interfaces:

Code example [WayBackProgram2.pas · GitHub:

 

–jeroen

2 Responses to “Delphi inner scoping is undefined. Please Embarcadero/Idera, come up with a formal language definition for Delphi”

  1. Joseph Mitzen said

    “The big problem in both cases is a formal language specification. The lack of a formal language specification makes it very hard to predict the effect of use cases or generate them for testing.

    So this post is yet another request: Please Embarcadero/Idera, come up with a formal language definition for Delphi.”

    Marco Cantu has said in the past that they’ve considered, and rejected, the idea. I’m guessing the only rationale that makes sense is that they don’t want to make it easier for anyone else to make a compatible compiler. Barry Kelly once said that the ultimate canon on what was or was not valid Delphi was whether the Delphi compiler compiled it or not, and he was often surprised what would compile. Even this was thrown out once Marco was in charge when a bug fix rendered previously compilable code non-compilable. Marco stuck by the change and it insisted “It never should have compiled in the first place”. Now I guess there’s absolutely no reliable measure for what is or is not valid Delphi. Even if it compiles, it might not be valid code. It’s somewhat of a strange position to be in when the product is aimed squarely at the enterprise today.

  2. rvelthuis said

    Inner scoping is fine. A class can always access its own strict private members.

    What doesn’t “work” (or perhaps shouldn’t even “work”) is unqualified access to a parent class’ inner constants. In other words, these are obviously not inherited.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

 
%d bloggers like this: