D people :

 I dont remember if this was already discussed, but I wanna write about
Parameters by Index versus Parameters by Name

The problem which I have when programing, is a confusion with parameter list of a function. Supose the following functions ( dont pay attention to sintax yet):

char* substring(char* Source, int Start, Length) { }   (1)
char* substring(char* Source, int From, To) { }

char* replace(char* inString, Pattern, byPattern) { }  (2)
char* replace(char* Pattern, byPattern, inString) { }
char* replace(char* byPattern, Pattern, inString) { }

The first case the problem is the two meanings of same name "substring". The
second problem is the confusion about order of parameters.
When I am writing code, often I feel confused and need search the help for
"function definition".

S : Could be much more easy if I could call the funcions passing parameters by name too. Consider the following examples :

(1)
  s = substring(Source=old_str, Start = MIDDLE, Stop = str_len(old_str));

or

 s = substring(old_str, MIDDLE, str_len(old_str) - MIDDLE);  // confusion
???

(2)
 r = replace(Pattern = 'C++' , byPattern = 'D', inString = 'C++ Programming
Language');

or

 r = replace('C++ Programming Language' , 'C++' , 'D');

Advantages :

1 - The order of parameters is not too important now. The definition of
function can change with none or lesser impacts.
2 - The programmer don't will need search by function in source code to see
the "definition". The code will be more easy to write.
3 - Programmers will not change, accidentally, the order, doing a mistake.
3 - The code could be more readable.
4 - The in, out and inout will not be affected
5 - The overloading will work as is now.

Disadvantages :

1 - The typing and code will grow.
2 - To change the parameters name will not be to easy as now, but they will
start have more significant names.
3 - The C programmers don't will like and will say : this is ugly.
4 - The matching parameter will have two algoritms increasing the compiler.

Problems :

a)
int somefunc(double base, int fator) {}
int somefunc(int base, double fator) {}

when I call the following example, the compiler will need to throw a error. But It could know in semantic analysis time.

x = somefunc(base = 10 , fator = 2);

What you think about this ?
Comments, Sugestions, Negatives ?

"Juarez Rudsatz" <juarez@correio.com> wrote in message news:a1hnec$1eap$1@digitaldaemon.com...

>  I dont remember if this was already discussed, but I wanna write about
> Parameters by Index versus Parameters by Name

It was =)

> S : Could be much more easy if I could call the funcions passing
parameters
> by name too. Consider the following examples :
>
> (1)
>   s = substring(Source=old_str, Start = MIDDLE, Stop = str_len(old_str));

Not suitable since = is an operator in D, and thus Source=old_str is a legal expression.

However, : could be used instead:

    s = substring(Source: old_str, Start: MIDDLE, Stop: str_len(old_str));

> 2 - The programmer don't will need search by function in source code to
see
> the "definition". The code will be more easy to write.

There are usually help files for that. Besides, you have to know parameter names then, so you will still have to look at the declaration.

> What you think about this ?
> Comments, Sugestions, Negatives ?

It could be added as an alternative to the base syntax. Sometimes - not very frequently though - it is useful. However, I wouldn't be glad to type in all the parameter names.

Also, D allows to omit parameter names in prototypes. Not really a big problem, still...

> s = substring(Source: old_str, Start: MIDDLE, Stop: str_len(old_str));

After send the post I was thinking in changing the char "=" by ":". Is a good idea.

> It could be added as an alternative to the base syntax. Sometimes - not very frequently though - it is useful. However, I wouldn't be glad to type in all the parameter names.

If you are working with standart functions or methods or tiny methods this is not very important, because you can remember fast the parameters. And the help is in your hands ( or your finger F1 ). But when your code is growing, you need sometimes search by method declaration for see what I need put in list parameters.

> There are usually help files for that. Besides, you have to know parameter names then, so you will still have to look at the declaration.

Sometimes yes.
I have programming in M$/Sybase SQL, which use the both form, by Index and
by Name.
No rarely will dont remember the order or you mix the diferent order with
omiting the parameters.
This is not a problematic feature and maybe could not be to hard to
implement.

"Pavel Minayev" <evilone@omen.ru> escreveu na mensagem news:a1hqag$1g8l$1@digitaldaemon.com...
> "Juarez Rudsatz" <juarez@correio.com> wrote in message news:a1hnec$1eap$1@digitaldaemon.com...
>
> >  I dont remember if this was already discussed, but I wanna write about
> > Parameters by Index versus Parameters by Name
>
> It was =)

Oh ! No !!!!!!!!!!
There are nothing new under the Sun !

>
> > S : Could be much more easy if I could call the funcions passing
> parameters
> > by name too. Consider the following examples :
> >
> > (1)
> >   s = substring(Source=old_str, Start = MIDDLE, Stop =
str_len(old_str));
>
> Not suitable since = is an operator in D, and thus Source=old_str is a legal expression.
>
> However, : could be used instead:
>
>     s = substring(Source: old_str, Start: MIDDLE, Stop: str_len(old_str));
>
> > 2 - The programmer don't will need search by function in source code to
> see
> > the "definition". The code will be more easy to write.
>
> There are usually help files for that. Besides, you have to know parameter names then, so you will still have to look at the declaration.
>
> > What you think about this ?
> > Comments, Sugestions, Negatives ?
>
> It could be added as an alternative to the base syntax. Sometimes - not very frequently though - it is useful. However, I wouldn't be glad to type in all the parameter names.
>
> Also, D allows to omit parameter names in prototypes. Not really a big problem, still...
>
>

Named parameters is a good idea, it may go into V2. -Walter

"Juarez Rudsatz" <juarez@correio.com> wrote in message news:a1hnec$1eap$1@digitaldaemon.com...
> D people :
>
>  I dont remember if this was already discussed, but I wanna write about
> Parameters by Index versus Parameters by Name
>
> The problem which I have when programing, is a confusion with parameter
list
> of a function. Supose the following functions ( dont pay attention to
sintax
> yet):
>
> char* substring(char* Source, int Start, Length) { }   (1)
> char* substring(char* Source, int From, To) { }
>
> char* replace(char* inString, Pattern, byPattern) { }  (2)
> char* replace(char* Pattern, byPattern, inString) { }
> char* replace(char* byPattern, Pattern, inString) { }
>
> The first case the problem is the two meanings of same name "substring".
The
> second problem is the confusion about order of parameters.
> When I am writing code, often I feel confused and need search the help for
> "function definition".
>
> S : Could be much more easy if I could call the funcions passing
parameters
> by name too. Consider the following examples :
>
> (1)
>   s = substring(Source=old_str, Start = MIDDLE, Stop = str_len(old_str));
>
> or
>
>  s = substring(old_str, MIDDLE, str_len(old_str) - MIDDLE);  // confusion
> ???
>
> (2)
>  r = replace(Pattern = 'C++' , byPattern = 'D', inString = 'C++
Programming
> Language');
>
> or
>
>  r = replace('C++ Programming Language' , 'C++' , 'D');
>
> Advantages :
>
> 1 - The order of parameters is not too important now. The definition of
> function can change with none or lesser impacts.
> 2 - The programmer don't will need search by function in source code to
see
> the "definition". The code will be more easy to write.
> 3 - Programmers will not change, accidentally, the order, doing a mistake.
> 3 - The code could be more readable.
> 4 - The in, out and inout will not be affected
> 5 - The overloading will work as is now.
>
> Disadvantages :
>
> 1 - The typing and code will grow.
> 2 - To change the parameters name will not be to easy as now, but they
will
> start have more significant names.
> 3 - The C programmers don't will like and will say : this is ugly.
> 4 - The matching parameter will have two algoritms increasing the
compiler.
>
> Problems :
>
> a)
> int somefunc(double base, int fator) {}
> int somefunc(int base, double fator) {}
>
> when I call the following example, the compiler will need to throw a
error.
> But It could know in semantic analysis time.
>
> x = somefunc(base = 10 , fator = 2);
>
> What you think about this ?
> Comments, Sugestions, Negatives ?
>
>
>