The program below compiles. But if I try to use code completion here writeln(s.F...
Occurs this error:
test.lpr(8,31) Error: ancestor has same name as class.

program test;
{$mode objfpc}{$H+}
uses SysUtils, Classes;
type
  TStringList = class(Classes.TStringList)
  public
    function Foo: string;
  end;
function TStringList.Foo: string;
begin
  result := 'Foo';
end;
var
  s: TStringList;
begin
  s := TStringList.Create;
  writeln(s.Foo);
  s.Free;
  readln;
end.

Marcos Douglas

Like that:
type
  TMyStringList = Classes.TStringList;
  TStringList = class(TMyStringList)
  public
    function Foo: string;
  end;

...works fine.

Marcos Douglas

The codetools have no circle detection when searching recursively. As a simple protection versus endless loops they do not support naming classes the same as their ancestort. And I agree with Juha, it is bad coding practice.

Mattias

Marcos Douglas kirjoitti sunnuntai 06 maaliskuu 2011 03:57:02:

In any case your class name is very confusing. I would always use a different name. When someone else reads your code and sees TStringList he assumes it is a "normal" TStringList.

Juha

It was just an example.
But there is an advantage, see below.

Mattias Gaertner wrote

The codetools have no circle detection when searching recursively. As a simple protection versus endless loops they do not support naming classes the same as their ancestort. And I agree with Juha, it is bad coding practice.

If you have a program with a lot of TEdit and you have to modify some feature (eg: when the Edit give the focus, your color will change) you can codify this new feature in your own unit (eg mystrctrls.pas) and you can put the new unit on uses clause (at the end or after on "real" unit of TEdit) and voial?! You have a "new" TEdit in runtime.

Nobody did that??

Marcos Douglas

Maybe for the programmer of the unit, but for the users, it's almost always a disadvantage. They will get unexpected behavior instead (especially if you put it along with other things in the unit where one might need some of them). Open LCL sources and see how its components are named. For your "advantage" case, I would give something like TColorEdit. Your proposal has an advantage of changing a component behavior just by changing the uses clause, that's also possible with the current situation. Example:

uses
  StdCtrls,ColorEdit;
type
  TEditCtrl = TEdit;

... // use TEditCtrl everywhere

when you want to change to TColorEdit, just change TEditCtrl definition to TColorEdit. Same type-savings as your proposal.

leledumbo wrote

Maybe for the programmer of the unit, but for the users, it's almost always a disadvantage. They will get unexpected behavior instead (especially if you put it along with other things in the unit where one might need some of them).

This "hack" is used in a company when I worked before. So, all programmer did know about it. Nobody got unexpected behavior.

Open LCL sources and see how its components are named.

There are no pattern in LCL sources. Some components have a prefix, some not...

You din't TEdit class is already used in all sources. This hack provides a big change with a few lines code. This hack is used in programs that already exists. To new programs we use a new widget, of course (or not =).

Marcos Douglas