0

I have a few classes (of TObject) in Delphi XE7 (Firemonkey) which have a property AsJson:

uses
  System.Classes, System.SysUtils, XSuperObject;

type
  TMyObject = class(TObject)
  public
    property AsJson: ISuperObject read GetAsJson;
  end;

However, the compiler is giving me warnings for these:

[dcc32 Warning] MyUnit.pas(383): W1009 Redeclaration of 'AsJson' hides a member in the base class

I'm looking in the base class of TObject and see no such thing, nor is it a valid field if I were to try to use it. I see nothing in the documentation about such a property. This only appears to happen if the property type is ISuperObject which is the latest version of XSuperObject (from SVN a few weeks ago at least). I also tried using type Integer and I get it too.

What does this warning mean in my scenario and how do I get rid of it?

EDIT

It appears to only happen when I have XSuperObject in the uses clause...

program Project1;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils,
  XSuperObject in 'C:\...\XSuperObject.pas',
  XSuperJSON in 'C:\...\XSuperJSON.pas';

type
  TMyObject = class(TObject)
  private
    FTest: Integer;
  public
    property AsJson: Integer read FTest;
  end;

begin

end.

Above example produces:

[dcc32 Warning] Project1.dpr(17): W1009 Redeclaration of 'AsJson' hides a member in the base class

If I simply remove XSuperObject, I don't get this warning. My copy of XSuperObject is a few weeks old.

Jerry Dodge
  • 26,858
  • 31
  • 155
  • 327
  • If you get that warning for code as simple as what you show here (I don't) then that looks to me like a compiler bug (as in, some internal compiler table got corrupted). Do you also get this warning in an otherwise blank project? – 500 - Internal Server Error Dec 28 '14 at 18:26
  • The code in the question cannot give that error, assuming `TObject` is what we would expect it to be. Show a complete program. – David Heffernan Dec 28 '14 at 18:29
  • Your edit is odd. You said you derived from `TObject`. Did you? – David Heffernan Dec 28 '14 at 18:38
  • @DavidHeffernan Yes, but it happens from any base class. I just did that to keep it minimal. – Jerry Dodge Dec 28 '14 at 18:39
  • 1
    Why are there people still voting to close as "can no longer reproduce" when it's clear it can be? Accepted answer with the reason and everything... – Jerry Dodge Dec 28 '14 at 18:55

2 Answers2

7

Is it possible that XSuperObject declares a class helper for TObject this introduces an AsJSON property? That could explain the error.

Update: Sertac confirms in a comment that this is indeed the case.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
1

Following code also triggers such warning. I suspect that you have TObject class redeclared somewhere.

program Project1;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils;

type
  ISuperObject = interface
  end;

  TObject = class
  public
    function AsJSON: string; virtual;
  end;

  TMyObject = class(TObject)
  public
    function GetAsJson: ISuperObject;
    property AsJson: ISuperObject read GetAsJson;
  end;

function TObject.AsJSON: string;
begin

end;

function TMyObject.GetAsJson: ISuperObject;
begin

end;

begin
end.
Dalija Prasnikar
  • 27,212
  • 44
  • 82
  • 159
  • Please see my edit. It appears to be `XSuperObject` doing something. – Jerry Dodge Dec 28 '14 at 18:37
  • Your answer can't be valid because you're making your own `ISuperObject` instead of using the actual `XSuperObject` library. Also, an answer cannot be based on suspicion. Answers on Stack Overflow need to be based on facts. Suspicion is very close to Opinion. – Jerry Dodge Dec 28 '14 at 19:00
  • 2
    @Jerry The answer you accepted was based on suspicion. I just happened to have a lucky guess. – David Heffernan Dec 28 '14 at 19:08
  • @David I didn't see that as suspicion, I thought you knew for a fact that XSuperObject had such a thing :-) – Jerry Dodge Dec 28 '14 at 19:11
  • In your original question, you had three and half lines of code and all I could do is make educated guess about what might be going on. Granted my guess was wrong, and @David made much better one. – Dalija Prasnikar Dec 29 '14 at 09:33