[fpc-pascal] Property with no default value
Michael Van Canneyt
michael.vancanneyt at wisa.be
Mon Apr 18 09:27:01 CEST 2005
On Mon, 18 Apr 2005, Michalis Kamburelis wrote:
> 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
> 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.
More information about the fpc-pascal