Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Create cross-format
StandardProperties
class #29base: dev
Are you sure you want to change the base?
Create cross-format
StandardProperties
class #29Changes from 9 commits
c87e3ba
ee30d57
ad0c724
0910fa9
3cc9283
bc4ce09
45783f0
5341ecf
b8673c7
bd7ecc2
f0a2376
da53284
52852bd
6f4aa42
0a46ede
fd19740
4633d7f
273e481
26e608f
5eaf880
782469d
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This design is bad: malicious actors can fake an id and pollute the metadata detection. You should just keep a
Map<MappingFormat, Map<String, StandardProperty>>
instead.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what you mean, the internal maps are all private anyway
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Say if you have a
next-intermediary-method
read from tiny v1, you would incorrectly interpret it as an intermediary counter while it isn't.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've already added a sanity check preventing this: 5341ecf
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue why I need a simple String ID instead of a
Map<MappingFormat, Map<String, StandardProperty>>
is intermediate operations, sayMemoryMappingTree.accept(MemoryMappingTree)
, where none of the participants know which mapping format the former tree was originally constructed from. I could generate a random ID per session, but IMO that's overcomplicating things without much reason. Maybe prepending the existing ID withmio:
would do?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we just add a new
default void visitStandardProperty(StandardProperty prop, String value)
inMappingVisitor
andFlatMappingVisitor
, which fabric's builtin visitors will override? And we can choose to feed these standard properties back as String key-values in visit options.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, not a huge fan of this, since up until this point the visitor- and tree-based APIs have always been cleanly separated.
Edit: On the other hand,
StandardProperty
isn't really part of the tree-api, so maybe it'd work? But it still duplicates the metadata visit methods, which pollute theFlatMappingVisitor
interface, especially considering #41 will add even more.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Im not sure these should exist in mio, they are specific to intermediary and are generated by matcher. They arent part of the tiny format, and I dont think we actually read them anymore?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
happy to discuss this if you think otherwise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say this is a bit of an edge-case, since the counters have been special-cased until now and consequently behaved as de-facto standard properties. I could remove it, so we end up using the
INTERMEDIARY_COUNTER
notation in Tiny v2, too, though this would conflict with existing naming conventions and we would be stuck with a misleading name. We could of course also delegate this responsibility to Matcher, which would have to do the conversion via a custom forwarding visitor passThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the long run we might need an API letting consumers register their own standard properties