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.

Sign up for GitHub

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

feat: implement type to record internal solution #205

Merged
merged 2 commits into from
Mar 10, 2020
Merged

feat: implement type to record internal solution #205

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1b312dd
feat: implement internal solution format.
CodeBear801 Mar 8, 2020
00fc9e3
fix: rename solutionformat-> solution
CodeBear801 Mar 9, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions integration/oasis/solutionformat/doc.go
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
/*
package solutionformat defines internal foramt for recording single solution result.
It isolates internal calculation logic and final restful response:
- Internal algorithm will calculate result in this format.
- In the end, oasis will use this format to generate restful response.
*/
package solutionformat
Copy link

Choose a reason for hiding this comment

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

I feel solution will be better, even it causes solution.Solution. How's your idea?

Copy link
Author

@CodeBear801 CodeBear801 Mar 9, 2020 •
edited
Loading

Choose a reason for hiding this comment

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

I like shorter name.

My original thinking is, solution is better contains not only type definition but also solution logic, which is how those type is constructed, such as the calculation logic.

Currently, I put constructing logic inside stationgraph, in the end of its calculation it will generate result in solutionformat, which could be dumped to external format. That's what I try to limit scope with solutionformat or solutiontype

But as a reviewer, I think solution is more clear than solutionformat or solutiontype.

Copy link
Author

@CodeBear801 CodeBear801 Mar 9, 2020 •
edited
Loading

Choose a reason for hiding this comment

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

The following comment I think is worth to record: Avoid to use package name as variable name, otherwise you will get strange errors.

After I rename package name from solutionformat to solution, there are some existing code use this package create a variable solution there. (this code is not in this pull, they exists in the pull request #203)

solution := &solution.Solution{}
solution.ChargeStations = make([]*solution.ChargeStation, 0)

I met following error:
image

I think compiler confuse on whether solution is a package name or a variable name. After I rename variable solution to sol, problem solved. But it took me a while to figure it out. I original thought it is related with package renaming.

26 changes: 26 additions & 0 deletions integration/oasis/solutionformat/solution.go
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
package solutionformat

// Solution contains summary and selected charge stations
type Solution struct {
Distance float64
Duration float64
RemainingRage float64
Weight float64
ChargeStations []*ChargeStation
}

// ChargeStation contains all information related with specific charge station
type ChargeStation struct {
Location Location
StationID string
ArrivalEnergy float64
WaitTime float64
ChargeTime float64
ChargeRange float64
}

// Location defines the geo location of a station
type Location struct {
Lat float64
Lon float64
}