Simply question. Why?

In Delphi i don´t need this, and on ObjPascal i don´t see why this is necessary...

This warning happens even when i use the Delphi compatibility mode!

Léo Willian Kölln

Simply question. Why?

What did you do, try and lower the visibility of the constructor? If so, that is also not allowed in Delphi as far as I know.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

No.
See my singleton example:

TLoggerGeral = class
  private
  {$IFDEF WINDOWS}
    class var FInstance : TLoggerGeral;
  {$ELSE}
    {$STATIC on}
    FInstance : TLoggerGeral; static;
  {$ENDIF}
    constructor Create;
  protected
    pCritSection    : TCriticalSection;
    pLogarDatas     : boolean;
    pLogarTipos     : boolean;
    pArquivoDestino : TextFile;
    saidaConsole    : boolean;
    class function getData: String;
    class function tipoText(tipo: ETipoMensagem): String;
    class procedure executaOperacaoPrioridade(tipo: ETipoMensagem);
  public
    destructor Destroy; override;
    class function GetInstance: TLoggerGeral;
    class procedure recebeMensagem(const mensagem: String; tipo:
ETipoMensagem = NORMAL);
end;

A normal singleton and it complain!

Léo Willian Kölln

Actually, your constructor has the same signature as 'TObject.Create', so it should show a 'lower visibility' warning in Delphi, doesn't it? But, indeed, FPC shows the warning (should be public) for all constructors, even if you're not hiding from the parent class, and I always found this a (minor) annoyance.
But the fact that the semantic of constructors in Delphi/ObjectPascal have the same visibility rules of "common methods" (i.e. they force the visibility of the constructor from the parent class) is just sad. "Even" Java constructors' syntax is better ;-)
Not to mention that you can call constructors on instance "pointer" (ok, I know this "hack is useful/used in streaming/persistence code), even uninitialized ones...

-Flávio

Léo Willian Kölln wrote

No. See my singleton example:

How did I guess it was going to be about implementing a Singleton. This issue has been raised a thousand times in FPC and Delphi circles. :)

TLoggerGeral = class

Which means you are descending from TObject.

Which means you are trying to lower the constructor TObject.Create from public to private.

A normal singleton and it complain!

I have a much easier "lazy man's" singleton for you... It's not 100%, but then, I have *never* seen a singleton implementation in Delphi or FPC that is 100%. Simply access the singleton via the gMySingleton method.

eg:
   gMySingleton.DoSomethingCool;
========================
interface
   TMySingleton = class(TObject)
   ...
   end;
function gMySingleton: TMySingleton
implementation
var
  uMySingleton: TMySingleton;
function gMySingleton: TMySingleton;
begin
  if not Assigned(uMySingleton) then
    uMySingleton := TMySingleton.Create;
  result := uMySingleton;
end;

[...snip the rest of TMySingleton implementation...]

initialization
  uMySingleton := nil;
finalization
  uMySingleton.Free;
end.
========================

The reason you can't lower the visibility of the constructor or any method for that matter... A class interface (implementation section) , even for TObject as in your example, is a contract of how you can use that class and what is available to you. By lowering the visibility of a method or constructor in a descendant class, you are breaking the contract previously defined. This is a BIG no-no, hence the reason it is not allowed.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

2009/4/6 Flávio Etrusco :

Actually, your constructor has the same signature as 'TObject.Create', so it should show a 'lower visibility' warning in Delphi, doesn't it?

Correct, Delphi should also give this warning.

But, indeed, FPC shows the warning (should be public) for all constructors, even if you're not hiding from the parent class, and I always found this a (minor) annoyance.

See my previous reply. Lowering visibility in descendant classes are breaking a contract (class interface) that was previously declared.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

If it was a visibility "escalation" problem i agree, but Delphi Did Noy complain about this one (and yes, Delphi complains if this happens for other visibility problems).
And, i don't put an override to the constructor, so in my class the constructor is really a virtual override of the TObject.Create?

And, as Flavio Etrusco said:

But, indeed, FPC shows the warning (should be public) for all constructors, even if you're not hiding from the parent class, and I always found this a (minor) annoyance.

And it's true, it always complain!

The problem in this case is not a break of contract (class interface), in my opinion is a problem of compiler interpretation, it Always require constructors to be Public, we just need read the warning message again: "Warning: Constructor should be public"

Otherwise (break of contract), it would be an error right?

Léo Willian Kölln

Just to clarify the bloated code, i'm using the same code to compile on Delphi (Windows) and FPC (*nix).

I have a much easier "lazy man's" singleton for you... It's not 100%, but then, I have *never* seen a singleton implementation in Delphi or FPC that is 100%. Simply access the singleton via the gMySingleton method.

I liked it, but i cant use it, is too lazy and i'm a very very strict old boring man! :P

Léo Willian Kölln

Graeme Geldenhuys wrote

And, i don't put an override to the constructor, so in my class the constructor is really a virtual override of the TObject.Create?

No, it's not and IMO this warning is indeed a questionable one. There are valid ("non-hack") use-cases for protected or even private constructors.

Vinzent.

So, what can we do?

Fill a bug report? There is one here about this:
http://bugs.freepascal.org/view.php?id=11526

Closed. I see the status "resolved => closed " as wrong! It´s not resolved even if it is known and proposed!

I can´t make a path now, no time... Someone here can? I don´t see this as complicated. Just get rid of it!

Léo Willian Kölln