Hi Jonas
Thanks for the reply.
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.
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 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
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.
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?
Regards,
Nino
//--------------------------------------------------------------------------
unit Unit1;
(*
This code sample is written for use with Lazarus.
The Delphi equivalent also compile using Delphi.
*)
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, FileUtil, LResources, Forms, Controls, Graphics, Dialogs,
StdCtrls;
type
TForm1 = class(TForm)
Button1 : TButton;
procedure Button1Click(Sender : TObject);
private
public
end;
TTestProp = class
private
fX : Byte;
fY : Byte;
public
property X : Byte read fX write fX;
property Y : Byte read fY write fY;
end;
TTestClass = class
private
fTestProp : TTestProp;
public
constructor Create();
destructor Destroy(); override;
property TestProp : TTestProp read fTestProp write fTestProp;
end;
var
Form1 : TForm1;
implementation
constructor TTestClass.Create();
begin
//* If this line is commented, the compilation will succeed
//* but a violation will occur at runtime in button click handler
//* since the object referenced does not exist.
//*
//* Note: I'm not suggesting here that the compile should be aware
//* that this object, whilst being referenced later in the code,
//* is not instantiated, but it would be a cool feature if the compiler
//* could be modified to issue at least a warning advising of such an event.
fTestProp := TTestProp.Create();
end;
destructor TTestClass.Destroy();
begin
if Assigned(fTestProp) then
FreeAndNil(fTestProp);
inherited Destroy();
end;
procedure TForm1.Button1Click(Sender : TObject);
var
TestClass : TTestClass;
begin
TestClass := TTestClass.Create();
try
ShowMessage('TestProp before' + #13 +
'X = ' + IntToStr(TestClass.TestProp.X) + #13 +
'Y = ' + IntToStr(TestClass.TestProp.Y));
TestClass.TestProp.X := 10;
TestClass.TestProp.Y := 20 ;
ShowMessage('TestProp after' + #13 +
'X = ' + IntToStr(TestClass.TestProp.X) + #13 +
'Y = ' + IntToStr(TestClass.TestProp.Y));
finally
FreeAndNil(TestClass);
end;
end;
initialization
{$I unit1.lrs}
end.
//*************************************
On Saturday 06 June 2009 18:27:03 Jonas Maebe wrote:
> On 06 Jun 2009, at 17:36, fpcl...@silvermono.co.za wrote:
> > Is there a reason why the following code fails to compile in Delphi
> > but
> > compile in FPC? Could the reason be that FPC allows the use of global
> > properties?
>
> No, it's an error in FPC which has been fixed in 2.3.1:
> http://wiki.freepascal.org/User_Changes_Trunk#Treating_direct-mapped_proper
>ties_as_regular_fields
>
>
> 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
