Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Weed out deprecated headers #24

Open
solodon4 opened this issue Jun 12, 2015 · 0 comments
Open

Weed out deprecated headers #24

solodon4 opened this issue Jun 12, 2015 · 0 comments
Assignees

Comments

@solodon4
Copy link
Owner

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.

@solodon4 solodon4 self-assigned this Jun 12, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant