fbpx
Welcome, Guest
Username: Password: Remember me

TOPIC:

The X# Documentation Project - new topics last week 19 Feb 2018 08:27 #4049

  • wriedmann's Avatar

  • wriedmann

  • Topic Author


  • Posts: 2300
  • 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
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

    Please Log in or Create an account to join the conversation.

    The X# Documentation Project - new topics last week 19 Feb 2018 09:27 #4050

  • FFF's Avatar

  • FFF


  • Posts: 976
  • 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:
    CLASS z
    METHOD x(a AS STRING) AS INT32
    RETURN 1
    
    METHOD x(a AS STRING) AS STRING
    RETURN "1"
    END CLASS

    HTH
    Karl
    Regards
    Karl (X# 2.5b; Xide 1.25; W8.1/64 German)

    Please Log in or Create an account to join the conversation.

    The X# Documentation Project - new topics last week 19 Feb 2018 09:31 #4051

  • wriedmann's Avatar

  • wriedmann

  • Topic Author


  • Posts: 2300
  • Hi Karl,

    of course you are right. I will correct that today.

    Thank you very much!

    Wolfgang
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

    Please Log in or Create an account to join the conversation.

    The X# Documentation Project - new topics last week 19 Feb 2018 13:13 #4053

  • Chris's Avatar

  • Chris


  • Posts: 2039
  • 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 stackoverflow.com/questions/8808703/method-signature-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 docs.microsoft.com/en-us/dotnet/csharp/p...-and-structs/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
    XSharp Development Team
    chris(at)xsharp.eu

    Please Log in or Create an account to join the conversation.

    The X# Documentation Project - new topics last week 19 Feb 2018 13:47 #4054

  • wriedmann's Avatar

  • wriedmann

  • Topic Author


  • Posts: 2300
  • Hi Chris,

    thank you very much for your clarification! I will change the documentation topic as suggested.

    Wolfgang
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

    Please Log in or Create an account to join the conversation.

    The X# Documentation Project - new topics last week 19 Feb 2018 19:55 #4056

  • wriedmann's Avatar

  • wriedmann

  • Topic Author


  • Posts: 2300
  • 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
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

    Please Log in or Create an account to join the conversation.

    The X# Documentation Project - new topics last week 19 Feb 2018 23:07 #4057

  • FFF's Avatar

  • FFF


  • Posts: 976
  • 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:
    //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
    Regards
    Karl (X# 2.5b; Xide 1.25; W8.1/64 German)

    Please Log in or Create an account to join the conversation.

    The X# Documentation Project - new topics last week 20 Feb 2018 05:54 #4058

  • wriedmann's Avatar

  • wriedmann

  • Topic Author


  • Posts: 2300
  • 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:
    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
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

    Please Log in or Create an account to join the conversation.

    The X# Documentation Project - new topics last week 20 Feb 2018 10:02 #4059

  • FFF's Avatar

  • FFF


  • Posts: 976
  • 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
    Regards
    Karl (X# 2.5b; Xide 1.25; W8.1/64 German)

    Please Log in or Create an account to join the conversation.

    The X# Documentation Project - new topics last week 20 Feb 2018 10:38 #4060

  • wriedmann's Avatar

  • wriedmann

  • Topic Author


  • Posts: 2300
  • 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
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

    Please Log in or Create an account to join the conversation.

    The X# Documentation Project - new topics last week 20 Feb 2018 15:30 #4064

  • Chris's Avatar

  • Chris


  • Posts: 2039
  • Hi Karl,

    You use delegates when you need to call some code that is not known at compile time. For example you are creating a library with a function that does very heavy calculations and takes a lot of time to complete. Because of that, from time to time you want your library to send back some data (to the app that uses it) about its progress and maybe let the calling app decide if it wants to cancel the operation (random example that comes to mind, a windows update that takes too long time to complete and makes your system crawl and you cannot work, so you are MS and want to give some reliable info back to the user about the progress and allow him to cancel the %^%&#@ update).

    This can be nicely done with a delegate. You can define one as:
    DELEGATE LongProcessProgressReportDelegate(oInfo AS ProgressInfo) AS LOGIC

    and then simply use (simplified code)
    CLASS ToolInLibrary
    EXPORT oProgreesDel AS LongProcessProgressReportDelegate
    
    METHOD HeavyCalculations() AS VOID
    // ...
    IF MuchTimePassedSoMustReportBack
      LOCAL somedata AS ProgressInfo
      // ...
      somedata:TimeRemaining := 17 years
      IF .not. SELF:oProgreesDel:Invoke(somedata)
        // cancel operation
      ELSE
    ENDIF

    Your library code knows nothing about the actual code that will be actually called at runtime, it only knows (and enforces) that the method that will be called at runtime must and will have those specific parameters and return type that you specified in the delegate.

    The calling code, the one which uses your library, would then need to implement a method with that signature (you know what I mean :)):
    CLASS TheRealApp
      METHOD DoSomeWork() AS VOID
        LOCAL oTool AS ToolInLibrary
        // ....
        oTool:oProgreesDel := ProgressCallbackMethod
        oTool:Heavycalculation()
        // wait and wait and wait...
      RETURN
    
      METHOD ProgressCallbackMethod(oInfo AS ProgressInfo) AS LOGIC
        SELF:DisplayProgressInfoToUser(oInfo)
        IF UserIsCompletelyAngryWithDelay()
          RETURN FALSE
        ENDIF
      RETURN TRUE
    END CLASS

    This will work nicely at runtime, your library will be giving updates to the main app in a type safe and fast manner. Instead of invoking a delegate, you could possibly use just Send() to call a method in the calling code, we had that in VO for decades you will say. Yes, but this is not type safe, there is no parameter and return type cheeking at compile time, so you can accidentally easily use wrong params in the ProgressCallbackMethod() callback, which will throw an error at runtime only. With the delegate system, all is checked at compile time and the calls are guaranteed to be made correctly.

    Another way to implement the above scenario, would have been to declare an interface IProgressReport with a method member named ProgressCallbackMethod() and require the calling code to implement this interface, but this is probably overkill, to request such a thing just for a single callback method.

    Btw, .Net has brought this concept a step further, by introducing EVENTs, which are basically a warper around delegates, but their mechanism is the same and they require the exact same delegate type. In the sample above, you can replace the line
    EXPORT oProgreesDel AS LongProcessProgressReportDelegate

    with
    EXPORT EVENT ProgreesDel AS LongProcessProgressReportDelegate

    and it is the same thing more or less. So usually you are using delegates with events (like all those events in the Form class, which all use the "EventHandler" DELEGATE), but there are cases where you still need to use a delegate in its simple form, specified in a LOCAL or class var, for example when needing to provide a callback to a Win32 API function. A delegate instantiated and holded in a LOCAL also has the advantage that it can be passed around in your code just like any other variable and instantiated by various places in your code. But admittedly, there are very few cases where you would really need to do that.

    Anyway, again this post got a lot larger than planned, hope it clarifies things about delegates a bit, instead of making them look even weirder :)

    Chris
    XSharp Development Team
    chris(at)xsharp.eu

    Please Log in or Create an account to join the conversation.

    The X# Documentation Project - new topics last week 20 Feb 2018 20:42 #4069

  • wriedmann's Avatar

  • wriedmann

  • Topic Author


  • Posts: 2300
  • Hi Chris, hi Karl,

    I have now added a link to this message to the Delegase topic in the wiki. This IMHO the best option.

    Wolfgang
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

    Please Log in or Create an account to join the conversation.