Field options are currently stored in numbered arrays. For example, in field_image.inc, we use $field->options[1] for 'Maximum picture dimensions'.

This makes working on new features in fields a potential minefield; different developers could be creating field options with the same option 'index'. It also makes patches unnecessarily dependent upon eachother. Instead it would be a lot 'saver' to use associative arrays, such as $field->options['max_dimemnsions'].

Refactoring flexinode to use associative arrays involves two steps:

  • Editing the current set of field types
  • Providing an upgradepath for current contenttypes in the db

The former is trivial, but I have no experience with the latter. Is this a useful undertaking at this point in time (since a 4.7 release is still being fleshed out)?