two question about fasttable

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

two question about fasttable

stepharo
Hi

- Could we rename FastTable into Table?

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

Stef



--
Using Opera's mail client: http://www.opera.com/mail/

Reply | Threaded
Open this post in threaded view
|

Re: two question about fasttable

Henrik Nergaard-2
- Then I miss an important design point. Why datasource returns Morph?
Do you mean from #cellColumn:row: ?

- I do not get why a data source should return UI element. To me it violates layers.
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.

Best regards.
Henrik

-----Original Message-----
From: Pharo-dev [mailto:[hidden email]] On Behalf Of stepharo
Sent: Monday, November 28, 2016 9:32 PM
To: [hidden email]
Subject: [Pharo-dev] two question about fasttable

Hi

- Could we rename FastTable into Table?

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

Stef



--
Using Opera's mail client: http://www.opera.com/mail/


Reply | Threaded
Open this post in threaded view
|

Re: two question about fasttable

EstebanLM
In reply to this post by stepharo
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.

I got inspired for Cocoa NSTableView design (and NSTableViewDataSource), and that’s what it does. 
This function: 
- (NSView *)tableView:(NSTableView *)tableView
   viewForTableColumn:(NSTableColumn *)tableColumn
                  row:(NSInteger)row

is the equivalent of our FTDataSource>>cellColumn:row:

Esteban


Stef



--
Using Opera's mail client: http://www.opera.com/mail/


Reply | Threaded
Open this post in threaded view
|

Re: two question about fasttable

EstebanLM
In reply to this post by Henrik Nergaard-2

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. 

this ^ :)

Esteban

Reply | Threaded
Open this post in threaded view
|

Re: two question about fasttable

Ben Coman
In reply to this post by EstebanLM


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 

Reply | Threaded
Open this post in threaded view
|

Re: two question about fasttable

EstebanLM

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 :)

Esteban


cheers -ben 

Reply | Threaded
Open this post in threaded view
|

Re: two question about fasttable

demarey
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
Reply | Threaded
Open this post in threaded view
|

Re: two question about fasttable

philippeback
In reply to this post by EstebanLM
Even if not really matching 100%, Java has the TableModel.


In the MVVM buzzword land, ViewModel seems all the rage.

Some inspiration from Swift: https://github.com/tbergmen/TableViewModel

Phil

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

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 :)

Esteban


cheers -ben 


Reply | Threaded
Open this post in threaded view
|

Re: two question about fasttable

EstebanLM
In reply to this post by demarey

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.

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

Reply | Threaded
Open this post in threaded view
|

Re: two question about fasttable

Denis Kudriashov

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.
Reply | Threaded
Open this post in threaded view
|

Re: two question about fasttable

Aliaksei Syrel
"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.

Reply | Threaded
Open this post in threaded view
|

Re: two question about fasttable

Aliaksei Syrel
Sorry not souse, but a source :D 

On 29 November 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.


Reply | Threaded
Open this post in threaded view
|

Re: two question about fasttable

EstebanLM
In reply to this post by Aliaksei Syrel

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.

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.


Reply | Threaded
Open this post in threaded view
|

Re: two question about fasttable

Thierry Goubier


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.



Reply | Threaded
Open this post in threaded view
|

Re: two question about fasttable

Aliaksei Syrel
In reply to this post by EstebanLM

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
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
Reply | Threaded
Open this post in threaded view
|

Re: two question about fasttable

EstebanLM

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

not true. 
it returns an NSView.

Esteban 


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

Cheers,
Alex

Reply | Threaded
Open this post in threaded view
|

Re: two question about fasttable

Aliaksei Syrel

On 29 November 2016 at 10:39, Esteban Lorenzano <[hidden email]> wrote:
not true. 
it returns an NSView.

Could you name a method (send a link to a documentation) that is implemented by DataSource and returns an NSView?

According to documentation NSView for an item at row/column index is created and returned by NSTableView:

I didn't find any NSView related method in DataSource. Am I looking in a wrong place?

Cheers,
Alex
Reply | Threaded
Open this post in threaded view
|

Re: two question about fasttable

Aliaksei Syrel
Called by the table view to return the data object associated with the specified row and column.
https://developer.apple.com/reference/appkit/nstableviewdatasource/1533674-tableview

Cheers,
Alex

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

On 29 November 2016 at 10:39, Esteban Lorenzano <[hidden email]> wrote:
not true. 
it returns an NSView.

Could you name a method (send a link to a documentation) that is implemented by DataSource and returns an NSView?

According to documentation NSView for an item at row/column index is created and returned by NSTableView:

I didn't find any NSView related method in DataSource. Am I looking in a wrong place?

Cheers,
Alex

Reply | Threaded
Open this post in threaded view
|

Re: two question about fasttable

EstebanLM
In reply to this post by Thierry Goubier

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.

widgets are huge objects by definition (specially a table… or a text editor). 
but well, you can propose a refactor… Pharo 7 will be the good moment for it :)

Esteban


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.

Reply | Threaded
Open this post in threaded view
|

Re: two question about fasttable

Thierry Goubier


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

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.

widgets are huge objects by definition (specially a table… or a text editor). 

It would be really great to make them a bit more composable / modular...
 
but well, you can propose a refactor… Pharo 7 will be the good moment for it :)

Ah, if only I had the time...

Thierry
 

Esteban


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.


12