Committee Report 2015 Apr

MATSIM-162 - Getting issue details... STATUS

Extensions are catalogued here: 

An extension in this sense can be a Contrib, a project hosted externally, or even a part of org.matsim:matsim (pt, for example). The template allows providing a link to documentation. Contribs and parts of org.matsim:matsim should also link to their Javadoc.

MATSIM-186 - Getting issue details... STATUS

We are not attempting not to have some space-time-representation of the traffic system which is shared between MobsimEngine instances (a "service network" or "infrastructure network" which may allow putting people on links or some such). NetsimNetwork is currently tied to the QNetsimEngine but accessed by other code. We may factor some of this out of QNetsimEngine to "legalize" this.

MATSIM-197 - Getting issue details... STATUS

There was the question whether methods on Controler which allow to create service objects like TavelDisutility should be create-methods or getFactory-methods. In the meantime, all the Factory-getters and all the create-methods left on the Controler are going to disappear in favor of Dependency Injection.

MATSIM-215 - Getting issue details... STATUS

MatsimConfigReader does not treat the string "null" as a special value anymore. This kind of interpretation is now up to each ConfigGroup.

MATSIM-216 - Getting issue details... STATUS

Our top level containers provide Map views of their content. Population, for example, returns Map<Id<Person>, ? extends Person>. There is the argument that the only reason the wildcard is there was to make it compile-time-harder to add elements to this map, and that this was an abuse of Java syntax. There is no agreement on this. It is not even clear that providing a Map is the best idea at all. Hence, we will leave this in place until a distant-future possible major data API overhaul.

MATSIM-235 - Getting issue details... STATUS

We encourage all cooperating institutions to do a playground-sweep: Delete playgrounds of your former team members who are no longer working on MATSim. For the future, we encourage institutions to share one playground among different team members. This reduces inter-playground dependencies, and it presumably reduces occurences of playgrounds which don't compile for a long time, because mroe people would be likely to notice.

MATSIM-144 - Getting issue details... STATUS

We are not actively pursuing removing within-day replanning infrastructure from the core.

MATSIM-301 - Getting issue details... STATUS

It should not, in general, be necessary to test for the 'presence' of a top-level container such as TransitSchedule. Ideally, the question should be resolved at configuration time: If I don't have the transit module in the loop, then I should also not have things in the loop which use the transit module. In terms of Guice:

We parameterize our modules by Config. It's OK for a module to decide based upon the Config if, or to which implementation, an interface is bound. Hence:

if (getConfig().scenario().isUseTransit()) {

If I now later bind something which needs a TransitSchedule, it will not get injected null, but it will give a startup-time Exception.

Hence, when scenario.getTransitSchedule() throws an exception when there is no TransitSchedule, this approximates the above rather well, better than if it would return null.

MATSIM-229 - Getting issue details... STATUS

It was suggested to always use boxed primitives (Integer, Boolean, ...) as member types in data objects, rather than primitives (int, bool, ...). This would allow null as a value, meaning "undefined". We could not agree that this is something which should be generally recommended. The discussion in this Issue contains a suggestion how to avoid the situation alltogether. And in Java 8, there will be java.util.Optional<T>, OptionalInt, etc.