Hi,
Le 29 nov. 2016 à 08:45, Esteban Lorenzano <estebanlm@gmail.com> a écrit :
On 29 Nov 2016, at 00:00, Ben Coman <btc@openInWorld.com <mailto:btc@openInWorld.com>> wrote:
On Tue, Nov 29, 2016 at 5:29 AM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: Hi,
On 28 Nov 2016, at 21:32, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
Hi
- Could we rename FastTable into Table?
not for Pharo 6 but Pharo 7 yes⦠in fact, I think it should be called TableMorph. (Also we need to refactor a lot, to eliminate the FT prefix, etc.)
- Then I miss an important design point. Why datasource returns Morph? I do not get get why a data source should return UI element. To me it violates layers.
no, because thatâs its purpose: to provide the table with the cell elements (which are by definition Morphs⦠any kind of morphs). a TableDataSource is not a spec, is the provider of cells.
so maybe TableCellSource / TableCellProvider ?
Iâm not against changing its name, in general the family of names are âDataSourceâ, âStoreâ, etc. so I imagine that âProviderâ fits (even if I tend to hate names style âManagerâ, âFactoryâ, âProviderâ, because there are too generic⦠sometimes is that what you have :P) But is not just a âcell providerâ, it does something more, is a general model of the TableMorph: it provides cells, headers and interaction capabilities (like drag&drop)⦠so it is more like a "table data providerâ, TableDataSource, TableStore, TableProvider are then better names, IMOâ¦
this changes will impact Pharo 7⦠is very good that we can have a discussion like this now, that we have the time to reach a consensus :)
To me, the name datasource is misleading in this case. I would expect to find an abstraction that takes data from a database, or a file or in-memory object, etc. yes, something like TableCellSource or TableCellProvider is more intention revealing. Christophe