Well, collections will make life easier on the programmers (both contributors to MM and users of MM) in general. From that point of view, I can see the benefits of the proposal.
However from backward compatibility point of view, I couldn't think of a nice solution: * No automatic conversion of collections to arrays * Cannot overload the methods on return type only * Array subscript syntax doesn't work on the collection types * Even for the foreach syntax, most likely one would use a typed variable * Creating distinct methods or classes or packages works, but looks lame and still needs a depreciation policy So, a -1 for me on this one. -- Manuel > -----Original Message----- > From: Kasper Sørensen [mailto:[email protected]] > Sent: Wednesday, July 24, 2013 20:38 > To: [email protected] > Subject: [DISCUSS] use collections instead of arrays in API > > Another candidate for a breaking API change: Getting rid of arrays in the API > of MetaModel, and replace them with collections. > > Why? I have a couple of reasons that I have run into: > 1) Collections are easier to mock in testing scenarios. > 2) Collections can be made immutable (or just unmodifiable to consumers) > 3) Collections can be lazy evaluated (makes lazy metadata loading a lot > easier for us to implement) > > While these seem like important issues to address, I am myself actually > feeling a bit hesitant to make such a change. It would impact just about any > use of MetaModel out there maybe the price is too high. > > In practice these issues have so far been adressed like this: > 1) Only mocking of the individual array elements was possible. > 2) When necesary, an array copy will be returned instead of the original > array. > Thus modifications are at least harmless. > 3) Lazy loading has been implemented in the sense that these arrays are > themselves not loaded before necesary, but the array itself has to be > allocated/sized and lazy stubs needs at least to be added eagerly. In practice > we've not seen outragously large arrays, so memory-wise it hasn't been a > problem. > > Here's a list of places where arrays are returned, and where a collection type > would probably be better suited: > > DataContext.getSchemas() > DataContext.getSchemaNames() > Schema.getTables() > Schema.getTableNames() > Table.getColumns() > Table.getColumnNames() > Table.getPrimaryKeys() > Table.getForeignKeys() > Table.getIndexedColumns() > Table.getLiteralColumns() > Table.getBooleanColumns() > Table.getNumberColumns() > Table.getTimeBasedColumns() > Table.getColumnsOfType(...) > Table.getColumnsOfSuperType(...) > Table.getRelationships() > FilterItem.getChildItems() > FilterItem.getOrItems() > FromItem.getLeftOn() > FromItem.getRightOn()
