Skip to content

Conversation

@bartekgorny
Copy link
Collaborator

You may want to add some syntactic sugar, depends on your taste - for now the interface is a bit raw, you have to pass a tuple containing multicast host and a list of #extaddress{} records.

props :: list()
}).

-record(extaddress, {
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe I'm limited or sth but I think that using a map here would simplify developer's life when it comes to debugging (which is quite common part of our day to day life :) ). The map could have it's own type with required and optional type.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I have nothing against maps, they are so useful when you need flexibility. But when I know for sure what the data structure is supposed to contain I prefer records, they make code so much more readable.

Copy link
Contributor

Choose a reason for hiding this comment

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

they make code so much more readable

I'd say the same about maps :) plus they make debugging so much nicer :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Do they give you code completion?

Copy link
Contributor

Choose a reason for hiding this comment

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

Actually I don't use code completion so I don't care :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This case is not a big deal, so if it is your strict requirement then fine, I can change it to a map. But, really, we should give it a serious though. From what I know, our coding guidelines do not say "never use records", but the practice seems to be heading in that direction. I'd suggest we make some effort to formulate a common approach, stating which data structure should/can be applied in which cases, to avoid such tensions in the future.

Copy link
Contributor

Choose a reason for hiding this comment

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

It's not a strict requirement, note that I didn't request for changes, just commented in the review :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Ok, got it. Can it be merged, then?

@michalwski
Copy link
Contributor

Did you try it with current MongooseIM tests? escalus_stanza:message/4 was modified, there is a good chance this function is used somewhere in big_tests. It be good to know that tests still work with your changes.

Please rebase this branch on top of current master (there was quite many changes in escalus recently) and open a PR in MongooseIM with escalus from this branch.

@NelsonVides
Copy link
Contributor

Reviving this one, old and with some conflicts by now but I like the idea, would be cool to implement so in MongooseIM as well so having the testing tool will be useful beforehand. Any thoughts on this? @bartekgorny

@arcusfelis
Copy link
Contributor

Not closing, because @NelsonVides is interested in it...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants