As an Advisory Board member I am proud to post this official pre-announcement for the next, long awaited physical Delphi conference.

Where: San Jose, CA, USA
When: May 13th – 16th 2009
Who: All Delphi developers, let it be Delphi Win 32, Delphi Prism or Delphi for PHP ones.

We will try to get all the known top speakers, from the US and Overseas to make this event absolutely rocking. The conference will be organized by Software & Support Verlag, supported by CodeGear / Embarcadero. San Jose was chosen as location as it is close to CodeGear’s HQ, so that CodeGear staff can show up easily.

Attendees

For now, block this event in your calendar if you are interested. We will keep the price affordable – details will be posted asap.

To register, please go to the DelphiLive 2009 Website – which will go online in the next two weeks. We will send announcement emails through CodeGear’s Developer Network as soon as registration is open. Make sure you are signed up at CodeGear Developer Network and CDN emails are not blocked by your spam filters.

Speakers

If you want to present sessions at Delphi Live 2009, then please stay tuned for the official Call For Papers, which will be made public in the next 2 days or so.

Topics

We will cover from basics to advanced topics all around Delphi. The final topic list will be made available as soon as the call for papers is closed.

Following is a draft of tracks:

• Architecture / Design
• OOP
• Database
• IDE, Tools & Components
• Core Development
• Basics / Fundamentals
• Native Delphi
• Delphi Prism
• Delphi & .NET
• Delphi & Web
• Delphi & PHP
• Delphi & Ruby on Rails

If you have suggestions for specific topics you would like to be covered (and which you do not want to present yourself), then feel free to post these suggestions as comments to this blog. The same goes for speakers which you would definitely like to see in San Jose.

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)