On Sunday 07 June 2009 22:19:47 Jonas Maebe wrote: > On 07 Jun 2009, at 10:35, fpcl...@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 understand the difference, but a pointer to a record still suffers the from the same problem as a pointer to a class i.e. if memory is not allocated then the code fails at runtime. It's interesting to note though, that Delphi allows the assignment to the fields of a record type property via the with - do construct. Is this also the case with FPC 2.3.1? > > > 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 > _______________________________________________ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
