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

Extensible definition dictionary #47

Open
Tracked by #332
ForNeVeR opened this issue Feb 24, 2017 · 5 comments
Open
Tracked by #332

Extensible definition dictionary #47

ForNeVeR opened this issue Feb 24, 2017 · 5 comments

Comments

@ForNeVeR
Copy link
Owner

ForNeVeR commented Feb 24, 2017

To avoid polluting our main formula dictionary (i.e. PredefinedTexFormulas.xml) with various localized formula names (like this), I propose to add a dictionary extension mechanism.

Users should be able to provide theirs own dictionary files that will be merged with the existing definitions.

Also, these Russian localized definitions should be extracted from the default dictionary and should became opt-in functionality (I still want to redistribute them alongside WPF-Math because personally I need those, and I think they're generally useful for people around the world).

And don't forget to add end-user documentation explaining how to make and apply these definition files!

@alexreg
Copy link
Collaborator

alexreg commented Feb 26, 2017

This might be a reason to get rid of the DSL and define the operators using a builder-syntax in-code... haven't thought it through fully though.

@ForNeVeR
Copy link
Owner Author

ForNeVeR commented Feb 27, 2017

I think that's a separate issue. When planning this, I thought that we could simply split our XML definitions (e.g. PredefinedTexFormulas.xml) to multiple files and load them on demand (for example, pass resource names to TexFormulaParser constructor or something like this).

I'm not sure if we'll ever want to completely replace all our PredefinedTexFormulas with C# code, but some additional flexibility perhaps wouldn't hurt.

@alexreg
Copy link
Collaborator

alexreg commented Feb 27, 2017

I don't think that's nearly as elegant, if I'm honest... keeping everything in code makes the extensibility aspect really easy.

@ForNeVeR
Copy link
Owner Author

Alright, let's think about that a little more.

I'd like to settle things like this before releasing the "stable" version 1.0, that should have a stable and extensible API we won't accidentally break.

@alexreg
Copy link
Collaborator

alexreg commented Feb 27, 2017

Agreed. I know abandoning the XML definition format may seem like a bit of a waste now, but I think it could be the optimal way forward, especially as far as extensibility is concerned. The DSL could grow to unwieldy proportions otherwise...

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

2 participants