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

[C++][Pistache] Fix optional error and wrong function signatures #264

Merged
merged 10 commits into from
Jun 22, 2018

Conversation

stkrwork
Copy link
Contributor

@stkrwork stkrwork commented Jun 9, 2018

PR checklist

  • Read the contribution guidelines.
  • Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh and ./bin/security/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\.
  • Filed the PR against the correct branch: Default: master.
  • Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

Description of the PR

(details of the change, additional tests that have been done, reference to the issue for tracking, etc)

#257 #258

@stkrwork stkrwork changed the title [C++][Pistache] Looking into optional error and wrong function signatures [C++][Pistache] Fix optional error and wrong function signatures Jun 9, 2018
@stkrwork stkrwork force-pushed the pistahce_optional_and_api_fix branch from 7258341 to d77fc9d Compare June 9, 2018 20:07
@stkrwork
Copy link
Contributor Author

@ravinikam @fvarose @etherealjoy @MartinDelille

@@ -327,29 +327,16 @@ public String toDefaultValue(Schema p) {
ArraySchema ap = (ArraySchema) p;
String inner = getSchemaType(ap.getItems());
if (!languageSpecificPrimitives.contains(inner)) {
inner = "std::shared_ptr<" + inner + ">";
inner = inner;
Copy link
Contributor

Choose a reason for hiding this comment

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

Why this assignment?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

oh, seems i forgot to remove it, when removing shared ptr

{
return m_Category;
}
void Pet::setCategory(std::shared_ptr<Category> value)
void Pet::setCategory(Category value)
Copy link
Contributor

Choose a reason for hiding this comment

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

Here not a reference?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i'll add it

std::shared_ptr<Category> getCategory() const;
void setCategory(std::shared_ptr<Category> value);
Category getCategory() const;
void setCategory(Category value);
Copy link
Contributor

Choose a reason for hiding this comment

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

Here not a reference?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i'll add it

@etherealjoy
Copy link
Contributor

etherealjoy commented Jun 10, 2018

@stkrwork
Passing complex types by reference makes sense since it avoid copy construction. But Primitive types benefit from passing by value instead of by reference.
Does it makes sense to do this also here. I mean for all purposes the functional behavior is the same.
But the PR is solving some long standing issue in the generator with Optional, which is much needed.

@MartinDelille
Copy link
Contributor

I don’t know especially what Pistache is but passing the value by const reference, even for complex type, should be generalized to all cpp generators. What do you think?

@stkrwork
Copy link
Contributor Author

i was considering const&, but in my initial thought i was thinking of doing it for every signature, but this approach is better.

@MartinDelille
Copy link
Contributor

Each time I consider using const attributes for my methods, it leads to big and healthy refactoring! 😄

@stkrwork
Copy link
Contributor Author

the const and reference refactoring will most likely also be required for the restbed generator

@MartinDelille
Copy link
Contributor

And for Qt generator too! I create the issue.

@etherealjoy
Copy link
Contributor

@stkrwork
I have a question, now the complex types have to be const before passing as reference to the api right?

@stkrwork stkrwork force-pushed the pistahce_optional_and_api_fix branch from 7b90d3a to 9f76d1a Compare June 10, 2018 14:54
@stkrwork
Copy link
Contributor Author

It just states that the complex type wont be modified. they dont have to be const outside of the function, they are just dealt as constants in the function

@stkrwork
Copy link
Contributor Author

@CyrilleBenard does that fix your issues #257 and #258

@CyrilleBenard
Copy link

@stkrwork I'm sorry, I still do not try your PR 'cause I evaluate the openapi-generator during my time job. I will do it during the next week. Thx for your reactivity

@CyrilleBenard
Copy link

One regression seems to occurred, see issue #257 - part 2 of my last comment relative to the use of static + const

@stkrwork stkrwork force-pushed the pistahce_optional_and_api_fix branch from 41d8319 to e0b1917 Compare June 12, 2018 12:25
@stkrwork
Copy link
Contributor Author

i added your request

@wing328
Copy link
Member

wing328 commented Jun 14, 2018

If no further question/feedback on this PR, I'll merge it into master in a few hours.

cc @ravinikam @fvarose @etherealjoy @MartinDelille

@wing328 wing328 added this to the 3.0.2 milestone Jun 14, 2018
@CyrilleBenard
Copy link

CyrilleBenard commented Jun 14, 2018

Optional error has been fixed but I as far as I know, the function signature is still buggy. May be I misunderstand what's behind "wrong function signatures" (?).
In my opinion, it refers to #258 and nothing has been fixed :/

EDIT: More over, the Optional error fix implies a new issue (see type conversion). I saw in the chat (gitter) that @stkrwork was working on it

@stkrwork
Copy link
Contributor Author

well, it might take some time, because i don't have much time at the moment to implement the ideas i posted in chat

@CyrilleBenard
Copy link

CyrilleBenard commented Jun 14, 2018

@stkrwork yes sure 👍
I just replied to @wing328's question :)
Hopping the C++ server stub will compile again as soon as possible, maybe next week ? 💃

@stkrwork
Copy link
Contributor Author

otherwise you can also pick up where i left off.

@wing328
Copy link
Member

wing328 commented Jun 14, 2018

I'll put this on hold and will only merge this after I get the sign-off from you guys. Please take your time.

@stkrwork stkrwork force-pushed the pistahce_optional_and_api_fix branch from cf3db65 to d018fe0 Compare June 16, 2018 09:46
@Schrigga
Copy link

@stkrwork I forked your branch with the changes you have already done. I changed some things, but I stucked compiling the UserApi.cpp when the users should be initialized using an array or an list.
Currently I'm wondering if there is a possibility in the mustache files to distinguish whether there are non primitive type and are arrays. Do you have any knowledge about this?

@wing328
Copy link
Member

wing328 commented Jun 17, 2018

@Schrigga what about using the following?

{{#isListContainer}}
{{^isPrimitiveType}}
...
{{/isPrimitiveType}}
{{/isListContainer}}

@stkrwork stkrwork force-pushed the pistahce_optional_and_api_fix branch from d018fe0 to c6c1da4 Compare June 17, 2018 18:43
@jmini jmini modified the milestones: 3.0.2, 3.0.3 Jun 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants