> On 29 Nov 2016, at 09:11, Christophe Demarey <[email protected]> > wrote: > > Hi, > >> Le 29 nov. 2016 à 08:45, Esteban Lorenzano <[email protected] >> <mailto:[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.
yeah, but is a common use too… just you’re too DB shaped ;) > yes, something like TableCellSource or TableCellProvider is more intention > revealing. No, because is not *just* a cell provider. TableDataSource, TableStore, TableProvider, yes. I kind of like “TableStore”. Also we have other stores in image: FileSystem stores… which conceptually do more or less the same… so better to unify concepts/names… what do you think? Esteban > > Christophe
