TPersistent.com

If you aren’t subscribed to the delphi feeds or Nick Hodges blog you may not have noticed his recent post proposing that EMBT open source their unit tests.  If not, do yourself a favour and subscribe…

I blogged some time ago about EMBT needing to increase their leverage of open source like Apple and other IT companies, so it comes as a nice surprise that someone who has seen behind the corporate veil advocates a similar move to what I have previously recommended.

While I would agree with Nick’s premise that EMBT should make some Delphi source code open source, I’m afraid I can’t see it happening for several reasons:

1) Logistics/Resources.  As Nick concedes, resources would be necessary to act as GateKeepers for the project source.  Finding trusted gatekeepers with the time and willingness to participate on an on-going basis can be challenging.  If there is no compensation involved, and no corporate sponsorship in the form of donated developer time etc, it’s hard to keep a project alive. Even with gatekeepers, EMBT resources would be required, and they don’t seem to have any available cycles, or the benefits do not appear tangible enough to management.

2) Historical adversity to open source

While EMBT may be a different company from Borland, they have many of the same principal people and therefore share a similar perspective concerning open source projects.  Based on their closing of the open source PNG project after they integrated the code into Delphi, and the open sourcing of Interbase 6, I would have conclude they view open source as competition, not as an opportunity.  Interbase apparently only has one engineer left on the TEAM (is that expression “there is no “i” in TEAM” or “no ‘1′ in TEAM”…hard to tell sometimes).   Despite having resource issues, and Interbase accounting for (I believe) a small portion of their revenue, it remains a forked project from the IB6 source code, instead of being built in concert with Firebird.  Perhaps that is no longer possible since the fork took place so long ago, but EMBT has not decided to open source the current version of Interbase either.  Perhaps they view IB for iOS as a strategic product now.

3) Risking IP

While units of the RTL and VCL are included with some versions of the product, some source units have always been missing AFAIK in order to keep the RTL and VCL from being compilable, and all of that IP (intellectual property) from being “known”.

4) Accepting Constructive Criticism

EMBT is just not that receptive to having staff interact with customers and accept customer code contributions and criticism of EMBT code, policy, or implementations.  All you have to do is look at the evolution of FireMonkey, or in QC to see how well EMBT accepts and addresses customer criticisms of either their code, or implementations.

To write tests properly you need to have access to their code and any accompanying documentation.  EMBT is not about to open up access to anyone, otherwise DelphiSpeedUp would not be a necessary project, and the issues that Andreas has found and fixed would be immediately incorporated into the product and an official service pack would be released.  DelphiSpeedUp would not have to support multiple EMBT product releases with much of the same fixes.

Even open sourcing the IDE would be a good move.  There are bugs from eons ago in QC, some of which have been accepted into the internal bug tracking tool, that remain unaddressed.  The result is that we have code completion that produces uncompilable code, code navigation that is practically non-existent when compared to other IDEs, and multiple parsers for error insight, code completion etc, stalling the IDE’s main thread.  Not to mention all the missing re-factoring capabilities, code templating, clip board management etc that were available in CodeRush in Delphi 3 era, and now are only available in third party enhancements like Castalia, or in half baked form.  Why?  In part because Borland didn’t work with Mark Miller, the GExperts group and other customers to foster an ecosystem for IDE add-ins.  EMBT has continued this tradition and as a result, the IDE has fallen behind, just like DBX did.  Perhaps EMBT will buy another editor to try to catch up, but that didn’t work out so well last time.

A new developer’s first impression is the IDE, and it needs a lot of work compared to it’s peers.  The IDE is hardly EMBTs core IP, so it’s a natural one to leverage open source with.  The community has also shown with SynEdit that it could and would both use and extend such an offering.  Open sourcing the IDE would yield a much better result IMHO than anything else, but you don’t see EMBT doing so despite what I would call the success of leveraging the FastCode, and PNG projects, or the efforts of Andreas Hausladen.

5) Open Source is about giving back

To date, EMBT’s usage of open source seems to be about taking what they can get from open source, whether it be using Hudson internally for CI, or PNG, FastCode source code without apparently much in the way of giving back.  It still baffles me, that FPC was used in XE2 for iOS support, but I didn’t hear of any EMBT contributions back to the project, and there didn’t seem to be any fan fare in the product press release.  I couldn’t find a single reference to FreePascal, just “FireMonkey also enables Delphi XE2 users to create native HD and 3D applications for mobile (iOS) devices”.  Apparently a compiler was not necessary for iOS support.

Certainly one of the few contributions I am aware of, as a follower of Delphi, is their recent release of LLDB code.  The whole idea of open source is building a synergistic community and that requires contributions from all participants in a constructive fashion.

While progressive companies like Google, and Apple are leveraging open source projects in the commercial offerings while contributing to the evolution of those projects, EMBT still seems to be struggling to determine a strategy to do so.  One of the best things about Delphi is its community with the knowledge and experience they possess.  So far that has been pretty much untapped by EMBT.

If you have ever used the Debug Inspector you might have noticed it can be rather challenging to find a property, or method in a larger class that is a distant descendant of TObject.  Data, Methods and Property names are intermixed in their respective tabs, starting with (I believe) their root ancestor downwards.  IOW,  they don’t appear in alphabetical order.

The Delphi Debug Inspector

The Debug Inspector uses the same TInspListBox as the the ObjectInspector, so you can search for items by name by selecting the item, pressing Tab (The cursor will appear in the names section of the list), and typing the name of the item you’re looking for.  Unfortunately, using such a “Begins With” search has limited usefulness when the items are not sorted alphabetically.

Anyone know how to alphabetize this list?

Maybe I am daft, but ever since HTML help was introduced with the Galileo IDE, I can’t find much in the way of help.  I often configure later versions of Delphi to invoke the D7 help so I can find what I need.  That version of help was apparently put together by Danny Thorpe, so hitting F1 in the D7 IDE would bring up a topic for the current selected identifier in the editor.

So why is it that 11 years later, with technology marching forward, that I can’t do the same thing in XE4?  I quite often can’t even locate items by searching for them.  Despite selecting filters to prevent .NET and Visual Studio related material, I still get nothing relevant to Delphi or “RAD Studio”.  Take for instance the results of these screen shots searching for refactoring information.

Help on Refactoring

Google seems to provide much better results in a shorter search timeframe…

I just updated the sourceforge repo with VCL projects for XE4 with the exception of HengenOPFJVValidators (I don’t have JVCL installed at the moment). Simply define an environment variable “hcOPF” to point to the root folder for hcOPF and you should be able to compile the packages. Rt. Click on all dcl prefixed packages and choose Install from the local menu.

Enjoy!

Today I ran across yet another limitation of SyncEdit.  Incredible you say?  Check out the following sample code:

procedure CreatePackage(anInvoiceItem :ThcInvoiceItem; aClient :ThcClient);
begin
  if anInvoiceItem.AssociatedProduct.StockType.AsString = 'PACK' then
    CreatePackage(anInvoiceItem.AssociatedProduct.PackageType.AsString);
end;

Rather than use a Search/Replace as I would normally, I chose to invoke SyncEdit after highlighting the method.  Then I discovered I could not replace anInvoiceItem.AssociatedProduct with aProduct.  SyncEdit will not allow you to remove an identifier, so the closest I could get was a.aProduct.  Likewise, SyncEdit cannot be invoked when you use Ctrl+A to select the entire unit.  While it may be flashy, it’s not as flexible or as fast to use as Search/Replace IMHO.