Jump to content
Rollo62

The beauty of class and record helpers

Recommended Posts

Hi there,


I just stumbled about some class helpers, I rarely use, and I found that Embarcadero seems to have a different understanding of howto use them.

For example TByteHelper.Parse

I would have expect to use it like this:

var
    LByte : Byte;
begin
    LByte.Parse( AString );
    // Use LByte
end;

Unfortunately Delphi has set Parse as static class function in the record helper, which leads to the following useage:

var
    LByte : Byte;
begin
    LByte := Byte.Parse( AString );
    // Need an assignment here
end;

 

Why not using the first version ?
I assume this if because Delphis internal types, like Byte, Integer, etc. are special datatypes, and lack a kind of "Self" behaviour.

What I'm thinking of is, does the 2nd version maybe has some other advantages over the 1st version, which would make it the preferred choice.
If anybody has a good reason why I should prefer the 2nd version also with my normal types and classes, please let me know.


 

 

 

 

Edited by Rollo62

Share this post


Link to post

You can implement a helper the way you expect, but mutating methods on value types is troublesome. Imagine passing such a type as a const param and then calling such a method. Because Delphi lacks const methods (as found in C++), such things cause havoc. 

  • Like 1

Share this post


Link to post

Aha, right.  Thats a good reason to use the 2nd version.

I thought that I would get a warning, that I cannot modify const.

Have to check how this behaves ...

Edited by Rollo62

Share this post


Link to post

It's like passing an object as const. You can do what you want with the object because const is only for the reference.

 

P.S. But compiler can decide to put this const into a registry or pass as reference. Nice to track down bugs...

Edited by Cristian Peța

Share this post


Link to post

Ok, from time to time I use records as simple parameter containers,
without such convenience methods like Parse() since I don't need them (I thought I'm a little old.fashioned then)

procedure TForm1.UseMyRecord(const ARec: TMyRecordTest);
begin
    ARec.Parse( '42' );        // This opens a "backdoor" to the const record, better don't do

    if ARec.FField = 42 then
    begin
        ARec.FField := 0;  // This doesn't compile, thats fine
    end;
end;

Thats enough reason for me to start liking ugly constructions like   LMyVar := Byte.Parse('42') ;

 

 

Share this post


Link to post

I have been bitten by methods changing a given record multiple times: Some examples are

* changing a const parameter

* a property no longer changing its value after adding a getter method for it (boy was that one hard to track down)

 

Nowadays I try to avoid them, but sometimes they are just too convenient...

Share this post


Link to post

The constructions are not "ugly", they are just a class methods, understandable, clear and having no side-effects.

Share this post


Link to post

Yes, I agree too all whats said.

Still I don't like the usage of class functions on basic types, my fault :classic_blush:

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×