[fpc-pascal] Property with no default value

[Michael Van Canneyt]

On Mon, 18 Apr 2005, Michalis Kamburelis wrote:

> Hi
>
> While converting some Delphi project to Lazarus I noticed that in FPC RTTI 
> there is no way to mark a property as having *no* default value. This 
> particular Delphi project depends on it (it relies on the fact that when 
> saving some object to the stream, some of the properties will *always* be 
> saved in the stream (this way it knows that "Set" methods of these properties 
> will *always* be called when this object will be read from the stream)).
>
> Looking at FPC typinfo unit, and implementation of TWriter class, and 
> reaction on 'nodefault' directive in compiler/pdecvar.pas, there is no 
> equivalent possibility in FPC. Every property has "implicit" default of false 
> / 0 / [] / #0 etc. This means that I can never guarantee that when TWriter 
> writes an object with e.g. some boolean property, it will *always* write that 
> boolean property value, regardless of it's value (whether it's true or 
> false).
>
> The question is: did FPC decided to not implement this ?

No, just there wasn't time yet.

> Or is it just not 
> done yet ? In case it's planned to do this in FPC in a Delphi-compatible way, 
> below is 1-paragraph description how it's done in Delphi (I don't describe 
> here Delphi's implementation, only visible interface, so I guess that FPC 
> devels may read this without any legal concerns :)
>
> Delphi uses special value for TPropInfo.Default field: $80000000. It's used 
> only when TPropInfo.Kind is one of tkInteger, tkChar, tkEnumeration, tkSet 
> (in case of FPC this should also include tkBool). Then when TPropInfo.Default 
> of this property is $80000000, the TWriter will always write this property 
> value to the stream. The funny consequence is that an integer property with a 
> "default $80000000" will always be saved to a stream, even if it doesn't have 
> to be. So this is not very elegant solution from Borland (some field in 
> TPropInfo like IsDefault would be better), but it's probably too late to 
> change such things now, even for Borland, not to mention FPC if it tries to 
> keep typinfo unit absolutely compatible.

I think we'll change the propinfo, because that is the proper solution.
The Borland way is very messy indeed.

But this will be after 2.0, unless you can send a patch.

Michael.