[fpc-pascal] Records as properties and Delphi compiler error

[Jonas Maebe]

On 07 Jun 2009, at 10:35, fpclist at silvermono.co.za wrote:

> A high level, a class is like a record that has been modified to  
> include
> functions and procedures. I know that I'm over simplifying thing  
> here, please
> bare with me.

The difference you skip over is the fundamental reason why one works  
and the other doesn't: a class is a pointer, while a record is a value.

> I'm trying to understand the logic employed by the creators of  
> Delphi where
> they don't allow to write to the fields of a record type property,  
> but if the
> property points to a class type, then anything goes.

In case of a class, the property returns a pointer (namely the pointer  
to the class instance data), and then you (implicitly) dereference the  
pointer and write data where it points to. In case of a record, the  
property returns a record's value, and then (semantically) you change  
the value of this returned record (not the value of the element of the  
record that the property referred to).

This worked in previous FPC versions because rather than treating the  
result of the property like a function result (which it has to,  
because that's the semantical meaning of a property, so you can  
transparently change them into getters/setters without breaking any  
code), it treated it like a direct field access in case no getter/ 
setter existed. So rather than returning a record's value, the  
property returned "a reference to a record".

> In the example bellow,
> where a property is of a class type, both Delphi and FPC compile the  
> code,
> but there is no guarantee that the object referenced to by the  
> property has
> been instantiated before the property is used (The programmer must
> instantiate the TTestProp class within TTestClass prior to any call  
> made to xx
> the property). IMO, it would be a nice feature if the compiler could  
> be
> modified to issue a warning in such a case.Again, I'm over  
> simplifying, to
> the compiler, it would be similar to checking for a variable  
> declaration
> before the variable is used.

Except that it's about dynamically allocated memory and depends on  
interprocedural control flow graph analysis, which makes it immensely  
more complex.

> I thing that the "error" in the way that FPC allows record  
> properties to
> access the record fields could be handy if retained. Perhaps this  
> feature
> could be reserved for objfpc mode. What are your thoughts on the  
> matter?

Things will remain the way they are for the reasons explained above.


Jonas