two question about fasttable

On 28 Nov 2016, at 22:25, Henrik Nergaard <[hidden email]> wrote:

The datasource is a wrapper/binding between the real object and the view (table/list) and provides the necessary stuff for display and interaction between them. Returning custom UI elements (cells and rows) from the datasource is part of what makes it possible to reuse the same table/container morph for lists/tables/trees. 

On 29 Nov 2016, at 00:00, Ben Coman <[hidden email]> wrote:

On Tue, Nov 29, 2016 at 5:29 AM, Esteban Lorenzano <[hidden email]> wrote:

Hi, 

On 28 Nov 2016, at 21:32, stepharo <[hidden email]> 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 ?

cheers -ben 

On 29 Nov 2016, at 09:11, Christophe Demarey <[hidden email]> wrote:

Hi,

Le 29 nov. 2016 à 08:45, Esteban Lorenzano <[hidden email]> a écrit :

On 29 Nov 2016, at 00:00, Ben Coman <[hidden email]> wrote:

On Tue, Nov 29, 2016 at 5:29 AM, Esteban Lorenzano <[hidden email]> wrote:

Hi, 

On 28 Nov 2016, at 21:32, stepharo <[hidden email]> 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

On 29 Nov 2016, at 09:58, Aliaksei Syrel <[hidden email]> wrote:

"DataSource" is responsible for providing visual elements that represent items in a data set.

I don't see how word "Store" fits here, because DataSource does not store anything. DataSource is also not the best name since it is not a data source itself.

An object that is now called DataSource, basically just knows a single function that from mathematical point of view can be defined as follows:

f: Object -> Morph . You see, it is a mapping, not a souse or store.

Cheers,

Alex

On 29 November 2016 at 09:44, Denis Kudriashov <[hidden email]> wrote:

2016-11-29 9:35 GMT+01:00 Esteban Lorenzano <[hidden email]>:

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”. 

And if we have TableMorph then this guy should be TableMorphStore IMO.

On 29 Nov 2016, at 10:37, Aliaksei Syrel <[hidden email]> wrote:

On 29 November 2016 at 10:14, Esteban Lorenzano <[hidden email]> wrote:

And DataSource is another stuff in Cocoa, from where I borrowed the design: https://developer.apple.com/reference/appkit/nstableviewdatasource 

I know :)

However, implementation of FastTable does not correspond to Cocoa design.

A table view does not store its own data; it retrieves data values as needed from a data source to which it has a weak reference

https://developer.apple.com/reference/appkit/nstableview

This is where misconception begins. In Cocoa data source acts as real data source, it returns Object, not Morph! At the same time DataSource in FastTable returns Morphs.

Naming in Cocoa is correct and I am not arguing about it :) DataSource in FastTable != DataSource in Cocoa.

Cheers,

Alex

Called by the table view to return the data object associated with the specified row and column.

On 29 Nov 2016, at 10:36, Thierry Goubier <[hidden email]> wrote:

2016-11-29 10:14 GMT+01:00 Esteban Lorenzano <[hidden email]>:

On 29 Nov 2016, at 09:58, Aliaksei Syrel <[hidden email]> wrote:

"DataSource" is responsible for providing visual elements that represent items in a data set.

I don't see how word "Store" fits here, because DataSource does not store anything. DataSource is also not the best name since it is not a data source itself.

An object that is now called DataSource, basically just knows a single function that from mathematical point of view can be defined as follows:

f: Object -> Morph . You see, it is a mapping, not a souse or store.

Store != Storage. 

A store is a place where you go to get stuff (same as FileSystem stores: they give you access to different filesystems, as a FTDataSource gives you access to different data structures) :)

In Gtk3, you have GtkListView, and GtkListStore, for example. 

And DataSource is another stuff in Cocoa, from where I borrowed the design: https://developer.apple.com/reference/appkit/nstableviewdatasource 

So… I still rest my argument. 

Anyway… we will NEVER reach a 100% agreement. We just need to go with what fits better current design/general idea.

If you can't find the perfect meaning... just make sure there is no misunderstanding (i.e. DataSource is kind of confusing). Memorable can compensate for 'not exactly the right name'.

I like the FastTable moniker because it convey some of the design intent. As I like the core principle.

I don't like the overall design; it has a lot of the PluggableTreeMorph caracteristics, such as being a single widget trying to do everything with an API that's dozens of pages long... And we know what will be the community opinion on such widgets 10 years down the line.

It's fitting that it has a lot to relate with GTK / Cocoa designs. Places where people design huge objects because they live in a 'each function is 20 to fifty lines long' world and don't understand what fine grained objects / a live environment can be.

Thierry

 

Esteban

Cheers,

Alex

On 29 November 2016 at 09:44, Denis Kudriashov <[hidden email]> wrote:

2016-11-29 9:35 GMT+01:00 Esteban Lorenzano <[hidden email]>:

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”. 

And if we have TableMorph then this guy should be TableMorphStore IMO.