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

Remove Serialization MetaFormat #80

Closed
AdamsLair opened this issue Mar 10, 2014 · 2 comments

Comments

@ghost
Copy link
Collaborator

commented Mar 10, 2014

  • The serialization MetaFormat clutters the codebase and significantly increases the implementation of existing and new Formatter classes, as it essentially requires all of them to have a similar structure.
  • To remove it would decrease overall framework complexity, which is a good thing in this case.

Impact and Issues

  1. XmlMetaFormatter and BinaryMetaFormatter will be removed.
  2. XmlFormatter can be merged with XmlFormatterBase, and the same goes for BinaryFormatter and BinaryFormatterBase. A lot of their complexity will vanish.
  3. The editor will now longer be able to rely on the MetaFormat to rename Types and Namespaces when creating a new project.
  4. The ResourceHacker module becomes obsolete and will be removed as well. It will no longer be possible to use it for bulk renaming, etc.
  5. Different Formatters will be allowed to utilize different data structures that fit better to their kind.

Solutions and Thoughts

  1. Improvement
  2. Improvement
  3. This is a technical issue that needs to be dealt with. It is not possible to use temporary SerializeTypeHandlers for this purpose - because this will require the new Types to be resolvable, which isn't the case. There will be the need for some other solution.
    • String Operations on Xml Format?
    • New kind of operation for Formatter classes that reads from one stream, performs an operation on unresolved data, and directly writes it to a different stream?
    • Or maybe the same with two Formatters, so each one still only operates on one stream.
    • Or let that operation perform on a single stream with both reading and writing, so each Formatter class can handle it on its own. XmlFormatters could just find/replace on the document, BinaryFormatters could use the boundary markers to read and modify only headers, while writing other memory unchanged.
    • Or something else. No final solution yet.
  4. Using a human-readable data format will serve the same purpose and be a lot more efficient and easy at the same time. So this will not be a problem.
  5. Improvement

@AdamsLair AdamsLair added Task labels Mar 10, 2014

@ghost

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 14, 2014

  • Regarding point 3, it may actually be the best solution to just remove that renaming functionality entirely, since it is only used at a single (minor) spot in the entire framework.
  • In order to keep "Create New Project" working, including a namespace change, just auto-create some SerializeErrorHandler classes that are compiled into the new projects plugin.
@ghost

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 14, 2014

Done.

@AdamsLair AdamsLair closed this Mar 14, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
1 participant
You can’t perform that action at this time.