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

61 input location #62

Merged
merged 2 commits into from
Mar 9, 2019
Merged

61 input location #62

merged 2 commits into from
Mar 9, 2019

Conversation

hboutemy
Copy link
Member

see #61

*/
public static interface InputLocationBuilder
{
Object toInputLocation( XmlPullParser parser );

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about 'getCurrentInputLocation'?

Should we explicitly state the expected behavior?

Is it better to return an GenericInputLocation, just as a placeholder interface? It will make code more typesafe and clearer IMHO

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'getCurrentInputLocation': since it is expected to create an object, I don't like 'get'

What do you mean by "state the expected behavior"?

Since the implementation is really something that will be specific to the user, and that the user will have to cast, I don't see the benefit of creating an empty interface

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'getCurrentInputLocation': since it is expected to create an object, I don't like 'get'

My concern is that the function takes a stateful object as parameter, so I image it will return a view of the current state of the parser.
the word 'to' seems to me like a 'conversion'.
Not so important to me, I am very new to this code.

What do you mean by "state the expected behavior"?

For instance, if the method is called twice is it expected to return two equivalent objects, the same object, or what ?

Object a =  toInputLocation( parser );
Object b =  toInputLocation( parser );

should b == a, b.quals(a) or it is not important ?

Since the implementation is really something that will be specific to the user, and that the user will have to cast, I don't see the benefit of creating an empty interface

Fine

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for input location, ordering is not important: really, the documentation to read is https://codehaus-plexus.github.io/modello/location-tracking.html

Copy link

@eolivelli eolivelli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1
Thank you @hboutemy

I am very new to this part of Maven.

@hboutemy
Copy link
Member Author

yes, reviewing and seconding is a good opportunity to learn: thank you for your review

@@ -86,6 +88,12 @@ public Xpp3Dom( String name )
childMap = new HashMap<String, Xpp3Dom>();
}

public Xpp3Dom( String name, Object inputLocation )
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking out loud: Can we add a generic to Xpp3Dom, like Xpp3Dom<T>, where T reflects the inputLocation?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose it is feasible: IMHO, gives too much visibility to input location tracking, which is really something very special, but feasible

@hboutemy hboutemy merged commit dd8d35a into master Mar 9, 2019
@hboutemy hboutemy deleted the 61-input_location branch March 9, 2019 16:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants