Hi Kasper I like it on the surface, but if there is no _actual_ gains other than a minor improvement to naming, it may be a little too much change for too little value.
If it made new stuff possible, or make the API easier to use or extend, then it would make sense to me. BR, Dennis -----Original Message----- From: Kasper Sørensen [mailto:[email protected]] Sent: 20. januar 2015 08:34 To: [email protected] Subject: Introduce super-interfaces for Row and Column that are less table-oriented? 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
