After all, I tend to agree on the -1. Let's consider this discussed, but rejected.
2013/8/2 Manuel van den Berg <[email protected]>: > 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()
