The beauty of class and record helpers

[Rollo62 536]

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 October 14, 2019 by Rollo62

[David Heffernan 2345]

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. 

[Rollo62 536]

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 October 14, 2019 by Rollo62

[Cristian Peța 103]

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 October 14, 2019 by Cristian Peța

[Rollo62 536]

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') ;

 

 

[dummzeuch 1505]

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...

[Fr0sT.Brutal 900]

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

[Rollo62 536]

Yes, I agree too all whats said.

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

[Fr0sT.Brutal 900]

Then you'd better keep away from JavaScript ;)))