[Lazarus] Code completion: Error: ancestor has same name as class.

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[Lazarus] Code completion: Error: ancestor has same name as class.

Marcos Douglas
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

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Code completion: Error: ancestor has same name as class.

Marcos Douglas
On Sat, Mar 5, 2011 at 10:57 PM, Marcos Douglas <[hidden email]> wrote:

> 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.

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

...works fine.


Marcos Douglas

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Code completion: Error: ancestor has same name as class.

Juha Manninen
In reply to this post by Marcos Douglas
Marcos Douglas kirjoitti sunnuntai 06 maaliskuu 2011 03:57:02:
> type
>   TStringList = class(Classes.TStringList)
>   public
>     function Foo: string;
>   end;

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

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Code completion: Error: ancestor has same name as class.

Mattias Gaertner
In reply to this post by Marcos Douglas
On Sat, 5 Mar 2011 22:57:02 -0300
Marcos Douglas <[hidden email]> wrote:

> 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)

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

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Code completion: Error: ancestor has same name as class.

Marcos Douglas
On Sun, Mar 6, 2011 at 6:20 AM, Juha Manninen <[hidden email]> wrote:

> Marcos Douglas kirjoitti sunnuntai 06 maaliskuu 2011 03:57:02:
>> type
>>   TStringList = class(Classes.TStringList)
>>   public
>>     function Foo: string;
>>   end;
>
> 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.

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

On Sun, Mar 6, 2011 at 4:47 AM, Mattias Gaertner
<[hidden email]> 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

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Code completion: Error: ancestor has same name as class.

leledumbo
Administrator
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.
Reply | Threaded
Open this post in threaded view
|

Re: [Lazarus] Code completion: Error: ancestor has same name as class.

Marcos Douglas
On Sun, Mar 6, 2011 at 3:20 PM, leledumbo <[hidden email]> 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...

> 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.

You din't understand at all.
The 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

--
_______________________________________________
Lazarus mailing list
[hidden email]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus