fbpx
Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1
  • 2

TOPIC:

Some thoughts about new X# functionality 03 May 2021 22:23 #18285

  • ic2's Avatar

  • ic2

  • Topic Author


  • Posts: 938
  • I've watched Unboxing X# 2.8, thank you again for this presentation.

    This having said, I often get the impression that quite some IT developments have come to a kind of standstill.

    For example, end last year I replaced my Pc after nearly 7,5 years. I've never used a Pc that long and the only reason to get a new one was that I thought I was probably close to a system failure due to the number of working hours.

    Although the new Pc really has some nice specs, like a i9 and a NVMe M.2 PCIe SSD and more, the best I can say about it is that it gives the impression that some things seem to work a little bit faster. But no real gains in compile- or unzip times like I had on earlier Pc replacements.

    Same for language additions. X# is getting all the bells and whistles of C#, thanks to Rosalyn and the highly skilled development team. However, for most changes I wonder if they are really useful. E.g. I learned we can now write:

    METHOD MyToString() AS STRING =>SELF:Left()
    instead of
    METHOD MyToString() AS STRING ; RETURN SELF:Left()

    Robert already mentioned that the 2nd method is also 1 liner and only a few characters less code.

    When I see this I actually immediately forget it as I would have to lookup what to do again to apply this. Even worse: when I would later coma across someone's code written with => instead of the clear code of the "old fashioned" way, I would most likely wonder what this means. I've seen that more than once in C# as well, code I absolutely don't understand because the programmer used some "clever" new option with @#$%":{} in it and there's no way to even lookup what it means. How do you search for the meaning of a couple of special characters? Searching for the keyword RETURN, in case that is unfamiliar to you, is a lot easier.

    What I am afraid of is that a lot of effort is put in adding functionality which doesn't really change the use of the environment and hence a lot of people don't even bother to memorize it. I haven't found much in the last few years in C# nor Visual Studio which was really improving my productivity so I often don't even read the What's New after an update. Even worse, when I did csc /? in C:\Windows\Microsoft.NET\Framework\v4.0.30319, apparently the way to find out which C# version I have, it said 4.8.4084.0, from 11 years back. But further study learned me that it's updated with VS and/or .Net so it should be something like 7.3. Whatever....

    I've seen that happening with Windows 10 as well. The last few years, not much of any interest was added to W10. This means that when there actually is, by exception, something interesting, most people don't know about it. I consider Clipboard history (enabling you to select values copied/cut before the last one) as a very useful and tome saving addition. But I've asked quite a few people recently (including a few IT pro's) and nobody knew about. Default it's even turned off! support.microsoft.com/en-us/windows/clip...8d-97ea-fe46ddf338c6 in case you didn't know either ;)

    Finally, I am in no way trying to criticize the work and the choices of the development team; Robert once mentioned that quite a few these language additions are easy to implement using Rosalyn. If Microsoft would put more effort in productivity instead of adding more language "features" than the average programmer is able to recall (and hence: use), that would make X# benefit too. I think when I would move to X# the much better checks of the X# compiler versus that of VO would make my code less error prone. But so far I haven't seen one single language element in X# (or C#) from which I thought "I wish I had that in VO". The opposite I have multiple however (more for C# than for X# of course as X# can use most of the VO dialect) ....

    Dick

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

    Some thoughts about new X# functionality 04 May 2021 00:47 #18289

  • Chris's Avatar

  • Chris


  • Posts: 2495
  • Hi Dick,

    Indeed, Robert mentioned that the => expression on entities was just a very tiny improvement that was extremely easy to implement, so why not? It was not meant to be a very important addition to the language. What is IMO very useful though is local functions (implemented in the latest build), I've been missing them a lot since my days of writing pascal code.

    Regarding X# features in general, if you do not need the extra stuff it has over VO, then it is fine of course. But for other people, those are extremely important improvements, helping to write faster, a lot more robust and safe code. Let's bring this the other way around, is there any feature you are missing in VO and you would like to see it implemented in X# or another language?
    XSharp Development Team
    chris(at)xsharp.eu

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

    Some thoughts about new X# functionality 04 May 2021 10:06 #18292

  • leon-ts's Avatar

  • leon-ts


  • Posts: 136
  • Hi,

    ic2 wrote: But so far I haven't seen one single language element in X# (or C#) from which I thought "I wish I had that in VO".


    What about SWITCH? :)

    Best regards,
    Leonid

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

    Some thoughts about new X# functionality 04 May 2021 12:51 #18296

  • ic2's Avatar

  • ic2

  • Topic Author


  • Posts: 938
  • Hello Leonid,

    leon-ts wrote: What about SWITCH? :)


    SWITCH is indeed a great sample of something which only has disadvantages compared to DO CASE.

    The first time I used it (from some borrowed code) it took me a quite a while to find out that Switch simply continues to go through the conditions except when you type break in every line. If I want to have multiple conditions tested, a couple of IF..ENDIF's makes my code flow a lot more readable. The VO DO CASE is also a lot more readable than the Switch statement.

    I've seen several explanations of Switch versus Case but I've never seen a use of Switch which is in anyway more usable than DO CASE or IF ENDIF in VO, And the samples are always more code lines.

    Dick

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

    Last edit: by ic2.

    Some thoughts about new X# functionality 04 May 2021 13:36 #18297

  • ic2's Avatar

  • ic2

  • Topic Author


  • Posts: 938
  • Hello Chris,

    Chris wrote: What is IMO very useful though is local functions (implemented in the latest build), I've been missing them a lot since my days of writing pascal code.


    I re-watched that part about Local functions (from 22:50). Unfortunately I fail to see an advantage above a normal VO function, or it must be that you can use the variables of the calling function. Robert already called this tricky and I would certainly never apply that, a.o. because when looking into the function I am sure I would wonder where the variable (i in the presentation) is coming from.

    Chris wrote: Let's bring this the other way around, is there any feature you are missing in VO and you would like to see it implemented in X# or another language?


    That's a very intriguing question! There are certainly a few things missing in VO but some are present in X#/C#/VS, not all:

    1 I like CodeLens a lot, but this is not working in X#. Is that something which can be implemented? In VO I can of course do a global search on the function name but it often results in more hits than just the places where it is called and it costs a lot more time and effort.
    2 In VS I have more info about variables (e.g. VO stops showing content after 64 array elements or a certain string length) while in VS I can see everything and potentially allows me more options to change the process. But much of this doesn't yet work in X#, like Edit and Continue. Or does it? And it's often impossible to evaluate an expression because you have to guess how the expression would look like in C# including the right case.
    3 What I also like in VS is that using Step in the Debugger, you can see how much time was elapsed during the execution of a line. This once helped me finding the cause for a major delay which I could eliminate by using a different class (to get EXIF info of a graphic file).. But this works in X#/C#.

    I can't remember language elements I could use (but nor present in VO) but when I think of 1 the next few weeks I will post it. A thing which would save me a lot of time, not present in VO nor VS, would be a way to create strings with multiple languages straight from the code. Think of something like this: you are assigning a variable cVar:="This is a test" and you click to get a kind of popup showing you the machine translation of this string in some languages you have chosen to support, and shows some near similar translations which you could choose instead or show when it was already used (and translated earlier). Then you would edit the translations, if needed, and VS would take care of creating the results in a resource or something and take care of accessing the right string during program execution.

    I support multiple languages and I use a fairly efficient program to create translations in a database, but a native support would be much better.

    I will leave out all the things I wish VS/X#/C# has not which is in VO :)

    Dick

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

    Some thoughts about new X# functionality 04 May 2021 15:04 #18299

  • robert's Avatar

  • robert


  • Posts: 2174
  • Dick,

    ic2 wrote: Hello Leonid,

    SWITCH is indeed a great sample of something which only has disadvantages compared to DO CASE.

    The first time I used it (from some borrowed code) it took me a quite a while to find out that Switch simply continues to go through the conditions except when you type break in every line. If I want to have multiple conditions tested, a couple of IF..ENDIF's makes my code flow a lot more readable. The VO DO CASE is also a lot more readable than the Switch statement.

    I've seen several explanations of Switch versus Case but I've never seen a use of Switch which is in anyway more usable than DO CASE or IF ENDIF in VO, And the samples are always more code lines.


    SWITCH in X# does NOT need break statements.
    And the compiler will detect duplicate CASE values (which often happen when copying code).

    Robert
    XSharp Development Team
    The Netherlands

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

    Some thoughts about new X# functionality 04 May 2021 15:08 #18300

  • ic2's Avatar

  • ic2

  • Topic Author


  • Posts: 938
  • Hello Robert,

    robert wrote: Dick,
    SWITCH in X# does NOT need break statements.
    And the compiler will detect duplicate CASE values (which often happen when copying code).


    The first I didn't know, it certainly makes more sense than the C# way of doing it.
    The 2nd I once knew but I had forgotten it as I haven't had problems with duplicates values ever, but ok, Switch could be an advantage.

    Dick

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

    Some thoughts about new X# functionality 04 May 2021 15:20 #18302

  • leon-ts's Avatar

  • leon-ts


  • Posts: 136
  • Hello Dick,

    If you need to perform certain actions for different values ​​of a variable, then I cannot think of a single reason why IF/CASE statements are more efficient than the SWITCH statement, both for reading the code and for the speed of its execution.

    Comparison example IF/CASE/SWITCH:
    LOCAL nVal AS INT
     // .... some code
                                 DO CASE                         SWITCH nVal
    IF nVal == 1                 CASE nVal == 1                  CASE 1
    // ........................  do something  .............................
    ELSEIF nVal == 2             CASE nVal == 2                  CASE 2
    // ........................  do something  .............................
    ELSEIF nVal == 3             CASE nVal == 3                  CASE 3
    // ........................  do something  .............................
    ELSE                         OTHERWISE                       OTHERWISE
    // ........................  default  ..................................
    ENDIF                        END CASE                        END SWITCH

    As you can see from the example, for IF/CASE statements, you need to write more code and repeat the condition each time. This is one of the serious problems in this task, since every time you have to write a complete condition and in this case it is easy to make a mistake. For example, write the wrong variable in the condition or even the whole condition. In addition, during the subsequent verification of such a code, it is necessary to carefully read and check the condition in each line of this group of operators. In this case, in SWITCH you need to specify only the expected value of the variable, which is easier both for reading the code and for executing it. As far as I know, a special code with a jump table is generated for the SWITCH statement, which makes it possible to execute such code faster than if it were a group of IF/CASE statements.

    Thus, the SWITCH statement requires less coding, is less error prone, easier and cleaner to read, and executes faster. How does the IF/CASE for this type of task can be better? This is a rhetorical question.

    P.S. As far as I know, in VO, the DO CASE statement is transformed into a set of IF/ELSEIF conditions during compilation and, as a result, generates the same code.

    Best regards,
    Leonid

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

    Last edit: by leon-ts.

    Some thoughts about new X# functionality 04 May 2021 15:40 #18303

  • robert's Avatar

  • robert


  • Posts: 2174
  • Leonid,

    leon-ts wrote: P.S. As far as I know, in VO, the DO CASE statement is transformed into a set of IF/ELSEIF conditions during compilation and, as a result, generates the same code.


    You are right:

    Both in VO and in X# the DO CASE statement and the IF ELSEIF statements are compiled into the same construct. Each CASE and each ELSEIF become an ELSE IF . The last ELSE and the OTHERWISE become ELSE

    You can see that in our code:

    CASE Blocks generate an IF statement:
    github.com/X-Sharp/XSharpDev/blob/main/X...rmationCore.cs#L6361

    ELSEIF generates an IF statement too:

    github.com/X-Sharp/XSharpDev/blob/main/X...rmationCore.cs#L6318


    Robert
    XSharp Development Team
    The Netherlands

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

    Last edit: by robert.

    Some thoughts about new X# functionality 04 May 2021 17:02 #18307

  • ic2's Avatar

  • ic2

  • Topic Author


  • Posts: 938
  • Hello Leonid,

    leon-ts wrote: Thus, the SWITCH statement requires less coding, is less error prone, easier and cleaner to read, and executes faster. How does the IF/CASE for this type of task can be better? This is a rhetorical question.


    Thanks for taking the time to explain the difference and advantages of Switch. I understand and appreciate after the explanation that Switch is less error prone, it saves re-typing the condition and I take your word for it that it's faster. But if it's easier and cleaner to read is a matter of taste. I think it's the opposite.

    If I check a condition and directly above the condition I read CASE nVal == 2 I think that is a lot easier than when I read CASE 2. What 2? I have to go to the beginning of the statement (which can be very long) to mentally combine nVal and the value in the CASE line. Not to mention the DO...CASE statement where more than 1 condition is tested, this can't be done with Switch. For that reason I'm inclined to use DO CASE everywhere but I may reconsider that.

    I want to be able to have as much information in 1 place as possible. Another issue of .Net is that a method no longer needs to have a class written (although fortunately X# does make it possible). Especially when I have a methods of a few classes in 1 .prg, I will have to scroll up until I find the CLASS statement. That's a step backward too. In C# it's even worse because there's no ENDIF, ENDDO etc. You have to click on a ; and hope you have the one closing the statement you are working on :angry:

    Dick

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

    Last edit: by ic2.

    Some thoughts about new X# functionality 04 May 2021 17:15 #18308

  • wriedmann's Avatar

  • wriedmann


  • Posts: 2590
  • Hi Dick,
    please let me add something to the difference between do case and switch:
    when it is possible to use "switch", you should use that because it is faster, less code to type and you have more compile time checks.
    But in my own code, I'm able to replace only very few "do case" with "switch" statements, so it largely depends on you own coding style if the "switch" statement has advantages for you.
    Wolfgang
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

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

    Some thoughts about new X# functionality 04 May 2021 23:28 #18310

  • ic2's Avatar

  • ic2

  • Topic Author


  • Posts: 938
  • Hello Wolfgang,

    wriedmann wrote: when it is possible to use "switch", you should use that because it is faster, less code to type and you have more compile time checks.


    Technically it's a good advise. But as written above, I prefer the clearer CASE statements where I don't have to lookup elsewhere in the code what I am checking in a Switch statement.

    I have to add that almost everything I wrote new in X# is basically done the same way as I would do it in VO. The chance is larger that when I am programming and need a DO..CASE which can also be a Switch that I wouldn't even think that I could use Switch and have started the DO CASE without thinking. Even though I read the WhatsNew and carefully watch the on line sessions and make notes, I hardly have the idea that one of the new language elements is really worth remembering and hence I won't use it. Basically what I explained when I started this subject. I think that unless you directly see an advantage into something not available in VO, or search for something you can't easily realize in the VO way (e.g. in my C# photo program I use a listbox which contains the thumbnail images which I wouldn't know directly how to realize in VO), then it's a kind of routine to solve it the (VO) way one is familiar with.

    Nevertheless I will keep your remarks in mind and I think I am going to use a Switch somewhere where I can time the difference.

    Dick

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

    Last edit: by ic2.

    Some thoughts about new X# functionality 05 May 2021 05:48 #18313

  • wriedmann's Avatar

  • wriedmann


  • Posts: 2590
  • Hi Dick,
    remembering my "mental" migration from Clipper to VO, first I have worked in VO as I worked in Clipper, adding slowly new VO language constructs.
    In my "mental" migration to X# I have done the same thing, and now my code that I write in X# is very different from my VO code as it uses interfaces (really a great thing), collections and local classes, but never arrays as it is written in Core mode. It is a long way the change the mode to think programming, and I'm pretty sure my programming style will evolve also the next years.
    There are some constructs I don't use like the "using" statement, but maybe I will adopt them sometimes in the future. For sure, there are some addition to the language where I'm asking myself who may be using them, but maybe there are people liking them, and since the underlying Roslyn platform permits them - why not.
    Wolfgang
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

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

    Some thoughts about new X# functionality 05 May 2021 09:33 #18314

  • SHirsch's Avatar

  • SHirsch


  • Posts: 220
  • Hi Wolfgang,

    I like the "using" statement very much. The new introduced "USING VAR ..." makes it even easier to use. You don't have to care about disposing the object if it goes out of scope. In normal cases no problem. But what if an exception is thrown. Than you have to write much extra code.
    Without using (often seen in sample from the internet an criticized):
    TRY 
      VAR d := SomeDisposeableClass{}
      ... some code...
      d:Dispose()
    CATCH 
    END TRY
    What happens to the native resources if an exception is thrown? Dispose will never be called. Maybe you build a memory leak (depending on the class).

    Corrected without 'using' would be:
    LOCAL d AS SomeDisposeableClass
    TRY 
      d := SomeDisposeableClass{}
      ... some code...
    CATCH 
    FINALLY
      d:Dispose()
    END TRY
    'FINALLY' is always called. So d will always be disposed. But as you see you have to declare d outside the 'TRY' block otherwise it is only visible inside TRY and not in FINALLY.

    Better would be (IMHO):
    TRY 
      USING VAR d := SomeDisposeableClass{}
      ... some code...
      //d:Dispose() //this is called automatically when d goes out of scope, even if an exception is thrown
    CATCH 
    END TRY

    So one word more but high impact.
    @Robert: please correct me if I am wrong.

    Stefan

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

    Some thoughts about new X# functionality 05 May 2021 09:59 #18315

  • SHirsch's Avatar

  • SHirsch


  • Posts: 220
  • Hi Dick,

    I have to go to the beginning of the statement (which can be very long) to mentally combine nVal and the value in the CASE line.


    Not really about switch an case but here my thoughts about your statement:

    We have the very same problem in old code. When I have to understand such code to fix some bugs or enhance something. The first thing is refactoring. Extract all code from the CASE to a separated method. Then understand what is does. Give it a describing name. So the CASE is easy to read. Then I often see that half of the code inside the different CASE statements is copy/paste. So next thing is extracting duplicated code to separeted methods. There I often find that in some CASE parts an error was fixed but in the duplicated code it was not. So I fixed some bugs that have never been reported. Or I found code that has never been called.
    After digging deeper in the class I see the very DO CASE statement in serveral methods. So next step of refactoring, building a class for each CASE. In VO I create a base class in X# an interface and then inherit from it. What to do then depends on use case. Sometimes the needed class will be constructed in corresponing CASE or it is constructed in Init of the calling class.

    Now the code is easy to read and due to the separated class easier to understand and enhanceable for new CASES.

    Stefan

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

    Some thoughts about new X# functionality 05 May 2021 11:11 #18317

  • ic2's Avatar

  • ic2

  • Topic Author


  • Posts: 938
  • Hello Stefan,

    SHirsch wrote: So next step of refactoring, building a class for each CASE. In VO I create a base class in X# an interface and then inherit from it.


    It sounds like an interesting project but I find it difficult to imagine how to make a class of a DO CASE and inherit from it and what the advantage is.

    Maybe this makes a nice presentation for you if there is ever going to be an X# conference again.

    Dick

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

    Some thoughts about new X# functionality 05 May 2021 11:30 #18319

  • ic2's Avatar

  • ic2

  • Topic Author


  • Posts: 938
  • Hello Wolfgang,

    wriedmann wrote: I have done the same thing, and now my code that I write in X# is very different from my VO code as it uses interfaces (really a great thing), collections and local classes,


    To comment on these 3 addition you mention:
    Collections: indeed, in VO I would use an array but something like as List is much more readable and easier to understand.
    Local classes No idea what it is. Something like nested classes? Or do you mean local functions? I saw these in the presentation but I see no advantage or difference with the regular functions as used in VO.
    Interfaces There goes your saving you just achieved with typing a bit less in the Switch statement :P. As far as I have seen, interfaces mainly is extra typing of the same code to get some "contract" about what arguments or return types you methods should have. No idea why you need extra code for that. Only advantage I can think of is that you can implement multiple inheritance. I had to use an interface once, when implementing WCF. The web part is C# and the Pc part is X#. These didn't communicate with each other. I created an interface which solved the communication issue but I'd rather would have done without.

    Dick

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

    Some thoughts about new X# functionality 05 May 2021 11:37 #18320

  • SHirsch's Avatar

  • SHirsch


  • Posts: 220
  • Hi Dick,

    just a short sample:
    Old code
    METHOD DoStuff1() AS VOID
    DO CASE 
    CASE n == 1
       ... LARGE CODE PART 1
    CASE n == 2
      ... LARGE CODE PART 2
    CASE n == 3
      ... LARGE CODE PART 3
    END CASE
    RETURN
    
    METHOD DoStuff2() AS VOID
    DO CASE 
    CASE n == 1
       ... SOME CODE PART 1
    CASE n == 2
      ... SOME CODE PART 2
    CASE n == 3
      ... SOME CODE PART 3
    END CASE
    RETURN
    
    METHOD DoStuff3() AS VOID
    DO CASE 
    CASE n == 1
       ... SMALL CODE PART 1
    CASE n == 2
      ... SMALL CODE PART 2
    CASE n == 3
      ... SMALL CODE PART 3
    END CASE
    RETURN

    The new BaseClass (or Interface):
    CLASS BaseClass
    METHOD Large() AS VOID 
    RETURN
    METHOD Some() AS VOID 
    RETURN
    METHOD Small() AS VOID 
    RETURN

    Implementation for the 3 CASES
    CLASS CodePart1 INHERIT BaseClass
    METHOD Large() AS VOID
    ... LARGE CODE PART 1
    RETURN
    METHOD Some() AS VOID
    ... SOME CODE PART 1
    RETURN
    METHOD Small() AS VOID
    ... SMALL CODE PART 1
    RETURN
    
    CLASS CodePart2 INHERIT BaseClass
    METHOD Large() AS VOID
    ... LARGE CODE PART 2
    RETURN
    METHOD Some() AS VOID
    ... SOME CODE PART 2
    RETURN
    METHOD Small() AS VOID
    ... SMALL CODE PART 2
    RETURN
    
    CLASS CodePart3 INHERIT BaseClass
    METHOD Large() AS VOID
    ... LARGE CODE PART 3
    RETURN
    METHOD Some() AS VOID
    ... SOME CODE PART 3
    RETURN
    METHOD Small() AS VOID
    ... SMALL CODE PART 3
    RETURN

    And now your the refactored:
    METHOD GetCodeClass(n AS INT) AS BaseClass
    LOCAL o AS BaseClass
    DO CASE 
    CASE n == 1
       o := CodePart1{}
    CASE n == 2
      o := CodePart2{]
    CASE n == 3
      o := CodePart3{}
    END CASE
    RETURN o
    
    METHOD DoStuff1() AS VOID
    LOCAL o AS BaseClass
    o := SELF:GetCodeClass()
    o:Large()
    RETURN
    
    METHOD DoStuff2() AS VOID
    LOCAL o AS BaseClass
    o := SELF:GetCodeClass()
    o:Some()
    RETURN
    
    METHOD DoStuff3() AS VOID
    LOCAL o AS BaseClass
    o := SELF:GetCodeClass()
    o:Small()
    RETURN

    Maybe this gives an impression what I meant.
    Now it is easy to add another CLASS without changing DoStuffX methods. Just create the class, enhance GetCodeClass and that's it.
    Better readable, debugable, reusable, enhanceable.
    I know it is not everywhere possible but in our programs there were quite a few places where this was a very good approach.

    Stefan

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

    Some thoughts about new X# functionality 05 May 2021 11:45 #18322

  • wriedmann's Avatar

  • wriedmann


  • Posts: 2590
  • Hi Stefan,
    thank you very much for your comments about the "using" statement.
    Initially I don't used the "var" statement because XIDE had no support for it, and since I'm used to clean up my objects also in VO and after an "end try" ("end sequence" in VO code).
    But maybe I habe to rethink on this as it would save code (normally I don't declare variables in the middle of a function/method to have more readable code: all variable declarations in the start of the method).
    Wolfgang
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

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

    Some thoughts about new X# functionality 05 May 2021 11:53 #18324

  • wriedmann's Avatar

  • wriedmann


  • Posts: 2590
  • Hi Dick,
    the .NET interface has a very large advantage: you can declare some common methods/properties.
    A sample:
    I have a processing class that is called both from a Windows service and a WPF application.
    To process exceptions, progress messages and so forth, they call a method in the owner.
    So I can define an interface:
    interface IProcessingOwner
    method Progress( cText as string ) as void
    method ProcessException( oEx as Exception, cSuppData as string ) as void
    end interface
    and use that instead of the real class in my processing class:
    class Processing
    protect _oOwner as IProcessungOwner
    constructor( oOwner as IProcessingOwner )
    return
    .....
    end class
    And both my Windows service and my WPF application can implement this interface and pass themselves to the processing class.
    Wolfgang
    Wolfgang Riedmann
    Meran, South Tyrol, Italy

    www.riedmann.it - docs.xsharp.it

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

    • Page:
    • 1
    • 2