I suggest you ...

Add interface support for basic VCL classes

Most of the classes in VCL don't have interfaces support. F.e. add interface IStrings(TStrings), IField(TField), IDataset(TDataset), IDatasource and so on.
You have created great VCL classes hierarchy, just add similar interfaces hierarchy - this is so easy to implement, but can significantly improve coding speed.
F.e., just imagine common interface for DbControls - IDBControl, which may look like that(:
property Datasource: IDatasource;
property Fieldname:string;
property DataField: IField;
Adding such interface will make work with different DbControls much easier.

And so on with other classes.

Passing interfaces will make possible to interact between DLL-s, that were compiled different Delphi versions, and many more other improvements.
Using interfaces will allow to declare variables as interfaces, and not worrying about freeing them.

How about that?

236 votes
Vote
Sign in
(thinking…)
Sign in with: Facebook Google
Signed in as (Sign out)
You have left! (?) (thinking…)
tdelphi shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

7 comments

Sign in
(thinking…)
Sign in with: Facebook Google
Signed in as (Sign out)
Submitting...
  • Antonio Bakula commented  ·   ·  Flag as inappropriate

    I would surely like ISQLDataset with SetSQL and GetSQL methods (and of course with SQL property), for example implementation of that methods for TClientDataset willget/set CommandText, for TSQLQuery SQL property and so on.

    I did this my self but then I must make descendants for every dataset type that implements this ISQLDataset interface

  • tdelphi commented  ·   ·  Flag as inappropriate

    Here is one more example:

    If we had following interfaces:

    IDataSourceProperty = interface
    property Datasource: Idatasource;
    end;

    IDataFieldProperty = interface
    property DataFieldName:string;
    function GetDataField: IField;
    end;

    IReadOnly = interface
    property ReadOnly: Boolean;
    end;

    Then, our work with Db-controls could become simpler, just checking if control supports interface.

    It could be useful, for example, for unified applying security features for controls. For example, if user is prohibited to access some field in database, then we could easily check all controls on form, which work with this field and make it disabled and invisible. Or even read-only.

    It could be done even now, but have to use TypInfo unit's functions(which work only for published properties), or check types manually. For example, like that:

    If aControl is TDbEdit then
    tmpField := TDbEdit(aControl).DataField
    else
    If aControl is TDbMemo then
    tmpField := TDbMemo(aControl).DataField
    else
    If aControl is TDbComboBox then
    tmpField := TDbComboBox(aControl).DataField;
    if tmpField.Fieldname = 'ProhibitedField' then
    aControl.Enabled := False;

    Just because TDbEdit inherits from TCustomMaskEdit, TDbComboBox inherits from TCustomComboBox, but TDbMemo inherits from TCustomMemo.

    Hope, this example, makes my idea more clear.

  • tdelphi commented  ·   ·  Flag as inappropriate

    p.s. there's nothing wrong with declaration:
    property DataField: TField;

    But, using interfaces, maintaining and refactoring large applications will become MORE FLEXIBLE.

  • tdelphi commented  ·   ·  Flag as inappropriate

    And the last and most important aspect:

    It will become MUCH EASIER to write more universal code. Most of my applications work with database and use Db-aware controls like TDbEdit. Sometimes, I change used controls for more advanced(f.e. TDbEditEh from Ehlib library). After replacing components on form, i have to find all the places it was used, and replace all type casts like Sender as TDbEdit to something like Sender as TDbEditEh, i have to spend time for doing this, just because new components do not inherit from the old ones. And when, after some years, I'll find better Db-controls library, I'll have to spend time for the same things again.
    But if TDbEdit have supported some basic DbControl interface, which covers 80% of all Db-control functionality and supported by ALL DbEdit-like controls.
    IDbControl = interface
    DataSource: Idatasource
    DataFieldname: Istring;
    DataField: IField;
    ...

    Then, in most places we could use just this interface. So, replacing components will become MUCH EASIER, without having to search for hard-coded type-casting,

  • tdelphi commented  ·   ·  Flag as inappropriate

    The other point is that, interfaces support to base classes will ease automatic memory managment. For example, instead of writing
    procedure SomeProcedure;
    tmpSL: TStringList;
    begin
    tmpSL:= TStringList.Create;
    try
    // some code
    finally
    tmpSL.Free;
    end;
    end,

    I'd like to write:
    procedure SomeProcedure;
    tmpSL: IStringList;
    begin
    tmpSL:= TStringList.Create;
    // some code
    end, // tmpSL will be automatically freed

  • tdelphi commented  ·   ·  Flag as inappropriate

    No, I'm pure Delphi coder.

    No, pointers are not the same. F.e. we can use pointers to pass them into dll, and use a hard type-casting there: TField(pointer). But, in this case, we must be sure, that dll and exe were compiled with the same Delphi version.

    I'm maintaining few big applications, which were started with Delphi 3. Some of our clients still using them. I'd like to make my applications modular, but i don't wanna mess with COM technology, and don't want to use BPLs, because I cannot guarantee, that classes structure will be the same in BPL's and exe.

  • obucina commented  ·   ·  Flag as inappropriate

    You were learning programming on Java, aren't you? We can do all the things explained by using pointers. The way you describe this, I do not see the benefits. Whats wrong with declaration
    property DataField: TField;

Feedback and Knowledge Base