You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is that possible the Constructor pattern is used without C(P) ?
when I read the paper in Open Pattern Matching For C++, it says Constructor pattern should be used with C(p), for recognize it's class type. but, when I see the example01 file, It just match its type as Case(Circle) - not Case(C(center, radiuse) - is that syntax changed ?
or, the two usage is distinct its' functionality ? like ... for specifying which constructor / and it's member binding, use the Constructor Pattern, and When Just specify its' type, is using Case(ClassType) ?
Incomplete Answer:
Yes, we’ve been experimenting with different syntaxes in the project and currently the library can support several of them. Not at the same time unfortunately, but as close as we could get to this. Search for uses of macro XTL_DEFAULT_SYNTAX as it controls which of the syntaxes and encodings the library should use. The older match.hpp header would default to Case clauses with syntax you see in example01.cpp. The newer syntax towards which we lean is enabled by including header type_switchN-patterns.hpp. It is derived from the older match.hpp, however it moves experimentation further in the direction of relational matching (multiple arguments) and patterns. You can still use patterns syntax in the old header, but you’d have to use Qua clauses instead of Case clauses. Header type_switchN-patterns-xtl.hpp is even further generalization of the type_switchN-patterns.hpp that allows support for non-polymorphic (in C++ terminology) classes like boost::variant. That’s the most recent version of the header, which I’ll be moving forward. Other headers would be either eliminated if they are superseded by this one, or kept (like match.hpp), when they provide functionality not superseded by this latter one. We do strongly recommend the syntax from the paper via use of this last header as it provides the most flexibility in design overall.
Action:
Eliminate all experimental match*.hpp headers and leave only the older match.hpp and then latest type_switchN-patterns-xtl.hpp with a sexier name. These 2 will have differences in functionality, and preference should be given to the latter newer one. All other experimental derivations should be cleaned out.
The text was updated successfully, but these errors were encountered:
Question from email:
Is that possible the Constructor pattern is used without C(P) ?
when I read the paper in Open Pattern Matching For C++, it says Constructor pattern should be used with C(p), for recognize it's class type. but, when I see the example01 file, It just match its type as Case(Circle) - not Case(C(center, radiuse) - is that syntax changed ?
or, the two usage is distinct its' functionality ? like ... for specifying which constructor / and it's member binding, use the Constructor Pattern, and When Just specify its' type, is using Case(ClassType) ?
Incomplete Answer:
Yes, we’ve been experimenting with different syntaxes in the project and currently the library can support several of them. Not at the same time unfortunately, but as close as we could get to this. Search for uses of macro XTL_DEFAULT_SYNTAX as it controls which of the syntaxes and encodings the library should use. The older match.hpp header would default to Case clauses with syntax you see in example01.cpp. The newer syntax towards which we lean is enabled by including header type_switchN-patterns.hpp. It is derived from the older match.hpp, however it moves experimentation further in the direction of relational matching (multiple arguments) and patterns. You can still use patterns syntax in the old header, but you’d have to use Qua clauses instead of Case clauses. Header type_switchN-patterns-xtl.hpp is even further generalization of the type_switchN-patterns.hpp that allows support for non-polymorphic (in C++ terminology) classes like boost::variant. That’s the most recent version of the header, which I’ll be moving forward. Other headers would be either eliminated if they are superseded by this one, or kept (like match.hpp), when they provide functionality not superseded by this latter one. We do strongly recommend the syntax from the paper via use of this last header as it provides the most flexibility in design overall.
Action:
Eliminate all experimental match*.hpp headers and leave only the older match.hpp and then latest type_switchN-patterns-xtl.hpp with a sexier name. These 2 will have differences in functionality, and preference should be given to the latter newer one. All other experimental derivations should be cleaned out.
The text was updated successfully, but these errors were encountered: