Hi, > Le 29 nov. 2016 à 08:45, Esteban Lorenzano <[email protected]> a écrit : > >> >> On 29 Nov 2016, at 00:00, Ben Coman <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> >> On Tue, Nov 29, 2016 at 5:29 AM, Esteban Lorenzano <[email protected] >> <mailto:[email protected]>> wrote: >> Hi, >> >>> On 28 Nov 2016, at 21:32, stepharo <[email protected] >>> <mailto:[email protected]>> 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
