+ From: ]On Behalf
Of Michael Van Canneyt

+ On Thu, 4 Nov 1999, Chris Storah wrote:
+
+ > I am having problems when compiling a derived class (WinNT version).
+ > This is the code:
+ >
+ > TVer1 = class(TObject)
+ > protected
+ > rec: TObject;
+ > end;
+ >
+ > TVer2 = class(TVer1)
+ > protected
+ > rec: TObject; <=== duplicate identifier
+ > end;
+ >
+ >
+ > The error using ppc386 is 'Error: Duplicate identifier REC'. +
+ This IS an error; if you declare such a thing in the protected
+ part, you should rename it. How is the compiler supposed to
+ know in a descendent class which one to take ? Any decision will
+ be necessarily an arbitrary one.
+
+ > Is this a known bug?
+ > If so, anyone know how to fix it without changing the identifier names
+ > (Delphi works with the above code).
+
+ Delphi has other strange quircks; Can you tell me WHICH rec it takes
+ when you refer to it ?

Yes. Its the same as with non virtual methods with the same name.

Example:

var
  v1: TVar1;
  v2: TVar2;
begin
  v1 := TVer1.Create;
  {v1.rec refers to TVer1.rec}
  v2 := TVer2.Create;
  {v2.rec refers to TVer2.rec}

  v1 := TVer2.Create;
  {v1.rec refers to TVer1.rec, since rec is not virtual (mostly for vars

;-)}
{this same rule applies if rec was a method }

  v2 := TVer2.Create;
  {TVer1(v2).rec refers to TVer1.rec, same rule as above}
  v1 := TVer2.Create;
  {TVer2(v1).rec refers to TVer2.rec}
end;

This is/was somewhere documented, don't know where

Marc

Sorry, Value isn't a problem - I suddenly lost the ability to read code :-)

Why does the compiler error with the parameters of the constructors? If this is the case, code porting will be a nightmare since a lot of code will use 'Create' with the same parameter list as the base class?

Chris

Can you tell me WHICH rec it takes when you refer to it ?

Delphi takes the rec of the TVer2 class.

How is the compiler supposed to know in a descendent class which one to

take ?
Delphi takes the descendent class 'rec', as it does with the virtual members.
Surely if the descendent class overrides a member of it's base class, that is the one to be used?

if you declare such a thing in the protected part, you should rename it.

The problem is not limited to the protected members (change it to 'public' and the same thing happens).

..simply bad programming to do this

I agree that it's not the best approach, but what if you need some code that does the same processing on file records and you change the record structure at a later date. If you have to change 'rec' to something else, then the processing code will need to change from being generic to version specific (i.e. processing 'recVer1,2,3...N' instead of rec).

Delphi has other strange quircks;

Does this work on other versions of Pascal?
I have only tried it on Delphi and ppc386 so I can't verify that it is a quirk or not.

Chris

Where is it re-used ? I don't see it ? Once in TStrField and once in TNumfield which don't depend on each other.

BTW. I see you used TDataset stuff as examples; If you're writing TDataset stuff: There is a TDataset with TField implementation available for Free Pascal in the FCL. It provides Read-only access; there are 2 descendants: one for a dataset in a flat file, one for accessing a MySQL database. I have the plans for scalable TDatasets ready
(I mean TTable and TQuery that work on any database)

Just so you don't implement things that already exist :-)

Michael.

Not if it is protected; Private: yes, but not protected nor public, nor published.

>if you declare such a thing in the protected part, you should rename it. The problem is not limited to the protected members (change it to 'public' and the same thing happens).

Change the rec with a class and then it's solved :-)

>Delphi has other strange quircks; Does this work on other versions of Pascal? I have only tried it on Delphi and ppc386 so I can't verify that it is a quirk or not.

Maybe a quirck is a bad name; I meant more that Delphi allows some things which go against good pascal programming.

Michael.

+ From: Chris Storah

+ Just found a piece of code that may or may not clarify things:
+ (TField sample in the Delphi help)...
+
+ Problem is not limited to variables - constructors have the
+ same problem if
+ the parameters names conflict.
+
+ The compiler gets conflicts for FNAME, X anf Y, but not Value
+ - why has
+ Value got through, as it's name is re-used?

Value is private. Private parts are (supposed to be) invisible to descendants. So you may use the name again since it is not known.

Marc

+
+ Cheers,
+ Chris.
+
+ {================================}
+ TField = class
+ private
+ X, Y, Len: Integer;
+ FName: String;
+ public
+ constructor Copy(F: TField);
+ constructor Create(FX, FY, FLen: Integer; FName: String);
+ destructor destroy; override;
+ procedure Display; virtual;
+ procedure Edit; dynamic;
+ protected
+ function GetStr: String; virtual;
+ function PutStr(S: String): Boolean; virtual;
+ private
+ procedure DisplayStr(X, Y: Integer; S: String);
+ public
+ property Name: String read GetStr write Buffer;
+ end;
+
+
+ TStrField = class(TField)
+ private
+ Value: PString;
+ public
+ constructor Create(FX, FY, FLen: Integer; FName: String);
+ destructor Destroy; override;
+ protected
+ function GetStr: String; override;
+ function PutStr(S: String): Boolean; override;
+ end;
+
+ TNumField = class(TField)
+ private
+ Value, Min, Max: Longint;
+ public
+ constructor Create(FX, FY, FLen: Integer; FName: String;
+ FMin, FMax: Longint);
+ function GetStr: String; override;
+
+ function PutStr(S: String): Boolean; override;
+ function Get: Longint;
+ procedure Put(N: Longint);
+ end;
+
+ {===================================================} +
+
+ -----Original Message-----
+ From: Michael Van Canneyt
+ Sent: 04 November 1999 09:32
+ To: Lazarus (E-mail)
+ Subject: Re: [lazarus] Possible compiler bug with derived classes? +
+
+
+
+ On Thu, 4 Nov 1999, Chris Storah wrote:
+
+ > I am having problems when compiling a derived class (WinNT version).
+ > This is the code:
+ >
+ > TVer1 = class(TObject)
+ > protected
+ > rec: TObject;
+ > end;
+ >
+ > TVer2 = class(TVer1)
+ > protected
+ > rec: TObject; <=== duplicate identifier
+ > end;
+ >
+ >
+ > The error using ppc386 is 'Error: Duplicate identifier REC'. +
+ This IS an error; if you declare such a thing in the protected
+ part, you should rename it. How is the compiler supposed to
+ know in a descendent class which one to take ? Any decision will
+ be necessarily an arbitrary one.
+
+ > Is this a known bug?
+ > If so, anyone know how to fix it without changing the
+ identifier names
+ > (Delphi works with the above code).
+
+ Delphi has other strange quircks; Can you tell me WHICH rec it takes
+ when you refer to it ?
+
+ I agree that for the sake of compatibility, we should accept
+ this, but it is
+ simply bad programming to do this, so this is not a priority. +
+ Michael.
+
+ _________________________________________________________________
+ To unsubscribe: mail with
+ "unsubscribe" as the Subject
+ archives at http://www.miraclec.com/list_archives/lazarus +
+ _________________________________________________________________
+ To unsubscribe: mail with
+ "unsubscribe" as the Subject
+ archives at http://www.miraclec.com/list_archives/lazarus +

I am having problems when compiling a derived class (WinNT version). This is the code:

  TVer1 = class(TObject)
      protected
         rec: TObject;
   end;
  TVer2 = class(TVer1)
      protected
         rec: TObject;	<=== duplicate identifier
      end;

The error using ppc386 is 'Error: Duplicate identifier REC'.

Is this a known bug?
If so, anyone know how to fix it without changing the identifier names (Delphi works with the above code).

Cheers,
Chris

This IS an error; if you declare such a thing in the protected part, you should rename it. How is the compiler supposed to know in a descendent class which one to take ? Any decision will be necessarily an arbitrary one.

Is this a known bug? If so, anyone know how to fix it without changing the identifier names (Delphi works with the above code).

Delphi has other strange quircks; Can you tell me WHICH rec it takes when you refer to it ?

I agree that for the sake of compatibility, we should accept this, but it is simply bad programming to do this, so this is not a priority.

Michael.

Just found a piece of code that may or may not clarify things: (TField sample in the Delphi help)...

Problem is not limited to variables - constructors have the same problem if the parameters names conflict.

The compiler gets conflicts for FNAME, X anf Y, but not Value - why has Value got through, as it's name is re-used?

Cheers,
Chris.

{================================}
TField = class
private
  X, Y, Len: Integer;
  FName: String;
public
  constructor Copy(F: TField);
  constructor Create(FX, FY, FLen: Integer; FName: String);
  destructor destroy; override;
  procedure Display; virtual;
  procedure Edit; dynamic;
protected
  function GetStr: String; virtual;
  function PutStr(S: String): Boolean; virtual;
private
  procedure DisplayStr(X, Y: Integer; S: String);
public
  property Name: String read GetStr write Buffer;
end;
  TStrField = class(TField)
  private
    Value: PString;
  public
    constructor Create(FX, FY, FLen: Integer; FName: String);
    destructor Destroy; override;
  protected
    function GetStr: String; override;
    function PutStr(S: String): Boolean; override;
  end;
  TNumField = class(TField)
  private
    Value, Min, Max: Longint;
  public
    constructor Create(FX, FY, FLen: Integer; FName: String;
      FMin, FMax: Longint);
    function GetStr: String; override;
    function PutStr(S: String): Boolean; override;
    function Get: Longint;
    procedure Put(N: Longint);
  end;

{===================================================}

Yes, like the VCL code they implemented - looks like one of the documentation bugs...
Managed to get round the original problem using properties, but haven't checked it compiling under ppc yet.

Thanks for the help,
Chris

That makes sense...maybe Delphi is being clever and automatically adding in the type-casting '(TVer2)rec' for derived classes? That's good for my code, but I can see it wouldn't follow standards...

Chris

I haven't committed myself to a particular component set yet, but thanks for the warning.
Only just managed to get the compiler re-compiling! I may take a look at TGrid, unless it has been covered by anyone else - since I have written grid classes in the past (C++).

Chris

? Shouldn't you use 'override' or something like that ? Or at least make it virtual ?

Michael.