[CLOSED] something like "named parameters"

[Чебурашка]

In methods calls I often like to recall the name of each param so that when I read I see that a True is related to a certain parameter and this makes thing more reader friend.

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

1. procedure xyz(asourcePath: string; aCopyAll: Boolean; aDestinationPath: string; aOverwrite: Boolean);
2. begin
3.  // code
4. end;
5.  
6. xyz({asourcePath}'/home', {aCopyAll}False, {aDestinationPath}targetPath, {aOverwrite}False);
7.  
8. // or in alternative (but I almost always use the prev)
9.  
10. xyz(
11.   '/home', // asourcePath
12.   False, // aCopyAll
13.   targetPath,  // aDestinationPath
14.   False // aOverwrite
15. );
16.  

In other languages this is supported by the existence of named parameters:

Code: Text  [Select][+][-]

1. xyz(asourcePath: '/home', aCopyAll: False, aDestinationPath: targetPath, aOverwrite: False);
2.  

I was thinking that it would it be cool if also fpc has this feature.
WDYT?

[marcov]

IIRC something like this exists in Delphi for certain COM (IDispatch?) methods usage.

Still, IMHO vastly overrated, and making it more general would really complicate overloading selection rules

[Handoko]

Code: Text  [Select][+][-]

1. xyz(asourcePath: '/home', aCopyAll: False, aDestinationPath: targetPath, aOverwrite: False);
2.  

It is too verbose to me. It even hurts its readability. When debugging source code, my eyes need to scan hundreds of lines in a very short time, now the xyz line becomes too long to read, not helpful. See the comparison below:

xyz(asourcePath: '/home', aCopyAll: False, aDestinationPath: targetPath, aOverwrite: False);

xyz('/home', False, targetPath, False);

Not sure in FP and other editors, but in Lazarus IDE you can use ctrl+shift+space to get information about the parameters for the function/procedure you're typing. And if you hover your mouse on the identifier you will get information about it.

[Martin_fr]

In methods calls I often like to recall the name of each param so that when I read I see that a True is related to a certain parameter and this makes thing more reader friend.

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

1. procedure xyz(asourcePath: string; aCopyAll: Boolean; aDestinationPath: string; aOverwrite: Boolean);
2. begin end;
3.  
4. xyz({asourcePath}'/home', {aCopyAll}False, {aDestinationPath}targetPath, {aOverwrite}False);
5.  

In other languages this is supported by the existence of named parameters:

IHMO, wrong approach.

At least if you have control over the method itself.

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

1. type
2.   TXyzCopyMode = (xyzDoNotCopy, xyzCopy);
3.   TXyzOverwriteMode = (xyzDoNotOverwrite, xyzOverwrite);
4.  
5. procedure xyz(asourcePath: string; aCopyAll: TXyzCopyMode; aDestinationPath: string; aOverwrite: TXyzOverwriteMode);
6. begin end;
7.  
8. xyz('/home', xyzDoNotCopy, targetPath, xyzDoNotOverwrite);
9.  

Of course "DoNotCopy" is a bad name. But if for example the action in that case is "Move" then it would be xyzMove vs xyzCopy.

And you may even combine the 2 flags as a single "set of(xyzCopy, xysOverwrite)" param at the end. Having overall one less param to specify.

[Чебурашка]

Code: Text  [Select][+][-]

1. xyz(asourcePath: '/home', aCopyAll: False, aDestinationPath: targetPath, aOverwrite: False);
2.  

It is too verbose to me. It even hurts its readability. When debugging source code, my eyes need to scan hundreds of lines in a very short time, now the xyz line becomes too long to read, not helpful. See the comparison below:

xyz(asourcePath: '/home', aCopyAll: False, aDestinationPath: targetPath, aOverwrite: False);

xyz('/home', False, targetPath, False);

Not sure in FP and other editors, but in Lazarus IDE you can use ctrl+shift+space to get information about the parameters for the function/procedure you're typing. And if you hover your mouse on the identifier you will get information about it.

Prob my example is wrong.

Imagine a method with many floating point params (for example if you want to parametrize a -not so- complex industrial device)

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

1. procedure TNSComplexIndustrialDevice.SetParameters(
2.         aXZeroPointOffset_m: Double;
3.         aXExcursion_m: Double;
4.         aXResolution_m: Double;
5.         aXMaxSpeed_m_div_sec: Double;
6.         aXRamp_msec: Double;
7.         aXFirstStopOffset_m: Double;
8.         aXFollowingStopsDistance_m: Double;
9.         aYZeroPointOffset_m: Double;
10.         aYExcursion_m: Double;
11.         aYResolution_m: Double;
12.         aYMaxSpeed_m_div_sec: Double;
13.         aYRamp_msec: Double;
14.         aLaserMaxPower_W: Double;
15.         aLaserMaxFrequency_Hz: Double;
16.         aLateralRollWorkingPressure_MPa: Double;
17.         aLateralRollHoldingPressure_MPa: Double;
18.         aLateralRollRigidElementPressure_MPa: Double
19.         );
20.  
21. // Then called like
22.  
23. aObject.SetParameters(0.05, 0.453,0.00001,0.4,750.0,0.11,0.03,0.00,0.120,0.00001,0.4,710.0,2540,300,2.0000E6,1.5000E7,9.000E6);
24.  
25. // or
26. aObject.SetParameters(
27.   0.05,
28.   0.453,
29.   0.00001,
30.   0.4,
31.   750.0,
32.   0.11,
33.   0.03,
34.   0.00,
35.   0.120,
36.   0.00001,
37.   0.4,
38.   710.0,
39.   2540.0,
40.   300.0,
41.   2.0000E6,
42.   1.5000E7,
43.   9.0000E6);
44.  
45.  

For sure no indication makes line shorter, but not easy to attribute the meaning to each value.

Of course one could imagine to split the parametrization call into single parameter methods

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

1. SetParam_XZeroPointOffset_m(aValue: Double);
2. ///
3.  

But this will create a problem every day you add one more parameter, you have to make sure you add the new call in every place the parametriation operation is done, and if you forget to make it the compiler won't complain, but your new parameter in some cases is not set and you will not notice in code.

[Чебурашка]

In methods calls I often like to recall the name of each param so that when I read I see that a True is related to a certain parameter and this makes thing more reader friend.

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

1. procedure xyz(asourcePath: string; aCopyAll: Boolean; aDestinationPath: string; aOverwrite: Boolean);
2. begin end;
3.  
4. xyz({asourcePath}'/home', {aCopyAll}False, {aDestinationPath}targetPath, {aOverwrite}False);
5.  

In other languages this is supported by the existence of named parameters:

IHMO, wrong approach.

At least if you have control over the method itself.

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

1. type
2.   TXyzCopyMode = (xyzDoNotCopy, xyzCopy);
3.   TXyzOverwriteMode = (xyzDoNotOverwrite, xyzOverwrite);
4.  
5. procedure xyz(asourcePath: string; aCopyAll: TXyzCopyMode; aDestinationPath: string; aOverwrite: TXyzOverwriteMode);
6. begin end;
7.  
8. xyz('/home', xyzDoNotCopy, targetPath, xyzDoNotOverwrite);
9.  

Of course "DoNotCopy" is a bad name. But if for example the action in that case is "Move" then it would be xyzMove vs xyzCopy.

And you may even combine the 2 flags as a single "set of(xyzCopy, xysOverwrite)" param at the end. Having overall one less param to specify.

This method requires to create enumerated types (worst case is one binary enumerated for each boolean param of the program if meanings are orthogonal) and is not apllicable to strings, floating points, strcutured types, objects, pointers.

[MarkMLl]

I've had one case where named parameters would definitely have helped me avoid a difficult bug- if I'd used them. I'd added a parameter in the middle of a procedure declaration which already had defaults for parameters after that point...

I must admit that I'm partial to the Smalltalk keyword format, which does generally assume that the ordering is fixed. However that's exceedingly non-Pascal, and I think the most that it would be reasonable to expect would be a record (or tuple of some form) as a parameter where the fields could be identified by name.

MarkMLl

[lainz]

In Kotlin there are named parameters, but there's something better, Android Studio shows name of parameters sometimes, I've not determined exactly the cases, but it shows the parameters grayed. That's something can be done without touching the language but touching the IDE.

[Чебурашка]

I've had one case where named parameters would definitely have helped me avoid a difficult bug- if I'd used them. I'd added a parameter in the middle of a procedure declaration which already had defaults for parameters after that point...

I must admit that I'm partial to the Smalltalk keyword format, which does generally assume that the ordering is fixed. However that's exceedingly non-Pascal, and I think the most that it would be reasonable to expect would be a record (or tuple of some form) as a parameter where the fields could be identified by name.

MarkMLl

The problem with structured types as params (records or objects) is that is needed anyway at some point to set each value (in worst case), and if you have a method that sets them all, if you add a new param/field, all you hvae to do is adjust the method that sets them all, and fix all his calls, and you are sure all params are set otherwise it won't compile at all. So the problem is translated to that method.

[Чебурашка]

In Kotlin there are named parameters, but there's something better, Android Studio shows name of parameters sometimes, I've not determined exactly the cases, but it shows the parameters grayed. That's something can be done without touching the language but touching the IDE.

Also Laz editor shows param names while you type, but you must be doing that and cursor must be there, comma after comma. While you are simply reading the code this does not happen.

[Чебурашка]

making it more general would really complicate overloading selection rules

This is a valid objection to me. 

[Bogen85]

Named parameters are useful when all (or most) of the parameters already have default values, and you just want to change specific values.

But as marcov pointed out, this complicates overloading, because while two functions may have different parameter lists, they might both have the same named parameter.

Currently default parameters already complicate function overloading.

[Чебурашка]

Named parameters are useful when all (or most) of the parameters already have default values, and you just want to change specific values.

But as marcov pointed out, this complicates overloading, because while two functions may have different parameter lists, they might both have the same named parameter.

Currently default parameters already complicate overloading function overloaded.

Yeah, I was re-readin on MS C# docs, you can also swap params in method call al long as they are referenced by name. This goes far beyond my idea of improving (if so) code readability.

[VisualLab]

Named parameters are a rather typical case of syntax sugar. Minimal utility. In addition, some programmers will consider it a major flaw in the language (e.g. me). The Pascal language is considered verbose* (i.e. too many characters have to be typed in during programming), so this will be another pseudo-argument to discredit it.

In scripting languages and the like, this is probably relatively easy to implement (in the interpreter or VM). The times are such that various bells and whistles are added to the older languages that are still used, because it is fashionable.

I agree that the compiler needs to be corrected, improved and developed. But it's easy to overdo it. A good example is the "development" of C++ - a new "standard" every few years. In this particular case, the misfortune is that they were developed by a committee (Design by committee). I wonder if compiler makers really keep up with implementing these quirks.

---
*) Of course I don't agree with that. It's the C language (and its monster-babies) that have overly primitive notation, a kind of shoddy code obfuscation built into the language.

[MarkMLl]

The problem with structured types as params (records or objects) is that is needed anyway at some point to set each value (in worst case), and if you have a method that sets them all, if you add a new param/field, all you hvae to do is adjust the method that sets them all, and fix all his calls, and you are sure all params are set otherwise it won't compile at all. So the problem is translated to that method.

Yes, but the record representing the parameters can in principle at least be initialised from a constant:

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

1. const
2.   descriptionTemplate: TPortDescription= (
3.                          baseName: 'ttyUSB';
4.                          idVendor: '';
5.                          idProduct: '';
6.                          busType: '';
7.                          driverName: 'usb-serial/drivers/ftdi_sio';
8.                          manufacturer: ''; (* Avoid: varies on counterfeits etc. *)
9.                          product: 'FT232R USB UART';
10.                          serial: 'A50285BI' (* Common in counterfeit R/O EEPROM *)
11.                        );
12.  
13. var
14.   description: TPortDescription= descriptionTemplate;
15. ...
16.   result := FindPortByDescription(description, portScan)
17.  

I agree with

Still, IMHO vastly overrated, and making it more general would really complicate overloading selection rules

In fact I agree with it rather strongly, since the automatic casts applied by FPC (to at least numeric types) are already far too sloppy in my opinion. However thinking things through, once (named) parameters are encapsulated in a record the overloading is actually much less stressed: it's either that record type, or it's not.

MarkMLl