Hi all, I really like the API of MetaModel, but there's just one thing that I think is sometimes getting in the way of semantically expressing all you can do with it: The names "Row" and "Column". These are fine if you're actually working with a tabular datastore such as a RDBMS or maybe a CSV file. But we also support NoSQL databases and other stuff where things aren't exactly columns, rather they are in my opinion "fields". And they aren't persisted in a row as such, but rather in a more loosely defined "record". Do you agree on this?
If you do ... I'm not quite sure yet what the overall impact would be of changing this naming. For now I am thinking that we could introduce two super-interfaces, "Field" and "Record". As such Row would extend Record and Column would extend Field. That doesn't do any impact, except that we symbolically show that there's a specific kind of record called "Row" and a specific kind of field called "Column". Already a semantic improvement in my opinion. We could then also consider some minimal-impacting initiatives like adding adding a method "Record.getValue(Field)" similar to the current "Row.getValue(Column)". This would have a small impact, but that could all be handled in AbstractRow and I doubt that any consumers of MM would ever notice - even those that build new DataContext implementations or such. Lastly if we take the idea to it's extreme we would also need to find a new super-interface for Table, and that structure would be able to provide a getFields()-like method (like the getColumns() method in Table) ... But on that I am neither sure about naming nor how to do it without major impact on compatibility. What do you guys think? Is it important to do this kind of semantic stuff to make the API pretty, or does it not matter at the end of the day? Best regards, Kasper
