type helpers are awesome.

[guest58172]

It's clearly a feature that was needed. For new stuff it's awesome, for old stuff it can become a problem. It's a semantic thing:

for example let's take this helper:

Code: Pascal  [Select][+][-]

1. TStringHelper = type helper for string
2.   function isEmpty: boolean;
3.   function isNotEmpty: boolean;
4. end;

it allows to write

Code: Pascal  [Select][+][-]

1. if str.isEmpty

instead of

Code: Pascal  [Select][+][-]

1. if str = ''

but it can easily becomes unclear:

Code: Pascal  [Select][+][-]

1. if project.baseFolder.isEmpty then ...

the isEmpty helper is for a string but here the meaning is unclear: is the string that represents the path is null or is the folder represented by the string physically empty ?

That's the problem we'll encounter when trying to modernize our code.

 

[taazz]

Yeah it requires a lot of attention picking a name as you have found already. IsEmpty is one of those names that probably should not be used so lightly. Unless of coure the BaseFolder is of type TFolderName is which case things become easier to handle. Any way you my friend are not allowed to modernize your code beyond 2.6.4 not while 2.6.4 is still the only supported version. Modernizing should start after the 1st stable release of lazarus 1.6.

[guest58172]

Personnaly I've made the jump, but let's be clear: after refactoring I didn't felkt good...it's a bit scary. Did i do the right thing ? Did I kill myproject, when I've chosen to use helpers ?

[taazz]

Personnaly I've made the jump, but let's be clear: after refactoring I didn't felt like a Brooklin hypster...it's a bit scary. Did i do the right thing ? Did I kill myproject, when I've chosen to use helpers ?

 

My experience? OK here it comes. Don't convert any working code, if you decide to convert keep a back up just in case you have to support older compiler versions. As lazarus keeps on releasing  new versions it might become a mute point in the near future but until then make sure you will not have to undo your conversions. Know your targets linux, windows, desktop, embedded (what ever you need) and know which compiler version supports your platforms does your library support that version? Is this version the latest or you need to go back a couple of versions? If in high spirits you forgone all caution and converted everything shit back a bit have a glass of wine a beer or something heavier (what ever you like) and enjoy it. You have followed you heart and that is the most important to remember. Get ready to rewrite what ever might be needed if you have to support an older version and that's all you will ever have to do.

Your project is not going to fail or die a horrible death, you are not going to loose everything you own, your wife will not divorce you and you will still have to wake your kids every morning for school.
Then again you already knew all this and you were probably ironic, any way have fun.

[marcov]

The big problem with type helpers is that only one is allowed per type (in the scope, not in the program).

So if you make a library with type helper for string with that, and you use a library that use another typehelper for string, you might get into trouble.

So use with care.

I use typehelpers mainly for TStream, to brush away the fact that FPC defines more methods there than Delphi. That has been checked in partially in unit streamex.

[skalogryz]

I used type helpers to extended TRichMemo interface with Delphi's TRichEdit methods and properties, without bringing them to the actual TRichMemo interface or using any sort of inheritance.

I see them only as a tool necessary to overcome (backward) incompatibilities, similar to marcov's case. Imho, any other use should be banned. 

"dot" notation doesn't make a program to run faster or safer.  Infact, they could potentially even break some code (specifically using "with"s ).

[guest58172]

The big problem with type helpers is that only one is allowed per type (in the scope, not in the program).

So if you make a library with type helper for string with that, and you use a library that use another typehelper for string, you might get into trouble.

That's clearly important to my eyes, I didn't lnow that. Currently I juse use a single helper but I guess I'll have to always extend the same. Next step is all the file functions: extractFilePath, extractFileExt,... and goodbye the LOCs that ended with )));

[wp]

We will see tons of incompatibility issues due to the hype of introducing type helpers in FPC and everywhere else. The "with" construct of Pascal is not liked by many programmers, but it is used almost everywhere. Look at BGRABitmap (http://forum.lazarus.freepascal.org/index.php/topic,30525.msg200383.html#msg200383): This line

Code: Pascal  [Select][+][-]

1.     with ACursor.CurrentCoordinate do
2.     begin
3.       if ATexture = nil then
4.         TextOutAngle(x,y, -round(round(angle*1800/Pi), nextchar, AColor, taCenter)
5.       else
6.         TextOutAngle(x,y, -round(angle*1800/Pi), nextchar, ATexture, taCenter);
7.     end;

compiles fine in fpc 3.0, but fails in fpc 3.1.1: ACursor.CurrentCoordinate is a TPointF (= record x,y: Double;). But in fpc 3.1.1 the record has been extended with record helpers and record procedures, one of them being "round". As a consequence above code is broken because of the "with" statement: the "round" is attributed to the record helper, no longer to the system function as intended by the programmer. I am sure, record helpers will cause more trouble than the new strings of fpc.

[eny]

As a consequence above code is broken because of the "with" statement: the "round" is attributed to the record helper, no longer to the system function as intended by the programmer. I am sure, record helpers will cause more trouble than the new strings of fpc.

+1
The use of record helpers should absolutely be banned from the core of Lazarus (LCL and the likes).
Every person redefining standard functions should be banned in the same way and not allowed ever to come within a 100 mile radius from the compiler.