{"action":"closed","issue":{"url":"https://api.github.com/repos/OPM/opm-parser/issues/795","repository_url":"https://api.github.com/repos/OPM/opm-parser","labels_url":"https://api.github.com/repos/OPM/opm-parser/issues/795/labels{/name}","comments_url":"https://api.github.com/repos/OPM/opm-parser/issues/795/comments","events_url":"https://api.github.com/repos/OPM/opm-parser/issues/795/events","html_url":"https://github.com/OPM/opm-parser/issues/795","id":153637287,"number":795,"title":"Difficult api: EclipseDeck?","user":{"login":"joakim-hove","id":1321665,"avatar_url":"https://avatars.githubusercontent.com/u/1321665?v=3","gravatar_id":"","url":"https://api.github.com/users/joakim-hove","html_url":"https://github.com/joakim-hove","followers_url":"https://api.github.com/users/joakim-hove/followers","following_url":"https://api.github.com/users/joakim-hove/following{/other_user}","gists_url":"https://api.github.com/users/joakim-hove/gists{/gist_id}","starred_url":"https://api.github.com/users/joakim-hove/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/joakim-hove/subscriptions","organizations_url":"https://api.github.com/users/joakim-hove/orgs","repos_url":"https://api.github.com/users/joakim-hove/repos","events_url":"https://api.github.com/users/joakim-hove/events{/privacy}","received_events_url":"https://api.github.com/users/joakim-hove/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":11,"created_at":"2016-05-08T05:44:40Z","updated_at":"2016-11-04T08:42:57Z","closed_at":"2016-11-04T08:42:57Z","body":"The seemingly quite simple PR: https://github.com/OPM/opm-upscaling/pull/188 is an example of a recurring problem:\n1. The `Deck` datatype is essentially a quite simple container of `DeckKeyword` instances, the `Deck` container gives no upfront guarantees of the content of the container.\n2. The `EclipseState` constructor requires a valid[1] deck as input, and will raise an exception if e.g. the `GRID` section is missing.\n3. The `EclipseGrid( Deck )`constructor is by construction accepts a non valid grid - in particular a grid without a `GRID` section.\n\nWe therefor have a situation where the two constructors:\n\n``` C++\nEclipseGrid::EclipseGrid( Deck ) \n...\nEclipseState::EclipseState( Deck, )\n```\n\nhave different semantic requirement to the input argument - that is quite difficult to see!\n\n**EclipseDeck**\n\nAs a possible improvement I suggest that we create a class e.g. `EclipseDeck` which wraps/extends an existing `Deck` instance and enforces deck validity in the constructor:\n\n``` C++\nEclipseDeck::EclipseDeck( const Deck& deck) {\n    if (!deck.hasKeyword(\"GRID\"))\n      throw std::invalid_argument(\"Missing GRID section\");\n   ...\n}\n```\n\nBy using the `EclipseDeck` or `Deck` type in the api we can clearly communicate whether we want a semantically correct Eclipse deck, or just a random collection of keywords.\n\n[1]: Valid is quite poorly defined in this context, but it at least requires some sections. Going along the suggested route with `EclipseDeck` we could also give a much better definition to _valid deck_. \n"}}
{"actor":{"display_login":"jokva"}}