Archive for June, 2011

hcOPF - Object Lifetime Management

Monday, June 13th, 2011

In more complex application scenarios, especially multi-threaded ones, it is difficult to determine when an object can be safely destroyed. The last thing you want to do is prematurely free an object that is referenced elsewhere and then try to track down all the mysterious AVs that only result in specific situations that users cannot describe sufficiently for you to isolate the problem.

For example, if you have a customer object they may be referenced by an invoice being processed, and a form to change their contact information. When the invoice is completed, the developer cannot simply assume they can destroy the customer object. There are several possible solutions to such a problem:

1) clone the object whenever it is referenced. This isn’t really a good idea. It chews up more resources, and data modifications on the clones can cause last-write-wins problems with valid data being over written with stale data. One of the benefits of an OPF is requiring fewer round trips to the database to refresh data than a TDataSet approach, but this only works if all changes are made through a single instance of the object.

2) Use reference counted interfaces. This solution has a couple drawbacks that I can think of.  You cannot use indexed properties in an interface definition. For hcOPF that would mean generating individual getter and setter methods for each attribute, rather than using a generic property definition such as:

 property Name :ThcAttribute Index 12 read GetAttribute;

That would require a lot more code generation and a much more brittle object definition that’s difficult to maintain over time.  In addition, hcOPF was designed using a Class model so the framework handles the object internally as class instances rather than interface references.  This would be a significant architecture change, and I don’t think it would be worth it.

3) Use manual reference counting.  With this approach there is minimal overhead; less than even interface ref counting, but the downside is it’s completely up to the developer to implement, and it requires keeping a list of the root objects that need to be destroyed.

The latest commits for hcOPF provide additional support for monitoring the RefCount of an object, adjusting it (Retain/Release) and logging it’s destruction with CodeSite.  Unfortunately, if you’re familiar with Retain/Release you might be hoping for something like Apple’s ARC functionality but it’s just not possible since it’s implemented as part of the compiler.

The Trials and Tribulations of Embarcadero

Friday, June 3rd, 2011

My current client wanted to upgrade the project I’ve been working on for the past year in Delphi 7 to a more recent version of Delphi and the VCL for improved support of Windows 7.  I had the option of using Delphi 2007 for development, but I chose Delphi 7 because

  • the IDE is leaner
  • the form designer is about 4x faster
  • Delphi 7 doesn’t give me E2027 errors when trying to evaluate simple things such as Object.ClassName
  • CodeRush for Delphi still makes development faster for me
  • Delphi 7 is still more stable than Delphi 2007
  • the IDE pause while parsing code in the editor isn’t quite as long (although still extremely frustrating)

Of course Delphi 7 doesn’t have

  • VCL support for window ghosting and improved Z order handling
  • MSBuild which provides Debug and Release configurations with easier build automation
  • new language features and all the other changes found here
  • all the improvements made since D2007

I would have opted for Delphi 2010 but we use components that I didn’t want to have to initially port to Unicode.  Now it looks like porting to Delphi XE is a better option than using Delphi 2007, so I downloaded a trial version of Delphi XE to make an attempt.

The installation of the trial was fast and pain free, but then I tried to install the JCL/JVCL.  The installer appears to work, but no components appear, and no DCUs are generated.  A closer look at the JCL log file reveals:

Compiling package Z:\JEDI\jcl\packages\d15\Jcl.dpk
[snip]
This version of the product does not support command line compiling.
Compilation success
...done.

Obviously the error code returned from the compiler must not be what the JCL installer expects, but neither is the fact that an Architect Edition Trial cannot install such popular components suites as the JCL/JVCL and DevExpress.  They should really call the Trial edition Crippleware.

Does Embarcadero seriously think that anyone about to spend Can$3,387.29 for a new Architect edition would be left with a positive impression of the product after having to work around such limitations just to install the components they want?  If Embarcadero is so confident in their licensing protection why cripple the product?  It is after all, only a 30 day trial.  If you have any serious work in addition to your porting efforts, 30 days may not even be enough!

I think EMB needs to seriously look at why users download a trial.  I would venture that most of the time it’s so developers can experiment with the new features in that release and attempt to get their projects compiling in it.  If the latter is successful, chances are EMB has a new sale.  Making the process more frustrating just embitters current and potential new customers as well as undermining the efforts of vendors such as DevExpress and long time supporters in the community offering open source solutions such as the JEDI.  This has been a problem since the Delphi 2007 trial was released.  Apparently someone is still sleeping at the wheel.