Page 7 of 8
The X# Documentation Project - new topics last week
Posted: Mon Feb 19, 2018 7:27 am
by wriedmann
Hi,
last week a few new topics have been added. As usual, comments and corrections are welcome!
The Preprocessor
Literals
Delegates
Naming conflicts
CreateInstance() and Libraries
Wolfgang
The X# Documentation Project - new topics last week
Posted: Mon Feb 19, 2018 8:27 am
by FFF
Hi Wolfgang,
great, to see the progress!
One thing i just saw in Delegates:
"...a signature is the number and types of parameters and the type of return value)."
AFAIK, the return type is NOT part of the signature, e.g., the compiler will not accept:
Code: Select all
CLASS z
METHOD x(a AS STRING) AS INT32
RETURN 1
METHOD x(a AS STRING) AS STRING
RETURN "1"
END CLASS
HTH
Karl
The X# Documentation Project - new topics last week
Posted: Mon Feb 19, 2018 8:31 am
by wriedmann
Hi Karl,
of course you are right. I will correct that today.
Thank you very much!
Wolfgang
The X# Documentation Project - new topics last week
Posted: Mon Feb 19, 2018 12:13 pm
by Chris
Guys,
Looks like there are conflicting views on what is a signature, depending on the context the return type is part of it or it isn't. For example, from
https://stackoverflow.com/questions/880 ... in-c-sharp :
There are two definitions of method signature. The C# language definition does not include the return type, and uses the signature of the method to determine whether two overloads are allowed. Two methods with the same signature are not allowed in a type. Since C# does not consider the return type to be a part of the signature, C# does not allow two methods that differ only in return type to be declared in the same type.
The CLR, however, does include the return type in the signature. The CLR allows for two methods to be in the same type that differ only in return type.
I think I also like this definition form
https://docs.microsoft.com/en-us/dotnet ... ts/methods :
A return type of a method is not part of the signature of the method for the purposes of method overloading. However, it is part of the signature of the method when determining the compatibility between a delegate and the method that it points to.
So, in short, maybe we shouldn't say that a delegate much have the same signature with the method, but in order to avoid ambiguity, let's say that the delegate must have the same parameters and return type as the method, which is more clear. A shame, since "same signature" is much easier to say
Chris
The X# Documentation Project - new topics last week
Posted: Mon Feb 19, 2018 12:47 pm
by wriedmann
Hi Chris,
thank you very much for your clarification! I will change the documentation topic as suggested.
Wolfgang
The X# Documentation Project - new topics last week
Posted: Mon Feb 19, 2018 6:55 pm
by wriedmann
Hi Chris, hi Karl,
I have now updated the topic:
https://docs.xsharp.it/doku.php?id=delegates
I hope this is now ok.
IMHO contributions like yours are very precious because they make the content of the wiki better.
Wolfgang
The X# Documentation Project - new topics last week
Posted: Mon Feb 19, 2018 10:07 pm
by FFF
Wolfgang,
yes, probably better. Although: following your net-information link one finds:
A delegate is independent of the type of method that it references. The signature of the method and the delegate should match.
Notice the "should"...
Sloppy use of language causes much unnecessary pain
And, we should try to produce "striking" samples for coding concepts.
See the sample, also from above link:
Code: Select all
//A class method
public void add(int n1, int n2)
{ MessageBox.Show("Adding numbers : " + (n1 + n2).ToString()); }
//invocaton
Form1 form1 = new Form1();
delegateMethod addNumbers = new delegateMethod(form1.add);
addNumbers(50, 10);
doesn't help me much to understand, why i should use the concept at all..:dry:
Karl
The X# Documentation Project - new topics last week
Posted: Tue Feb 20, 2018 4:54 am
by wriedmann
Hi Karl,
A delegate is independent of the type of method that it references. The signature of the method and the delegate should match.
Notice the "should"...
I have no problem to say:
must. If you try to set the delegate variable to a method that does not match, the compiler states clearly:
Code: Select all
error XS0123: No overload for 'Execute3' matches delegate 'IntDelegate'
About better samples: I will try to add a sample.
But like in VO we don't used function pointers when not needed by an external API (we had codeblocks - much better), the .NET languages don't need delegates when not required by an external API (in .NET we have lambdas and commands - much better than a delegate).
Therefore I will add a delegate sample from one of my migrated VO libraries - where a Windows API function requires a callback function and in X# a delegate is needed (the Xporter replaces callbacks by delegates).
Wolfgang
The X# Documentation Project - new topics last week
Posted: Tue Feb 20, 2018 9:02 am
by FFF
Good morning Wolfgang!
Fine, thx.
FTR, i didn't want to question "you" or your samples, i admire very much your commitment to promote this project!
My critique points at all the self-called "experts" which post sloppy lectured content...
HAND
Karl
The X# Documentation Project - new topics last week
Posted: Tue Feb 20, 2018 9:38 am
by wriedmann
Hi Karl,
no problem at all! I'm very, very far from being perfect, or even from knowing the X# language or the .NET framework very well, so every correction of my text or my samples is welcome.
I had some errors, and Chris gave me several corrections or enhancements, so many of my topics contain informations from Chris or other people.
Only joined forces can help to make and keep the wiki a useful information source (where the "keep" may be much harder than "make").
Wolfgang