Olaf’s Thoughts About Development

In OOP, we are using Properties to be able to limit access to class members, or to have “calculated” values.  In Delphi Native Pascal, a class with 3 properties may look like this:

TEmployee = class(TPerson)
private
FHoursPerWeek: Double;
FWeeklyRate: Double;
FHourlyRate: Double;
procedure SetHourlyRate(const Value: Double);
procedure SetHoursPerWeek(const Value: Double);
function GetWeeklyRate: Double;
public
property HourlyRate: Double read FHourlyRate write SetHourlyRate;
property HoursPerWeek: Double read FHoursPerWeek write SetHoursPerWeek;
property WeeklyRate: Double read GetWeeklyRate;
end;

...

{ TEmployee }

function TEmployee.GetWeeklyRate: Double;
begin
Result := HourlyRate * HoursPerWeek;
end;

procedure TEmployee.SetHourlyRate(const Value: Double);
begin
FHourlyRate := Value;
end;

procedure TEmployee.SetHoursPerWeek(const Value: Double);
begin
FHoursPerWeek := Value;
end;

In the example above “HourlyRate” is what an employee get’s paid per hour. This value can be read and set. “WeeklyRate” is a read/only calculated value, which depends on “HourlyRate” and “HoursPerWeek”.

This all looks fine and we know how to deal with that since years. And it works the same way in Delphi Prism.

But sometimes, when you design a new class, do you always follow the “property-hides-field” pattern? Even if Delphi makes life easy with “Ctrl-Shift-C”, the code may look pretty much bloated, esp. if you have standard properties, not doing anything special. So you might just use “simple” Fields where possible. This is bad design of course, as if you need to change to a “real” property later, because you need to calculate something in a get or set method, you would have to change your classes signature, which may break compatibility …

Delphi Prism introduces two new language features to Pascal, which may prevent code from bloating and actually helps readability.

Implicit Fields

Implicit fields are fields which are created by the compiler automatically for properties which do not have any read or write accessors.

This is how the example would look like using implicit fields:

TEmployee = class(TPerson)
private
FWeeklyRate: Double;
function GetWeeklyRate: Double;
public
property HourlyRate: Double;
property HoursPerWeek: Double;
property WeeklyRate: Double read GetWeeklyRate;
end;
implementation

{ TEmployee }
function TEmployee.GetWeeklyRate: Double;
begin
Result := HourlyRate * HoursPerWeek;
end;

So this already look much less bloated. Implicit fields are not an invention of Delphi Prism though, but they were introduced with C# 3.0 Implicit Fields exist in Prism since 2004. They were introduced to C# 3.0 just a moment later, in 2008 , and they are called Auto-Implemented Properties here. The beauty of Pascal gets apparent though, once you compare Prism’s syntax with its C# equivalent:

class TEmployee
{
public Double HourlyRate {get; set;}
public Double HoursPerWeek {get; set;}

...
}

In Pascal there is no need to write these “stub” get and set calls.

Technically, it’s important to notice that Prism automatically creates a “get” and “set” method, plus a hidden private field for these properties. These hidden fields cannot be accessed in the classes code,  just use the Property itself everywhere. If you are not convinced that there are really hidden fields, then lets have a look at the IL code behind that (extracted using Red Gate’s Reflector):

.method public hidebysig specialname instance void set_HoursPerWeek(float64 'value') cil managed
{
.maxstack 3
L_0000: ldarg.0
L_0001: ldarg.1
L_0002: stfld float64 WindowsApplication5.TEmployee::@p_HoursPerWeek
L_0007: ret
}

The field gets obviously hidden by using “@” in it’s name which is not valid for Pascal, thus cannot be accessed. In C#, they are using brackets in the hidden private field name for the same purpose:

<HoursPerWeek>k__BackingField

Inline Expressions

With inline expressions you can make the code look even nicer. And best of all, to my knowledge there is no C# equivalent

Inline expressions may be used directly after the “read” keyword. This may drastically improve the readability of your code. Compare the final code example with the one at the very top!

TEmployee = class(TPerson)
public
property HourlyRate: Double;
property HoursPerWeek: Double;
property WeeklyRate: Double read HourlyRate * HoursPerWeek;
end;

Yes, this the complete TEmployee definition. No further implementation needed. Just 6 Lines, compared to the initial roughly 25 ones!

The Delphi Prism Wiki has an entry about “Class Properties”, which explains a few more details. (The “Implicit Fields” feature is a bit “hidden” though)

This entry was posted on Tuesday, December 16th, 2008 at 14:00 and is filed under .NET, Delphi, Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.