[CLOSED] something like "named parameters"

[Чебурашка]

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.  

This approach is ok in case initializations can be done at compile time, except for the need of creating these record structures, maybe just for being used as method arguments.

OTOH named parameters in the C# meaning mess up the compiler activity far more than the actual benefit to the end users, if any.

People like me wanting to put some extra reading helpers can go ahead in the way they are used to.

[Bogen85]

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.  

As long as the receiving function is not receiving it as a var parameter, then the intermediate variable can be skipped, and just the constant used.

Somewhat disconnected, but does meet than named parameter requirement.

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

Agreed. This solves the overloading issues.

And this already works, no changes required.

Of course to initialize with something other an constant, a variable is needed.

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

1. {$mode objfpc}
2. {$H+}
3. program namedparam;
4.  
5. type TRec1 = record
6.     a: integer;
7.     b: string;
8.   end;
9.  
10. procedure np(constref rec1: TRec1);
11.   begin
12.     writeln('a: ', rec1.a, ' b: ', rec1.b);
13.   end;
14.  
15. const
16.   p0 : TRec1 = (a: 5; b: 'b');
17.  
18. var
19.   p1 : TRec1; // = p0; namedparam.pas(19,3) Fatal: Syntax error, "(" expected but "identifier P0" found
20.  
21. begin
22.   np(p0);
23.   p1.a := 7;
24.   p1.b := 'second';
25.   np(p1);
26. end.

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

1. $ fpc namedparam.pas
2. Free Pascal Compiler version 3.2.2 [2022/08/17] for x86_64
3. Copyright (c) 1993-2021 by Florian Klaempfl and others
4. Target OS: Linux for x86-64
5. Compiling namedparam.pas
6. Linking namedparam
7. 26 lines compiled, 0.1 sec
8.  
9. $ ./namedparam
10. a: 5 b: b
11. a: 7 b: second
12.  

[Leledumbo]

Of course to initialize with something other an constant, a variable is needed.

You can follow the approach of TRect record and Rect function, among others, a pattern that has been established for years for stuffs like this.

[alpine]

Apologies that I'm posting in a closed thread, I just wanted to show what a incomprehensible jigsaw can be the usage of named parameters and the inplace object creation. See the attached picture. Parameter names painted green.

Fully agreed with Martin_fr for replacing booleans with enums. I would even add:

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

1. {$SCOPEDENUMS ON}

[Чебурашка]

Apologies that I'm posting in a closed thread

U welcome.

I just wanted to show what a incomprehensible jigsaw can be the usage of named parameters and the inplace object creation. See the attached picture. Parameter names painted green.

In this case I agreee that is quite complicated. But would it be less complicated without them?

Fully agreed with Martin_fr for replacing booleans with enums. I would even add:

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

1. {$SCOPEDENUMS ON}

As I said, this solution has some cons and is difficult to apply in general (to other datatypes).

[MarkMLl]

Apologies that I'm posting in a closed thread, I just wanted to show what a incomprehensible jigsaw can be the usage of named parameters and the inplace object creation. See the attached picture. Parameter names painted green.

Well, you can write $DEPRECATED_LANGUAGE in any notation :-)

The test is not whether some notation can be used to write something which is difficult to understand, but whether it allows a particular... dare I say pattern here? to be expressed succinctly without the introduction of syntactic sugar specifically for that use case.

I think FPC already goes a long way towards explicitly-named parameters via records. It would be nice if some of the remaining gaps could be filled in, for example being able to specify the default values when a type is declared and being able to specify the value of an individual field inline. However all of this is basically syntactic sugar: *provided* that somebody recognises that he's doing something problematic, Object Pascal already provides him ways of being defensive.

MarkMLl

[PascalDragon]

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.

At least GCC, LLVM and MSVC do, because at least developers of the later two are members of the committee and often they implement experimental features that are in the evaluation phase of the next standard.