Hello, FPC developers' list

I have compared what d2010 TObject has and found a few differences:

1. Dispatch method is virtual
2. new method: class function UnitName: string;
3. new method: function Equals(Obj: TObject): Boolean; virtual;
4. new method: function GetHashCode: Integer; virtual;
5. new method: function ToString: string; virtual;

Documentation:
http://docwiki.embarcadero.com/VCL/en/System.TObject.Dispatch http://docwiki.embarcadero.com/VCL/en/System.TObject.UnitName http://docwiki.embarcadero.com/VCL/en/System.TObject.Equals http://docwiki.embarcadero.com/VCL/en/System.TObject.GetHashCode http://docwiki.embarcadero.com/VCL/en/System.TObject.ToString

Which of that changes are welcome for FPC?

Best regards,
Paul Ishenin.

Since we opened the d2010 can of worms anyways, I think all would be accepted.

I was going to say the same :-)

Although I think that TObject.ToString will give a lot of problems for things like tiOPF...

On the other hand, UnitName may come in handy for the Lazarus IDE.

Michael.

Michael Van Canneyt wrote

I was going to say the same :-) Although I think that TObject.ToString will give a lot of problems for things like tiOPF...

actually it adds problems even to the fpc rtl :) since it has toString member in the component stream parser.

Best regards,
Paul Ishenin.

Yes, but..
Canned food can contain preservatives that are not always healthy. The ToString Javaism is poorly implemented in Delphi. I suggest that objfpc mode should be based on json or similar standards, which are already available. Not just rtti writeouts.

Thaddy wrote

The ToString Javaism is poorly implemented in Delphi. I suggest that objfpc mode should be based on json or similar standards, which are already available. Not just rtti writeouts.

TObject can't be one for ObjFpc mode and one for delphi mode.

Best regards,
Paul Ishenin.

Zitat von Michael Van Canneyt :

Lazarus already reads the unitname from the RTTI (see propedits.pp) and I guess MSEgui uses that too.
There are no classes yet without RTTI in lazarus where the unit name is needed.

Maybe it can be useful for debugging?

Mattias

(...)

The ToString Javaism is poorly implemented in Delphi. I suggest that objfpc mode should be based on json or similar standards, which are already available. Not just rtti writeouts.

It's poorly implemented on Java too, nonetheless...

-Flávio

2009/10/27 Michael Van Canneyt :

I was going to say the same. ;-) I just clicked on the link Paul posted to see what ToString does and compare it to tiOPF.

2009/10/27 Thaddy :

The ToString Javaism is poorly implemented in Delphi. I suggest that objfpc mode should be based on json or similar standards, which are already available. Not just rtti writeouts.

Based on the documentation available at Embarcadero, TObject.ToString is very simple - it just returns the ClassName by default.

------------------------------------
For example, calling System.TObject.ToString on a TButton instance returns a string containing "TButton".
-------------------------------------

Obviously the developer can override it and return more details, but by default it's the same as 'ClassName' property

Michael Van Canneyt wrote

On the other hand, UnitName may come in handy for the Lazarus IDE.

And this is the most difficult thing amoung other new methods :)

I am trying to get UnitName from the RTTI but have some problems:

1. If I call PTypeInfo(TypeInfo(TObject))^.Kind then I get tkClass and UnitInfo can be retrieved since tkClass has this member.

2. If I am using PTypeInfo(TypeInfo(Self))^.Kind inside a class method I get tkUnknown and UnitName is not avaiable ofcource.

3. If I am using ClassInfo iside a class method then it returns nil if the class has no RTTI.

Few questions now:
a) Why TypeInfo(TObject) TObject.ClassInfo?
b) Why TypeInfo(TPersistent) = TPersistent.ClassInfo? c) How to get TypeInfo of the class inside that class class method?

After all, if it should not use RTTI then I need to change the compiler to store also UnitName near the ClassName field but this is a be bad change since vmtMethodStart will change it offset and according to RTL comments few methods depends on that offsetts.

So what is the best way to implement this UnitName method?

Best regards,
Paul Ishenin.

This last is correct, since the ClassInfo is part of the RTTI ?

Few questions now: a) Why TypeInfo(TObject) TObject.ClassInfo? b) Why TypeInfo(TPersistent) = TPersistent.ClassInfo?

Because TPersistent is compiled in $M+ ?

c) How to get TypeInfo of the class inside that class class method?

I think that Florian should answer this, but it seems like a bug to me ?

Michael.

Yes, that's why I gived that TPersistent example here. I can't figure our how TypeInfo(TObject) works if TObject has no RTTI and since it works then why TObject.ClassInfo = nil.

Best regards,
Paul Ishenin.

Paul Ishenin пишет:

2. If I am using PTypeInfo(TypeInfo(Self))^.Kind inside a class method I get tkUnknown and UnitName is not avaiable ofcource.

Self = TClass, not TObject inside a class method. Obviously, there is no RTTI or whatever for TClass.

Sergei

No idea why but it is the same in delphi < d2010. Probably in d2010 it depends on project rtti settings. And UnitName = '' in d2009 for classes with no RTTI.

c) How to get TypeInfo of the class inside that class class method?

Probably no way except the using the same info which ClassType using.

So what is the best way to implement this UnitName method?

Still the question. Using RTTI and return empty result if it does not exists or changing the compiler to write unit name near the class name?

Best regards,
Paul Ishenin.

The implementation is probably the same: consult RTTI if present. If it is not present, then return empty...

Maybe generate partial RTTI for classes not in $M+ ?

Michaek

Michael Van Canneyt wrote

Maybe generate partial RTTI for classes not in $M+ ?

I think it is already generated since TypeInfo(TObject) returns data but probably not written by the compiler to the vmtTypeInfo offset.

Best regards,
Paul Ishenin.

TObject should NEVER -xcuse me for shouting - contain rtti information

Thaddy wrote

TObject should NEVER -xcuse me for shouting - contain rtti information

And we don't propose to do so :)

Michael.

Paul Ishenin wrote

Michael Van Canneyt wrote: > Maybe generate partial RTTI for classes not in $M+ ? I think it is already generated since TypeInfo(TObject) returns data but probably not written by the compiler to the vmtTypeInfo offset.

Indeed so. Look at attached patch.

Best regards,
Paul Ishenin.

Florian Klaempfl wrote

Since we opened the d2010 can of worms anyways, I think all would be accepted.

Thanks for accepting Dispatch changes.

Here are the next:
http://bugs.freepascal.org/view.php?id=14931
http://bugs.freepascal.org/view.php?id=14930

Best regards,
Paul Ishenin.