[babygopher question] Why using generic.Map to handle manifests instead of a well formed type struct? about cli HOT 2 CLOSED

We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: http://www.pivotaltracker.com/story/show/64510302

from cli.

@drnic this is an absolutely great question and I'm glad that you're asking it.

One big win from generic.Map is that it has a .Has(key) method which allows you to test for the existence of a key in the map and determine whether an integer (for example) is actually zero because the user said "set this to zero" or if that was set by default.

I also think (but am not certain) that manifests are slightly more complicated than a single struct could capture. We support inheritance in manifests, parameters for an application can be provided at the top scope, or for a single application and we also validate the contents of manifests so we can provide helpful error messages to users. The flexible, generic interface Map provides made these features fairly easy to implement. Manifests are really surprisingly complicated -- did you know that the v5 cli had a random number generator for manifests?

There are some higher-order functions built up around generic.Map -- namely Merge and Reduce -- that have been helpful, but I fear they may be slightly too clever and may prove to be difficult to maintain as the requirements around manifests change. Excessive use of this generic.Map pattern is probably a code smell -- I'd think twice before introducing it to more structured models with a well defined schema.

from cli.