1

Topic: Explain about pattern matching in C#

In new versions of language entered the expanded operator switch, called it "pattern matching", and advertize approximately so: static string M (Person person) {switch (person) {case Professor p: return $ "Dr. {p. LastName}"; case Studen s: return $ "{s. FirstName} {s. LastName} ({s. Level})"; default: return $ "{person. FirstName} {person. LastName}";}} (it is taken from here) the Question the first: in what the basic novelty which deserves the special term "pattern matching", after all it could be done and earlier, using is/as and if/else though is more bulky? That is, it is simply syntactic overhead projector sugar? A question of the second: what for it generally is necessary in OOP-language? I understand that now   aside , but after all a basis all the same remains to OOP. From my point of view, in style of OOP it was necessary to make somehow so: abstract class Person {public string FirstName {get; set;} public string LastName {get; set;} public virtual string GetDisplayString () {return $ "{FirstName} {LastName}";}} class Professor: Person {public override string GetDisplayString () {return $ "Dr. {LastName}";}} class Student: Person {public int Level {get; set;} public override string GetDisplayString () {return $ "{FirstName} {LastName} ({Level})";}}... static string M (Person person) {return person. GetDisplayString ();} Here and modularity (it is possible to add separately classes), and convenience of support of many choice points (branching implicitly carries out the compiler). A new method it is banal provokes to write the bad code, moreover and with the big convenience

2

Re: Explain about pattern matching in C#

Hello, dmitry_npi, you wrote: _> the Question the first: in what the basic novelty which deserves the special term "pattern matching", after all it could be done and earlier, using is/as and if/else though is more bulky? _> that is, it is simply syntactic overhead projector sugar? By and large all C# is syntactic sugar over ILASM. _> From my point of view, in style of OOP it was necessary to make somehow so: _> abstract class Person _> {_> public string FirstName {get; set;} _> public string LastName {get; set;} _> public virtual string GetDisplayString () _> {_> return $ "{FirstName} {LastName}"; _>} _>} And if Person associates are inaccessible to modification?

3

Re: Explain about pattern matching in C#

Hello, Night Looking, you wrote: NANOSECOND> And if Person associates are inaccessible to modification? All the same, the logician of distinction of types of objects should be separated from logic of formatting of a line. For example, to construct parallel hierarchy PersonFormatter, where to carry out formatting, and distinction of types to hide in factory of these . Yes, I understand that is bulky. No, I not .

4

Re: Explain about pattern matching in C#

Hello, dmitry_npi, you wrote: _> All the same, the logician of distinction of types of objects should be separated from logic of formatting of a line. For example, to construct parallel hierarchy PersonFormatter, where to carry out formatting, and distinction of types to hide in factory of these . _> Yes, I understand that is bulky. No, I not . Here perfectly approach extension methods.... <<RSDN@Home 1.3.110 alpha 5 rev. 62>>

5

Re: Explain about pattern matching in C#

Hello, _Raz _, you wrote: _R _> Hello, dmitry_npi, you wrote: _>> All the same, the logician of distinction of types of objects should be separated from logic of formatting of a line. For example, to construct parallel hierarchy PersonFormatter, where to carry out formatting, and distinction of types to hide in factory of these . _>> Yes, I understand that is bulky. No, I not . _R _> Here perfectly approach extension methods. They are not polymorphic, therefore type testing all the same remains

6

Re: Explain about pattern matching in C#

Hello, Jack128, you wrote: J> They are not polymorphic, therefore type testing all the same remains the Code: using System; namespace ConsoleApp2 {internal class Person {} internal class Professor: Person {} internal class Student: Person {} internal static class Ext {internal static string GetDisplayString (this Person p) {return p. GetType ().Name;} internal static string GetDisplayString (this Professor p) {return p. GetType ().Name;} internal static string GetDisplayString (this Student p) {return p. GetType ().Name;}} internal static class Program {private static void Main () {Console. WriteLine (new Person ().GetDisplayString ()); Console. WriteLine (new Student ().GetDisplayString ()); Console. WriteLine (new Professor ().GetDisplayString ()); Console. ReadKey ();}}} the Output: Person Student Professor... <<RSDN@Home 1.3.110 alpha 5 rev. 62>>

7

Re: Explain about pattern matching in C#

Hello, _Raz _, you wrote: _R _> Hello, Jack128, you wrote: J>> They are not polymorphic, therefore type testing all the same remains _R _> the Code: _R _> _R _> using System; _R _> namespace ConsoleApp2 _R _> {_R _> internal class Person _R _> {_R _>} _R _> internal class Professor: Person _R _> {_R _>} _R _> internal class Student: Person _R _> {_R _>} _R _> internal static class Ext _R _> {_R _> internal static string GetDisplayString (this Person p) _R _> {_R _> return p. GetType ().Name; _R _>} _R _> internal static string GetDisplayString (this Professor p) _R _> {_R _> return p. GetType ().Name; _R _>} _R _> internal static string GetDisplayString (this Student p) _R _> {_R _> return p. GetType ().Name; _R _>} _R _>} _R _> internal static class Program _R _> {_R _> private static void Main () _R _> {_R _> Console. WriteLine (new Person ().GetDisplayString ()); _R _> Console. WriteLine (new Student ().GetDisplayString ()); _R _> Console. WriteLine (new Professor ().GetDisplayString ()); _R _> Console. ReadKey (); _R _>} _R _>} _R _>} Not so does not go. At you in Main the object type moves explicitly, and in the task it is supposed that the link to basic object comes. At you the decoupling generally goes at compilation level. Besides, method GetType () - though and not virtual, but behaves as that, and only therefore your code works. If to cause a method of the extension from the link to basic object the last two methods of the extension will not be caused generally. Excuse, if not clearly explained.

8

Re: Explain about pattern matching in C#

Hello, dmitry_npi, you wrote: NANOSECOND>> And if Person associates are inaccessible to modification? _> all the same, the logician of distinction of types of objects should be separated from logic of formatting of a line. For example, to construct parallel hierarchy PersonFormatter, where to carry out formatting, and distinction of types to hide in factory of these . _> Yes, I understand that is bulky. Then to what questions about  ? Well and in a makeweight esteem about https://en.wikipedia.org/wiki/Tagged_union

9

Re: Explain about pattern matching in C#

Hello, _Raz _, you wrote: _>> Yes, I understand that is bulky. No, I not . _R _> Here perfectly approach extension methods. Do not approach. The classical inheritance hierarchy without the virtual methods does not work, and extension methods the virtual cannot be.

10

Re: Explain about pattern matching in C#

Hello, Night Looking, you wrote: NANOSECOND> And if Person associates are inaccessible to modification? We enter one more abstraction layer

11

Re: Explain about pattern matching in C#

Hello, mrTwister, you wrote: T> one more abstraction layer I all is entered I wait when who  recalls about Visitor.

12

Re: Explain about pattern matching in C#

Hello, dmitry_npi, you wrote: _> the Question of the second: what for it generally is necessary in OOP-language? I understand that now   aside , but after all a basis all the same remains to OOP. From my point of view, in style of OOP it was necessary to make somehow so: OOP includes . Here so. _> Here and modularity (it is possible to add separately classes), and convenience of support of many choice points (branching implicitly carries out the compiler). _> the New method it is banal provokes to write the bad code, moreover and with the big convenience In your OOP design it is necessary to drag all operations in classes, for example, how you dragged GetDisplayString. That is, a consequence of your design is encapsulation violation. Moreover, for many cases it is necessary   or its varieties. That, actually, as there is an encapsulation violation. Paradox, yes? Like OOP, and we break encapsulation when we follow OOP Actually in OOP a class the most basic functional should  only. And everything that can be made outside, should and become outside. , on the causing side there should be enough means for usage of this basic functional. This idea is implemented in Extension Method, Query Comprehension and . Pattern Matching - development of the same idea. That is, pattern matching there is an OOP improving, instead of a failure from it.

13

Re: Explain about pattern matching in C#

Hello, dmitry_npi, you wrote: NANOSECOND>> And if Person associates are inaccessible to modification? _> all the same, the logician of distinction of types of objects should be separated from logic of formatting of a line. For example, to construct parallel hierarchy PersonFormatter, where to carry out formatting, and distinction of types to hide in factory of these . It is necessary to separate a class from it . Distinction of types is . Formatting - . All need to be separated it from the class. And whether here it is necessary to divide distinction of types from logic formation of a line it already business the tenth. It is possible to divide, and it is possible and not to divide. And here is how only we of that divided that, in application it is necessary same to collect in a single whole. And for this purpose also it is necessary  . The Pattern-matching is not necessary there, where all monolithic.

14

Re: Explain about pattern matching in C#

Hello, _Raz _, you wrote: _R _> Hello, Jack128, you wrote: Instead of internal static string GetDisplayString (this Person p) {return p. GetType ().Name;} It is necessary internal static string GetDisplayString (this Person p) {if (p. GetType () == typeof (Person)) return "Person"; return GetDisplayString ((dynamic) p);}

15

Re: Explain about pattern matching in C#

Hello, vorona, you wrote: V> It is necessary V> V> internal static string GetDisplayString (this Person p) V> {V> if (p. GetType () == typeof (Person)) V> return "Person"; V> return GetDisplayString ((dynamic) p); V>} V> Here so - it is not necessary. DisplayString can change depending on singularities , adjustments of the user, the size of the device both  and . To drag all it in class Person - a crime.

16

Re: Explain about pattern matching in C#

Hello, Night Looking, you wrote: NANOSECONDS> do not approach. The classical inheritance hierarchy without the virtual methods does not work, and extension methods the virtual cannot be. Why not to make virtual extension methods?

17

Re: Explain about pattern matching in C#

Hello, dmitry_npi, you wrote: _> the Question the first: in what the basic novelty which deserves the special term "pattern matching", after all it could be done and earlier, using is/as and if/else though is more bulky? _> that is, it is simply syntactic overhead projector sugar? It not Pattern matching. It is simply expanded operator switch and anything more. For normal pattern matching that is necessary that like: static string M (Person person) {return switch (person) {case Professor ("Ivanov", _, _) p: $ "Dr. {p. LastName}"; case Studen ("Petrov", _, _, level1) s: $ "{s. FirstName} {s. LastName} ({s. Level})"; default: $ "{person. FirstName} {person. LastName}";} } That is to us the class comes, we compare it with the sample and depending on that where approaches, we fulfill certain actions. For example we want to find those professors, which Ivanovs, and the students, which Petrovy. It was possible  on value of primitives Earlier,  and lines like, now added possibility on the specific types, all innovation. Thus, as algebraic data types are not supported, this switch a little than differs from normal if else. If algebraic data types were supported, in this case at least the compiler could check up that we processed all possible subtypes, and in the separate operator switch would have sense, and so - simply insignificant syntactic improving. And high-grade pattern matching not too simply to make in practice, will be corner cases too much. And pattern matching it name because in languages which support this most pattern matching, it frequently use approximately then, what for use switch in C#. And when  are not necessary, enough  on specific type, in this case the code will be almost similar. When this pattern matching in language is, it changes programming style a little. For example if there is support Tuples with , it rather strongly changes style of a spelling of the code, there is a possibility not to create a heap of classes out of the blue, the code becomes more compact, but during too time quite clear at certain skill.

18

Re: Explain about pattern matching in C#

Hello, AlexRK, you wrote: ARK> Why not to make virtual extension methods? The virtual methods are known for a moment  target type, and methods of the extension are not present.

19

Re: Explain about pattern matching in C#

Hello, Night Looking, you wrote: T>> one more abstraction layer of NANOSECOND> I all is entered I wait when who  recalls about Visitor. And how it helps, if the hierarchy already cannot be modified and before the hierarchy did not know about a certain visitor?

20

Re: Explain about pattern matching in C#

Hello, dmitry_npi, you wrote: _> the Question the first: in what the basic novelty which deserves the special term "pattern matching" Well and in what "novelty" foreach when you can sort out hands indexes? Everything that is used often, it makes sense to carry out in convenient, short constructions. Actually, for writing of any algorithm only three commands generally are required! It agree that "pattern matching" here  but to name something another - once again to mislead. Let there will be " initial level" _> a Question of the second: what for it generally is necessary in OOP-language? OOP not and. Simply so it is convenient to assort structures when it is necessary to check a heap of conditions. PM proves in all beauty, for example, at handling AST. In the regular operation to me   it is not necessary - I manage, but if it is in C# at once, for certain and application would be!

21

Re: Explain about pattern matching in C#

Hello, vdimas, you wrote: ARK>> Why not to make virtual extension methods? V> the Virtual methods are known for a moment  target type, and methods of the extension are not present. And? The method of the extension for static type is, and more exact correspondence on dynamic type is searched in  - if is not present, the basic is caused. All the same, as with normal methods. Or I do not understand something?

22

Re: Explain about pattern matching in C#

Hello, AlexRK, you wrote: V>> the Virtual methods are known for a moment  target type, and methods of the extension are not present. ARK> And? The method of the extension for static type is, and more exact correspondence on dynamic type is searched in  - if is not present, the basic is caused. All the same, as with normal methods. Or I do not understand something? Actually it is many knee-bends, but to sense it is not strong more. Than from normal extension methods

23

Re: Explain about pattern matching in C#

Hello, AlexRK, you wrote: NANOSECONDS>> do not approach. The classical inheritance hierarchy without the virtual methods does not work, and extension methods the virtual cannot be. ARK> why not to make virtual extension methods? It is very expensive feature and absolutely unobvious.

24

Re: Explain about pattern matching in C#

Hello, AlexRK, you wrote: ARK> And? The method of the extension for static type is, and more exact correspondence on dynamic type is searched in  So it and there is dynamics. Only it is badly clear, where "is searched", in sense, what there about width of spanning? It is necessary to search in various methods-expansions of all static classes of all loaded and dependent assemblies? I.e. here the assembly is specified as dependent, but yet  because it is real types from it were not used yet, but for your sentence it is necessary  all both at once? And then to walk simple search by each call of the virtual method-expansion? Perhaps easier on "knee" somehow  if it is required to redefine behavior of the extension "globally": (schematically) static class SomeExtensions {public class Impl {public virtual void SomeExMethod (SomeType this _, Type1 arg1...) {...} } public static Impl Instance = new Impl (); public static void SomeExMethod (this SomeType this _, Type1 arg1...) {Instance. SomeExMethod (this _, arg1...)}}... class MySpecificImpl: SomeExtensions. Impl {public override void SomeExMethod (SomeType this _, Type1 arg1...) {...}}... void Main () {SomeExtensions. Instance = new MySpecificImpl ();}

25

Re: Explain about pattern matching in C#

Hello, AlexRK, you wrote: NANOSECONDS>> do not approach. The classical inheritance hierarchy without the virtual methods does not work, and extension methods the virtual cannot be. ARK> why not to make virtual extension methods? Because it absolutely other mechanics, as a matter of fact duck typing, and she demands absolutely other volume of changes both in language and in CLR.