Community pulse: New ways to enhance Delphi

There is an interminable thread on the public.non-technical battlefield called ‘Delphi for the Mac’. At the time of writing, there are approximative 500 (five hundreds) posts on that. (493 to be more exact). No, I won’t provide a link. Because I think that is better (at least now after 500 posts) to start a concrete discussion in order to enhance our tool of choice.

Don’t get me wrong, I do think that defending a tool is good, but this defense must take the form of enhancing our product, and not denigrating the other one just because it doesn’t fit with “my/our” philosophy.

So, in my humble opinion, we must take and adapt what is good on the other product (XCode / Interface Builder in this case) and avoid what is bad. I know that you are willing to do give feedback on this, the vast majority of you proved it many times, including in the last poll which we made. The results are depicted in our classical pie on the right.

However, our community has a long lasting disease – we transform ourselves in a community of talkers in order to be a team of doers. We had this also with .NET and now it seems that we start to have it with Mac. Sons, the better covering of user’s needs through innovation is the thing which will ensure our survival.

So, in short: …and correct me if I’m wrong. 🙂

We need to have enhance the productivity of our tool. Mac “has” MVC. Ok, other languages “has” MVC. Java “has”, .NET “has”… I think that’s time for Delphi to “has” it. Yeah, I know that there are community projects which implement MVC or similar patterns but I think that for example tiOPF is (unfortunately) far enough from Delphi community core in order to say that Delphi “has” an OO framework. I speak now primarily from the cultural point of view. The death of Bold and ECO left more traumas than we thought. But about the need of having a framework in Delphi (an about other things) we spoke in What means RAD Anyway?.

…hence we will concentrate now on another aspect of Delphi which appears constantly in Delphi vs .NET and Mac debacles. It is its data binding mechanism.

There are some ways to display data on GUI artifacts:

• Build special objects to hold the data (eg. TDataSet descendants) and special components which consume this data. ‘Nuff said.
• Interfaces. Good but is on-premise
• Class Signatures. Better – on-demand.
• Bindings.
• Attributes
• Multi-cast Property Triggers.

Of course, all the above can be used together. Beware: I didn’t say that you should do that, though.

Perhaps the last one (Multi-cast Property Triggers) needs some explanation. If you think Delphi, think it like an event handler which is fired exactly before (or after) a property value is set. If you think database, think at a database trigger (you know, 'Before Update', 'After Update' etc.). Of course, these can be added and removed using a mechanism similar with the multi-cast events. Also, this feature will be a very good thing in implementing Design by Contract. Yeah, I know that DbyC can be achieved also using other methods but I think that one of the things which Delphi must enhance nowadays is its flexibility of expression.

Oh, and a very draft syntax: (all the ‘x’ types are custom types of the actual ones provided as drafts for discussion)

  function AddBeforeTrigger(aProperty: TxRTTIProperty; aCode: TxTriggerProcedure): TxResult;
  function AddAfterTrigger(aProperty: TxRTTIProperty; aCode: TxTriggerProcedure): TxResult;

  function RemoveBeforeTrigger(aProperty: TxRTTIProperty; aCode: TxTriggerProcedure): TxResult;
  function RemoveBeforeTrigger(aProperty: TxRTTIProperty; aCode: TxTriggerProcedure): TxResult;

…or perhaps a much more OO approach like:

  myProperty.Before.AddTrigger(aCode); //'Before' being a list with Add, Delete, Items, Count members...
  //same stands for 'After'

I do think that the 2nd approach is far superior and gives much more control on the things. Also, TxTriggerProcedure will have as parameter the well known Sender: TxRTTIProperty.

How do you envisage the data binding mechanisms of the next Delphi?