Re: [Pharo-dev] two question about fasttable

[Henrik Nergaard]

- 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:pharo-dev-boun...@lists.pharo.org] On Behalf Of stepharo
Sent: Monday, November 28, 2016 9:32 PM
To: pharo-dev@lists.pharo.org
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/

Re: [Pharo-dev] two question about fasttable

[Esteban Lorenzano]

Hi, 

> On 28 Nov 2016, at 21:32, stepharo  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. 
See for example here: 
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/TableView/PopulatingView-TablesProgrammatically/PopulatingView-TablesProgrammatically.html
 

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

Re: [Pharo-dev] two question about fasttable

[Esteban Lorenzano]

> On 28 Nov 2016, at 22:25, Henrik Nergaard  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

Re: [Pharo-dev] two question about fasttable

[Ben Coman]

On Tue, Nov 29, 2016 at 5:29 AM, Esteban Lorenzano 
wrote:

> Hi,
>
> On 28 Nov 2016, at 21:32, stepharo  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

Re: [Pharo-dev] two question about fasttable

[Esteban Lorenzano]

> On 29 Nov 2016, at 00:00, Ben Coman  wrote:
> 
> 
> 
> On Tue, Nov 29, 2016 at 5:29 AM, Esteban Lorenzano  > wrote:
> Hi, 
> 
>> On 28 Nov 2016, at 21:32, stepharo > > 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 

Re: [Pharo-dev] two question about fasttable

[Christophe Demarey]

Hi,

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

Re: [Pharo-dev] two question about fasttable

[p...@highoctane.be]

Even if not really matching 100%, Java has the TableModel.

https://docs.oracle.com/javase/7/docs/api/javax/swing/table/TableModel.html

https://docs.oracle.com/javase/7/docs/api/javax/swing/table/DefaultTableModel.html

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

>
> On 29 Nov 2016, at 00:00, Ben Coman  wrote:
>
>
>
> On Tue, Nov 29, 2016 at 5:29 AM, Esteban Lorenzano 
> wrote:
>
>> Hi,
>>
>> On 28 Nov 2016, at 21:32, stepharo  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
>
>
>

Re: [Pharo-dev] two question about fasttable

[Esteban Lorenzano]

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

Re: [Pharo-dev] two question about fasttable

[Denis Kudriashov]

2016-11-29 9:35 GMT+01:00 Esteban Lorenzano :

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

Re: [Pharo-dev] 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  wrote:

>
> 2016-11-29 9:35 GMT+01:00 Esteban Lorenzano :
>
>> 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.
>

Re: [Pharo-dev] two question about fasttable

[Aliaksei Syrel]

Sorry not souse, but a source :D

On 29 November 2016 at 09:58, Aliaksei Syrel  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 
> wrote:
>
>>
>> 2016-11-29 9:35 GMT+01:00 Esteban Lorenzano :
>>
>>> 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.
>>
>
>

Re: [Pharo-dev] two question about fasttable

[Esteban Lorenzano]

> On 29 Nov 2016, at 09:58, Aliaksei Syrel  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  > wrote:
> 
> 2016-11-29 9:35 GMT+01:00 Esteban Lorenzano  >:
>> 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.
> 

Re: [Pharo-dev] two question about fasttable

[Thierry Goubier]

2016-11-29 10:14 GMT+01:00 Esteban Lorenzano :

>
> On 29 Nov 2016, at 09:58, Aliaksei Syrel  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 
> wrote:
>
>>
>> 2016-11-29 9:35 GMT+01:00 Esteban Lorenzano :
>>
>>> 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.
>>
>
>
>

Re: [Pharo-dev] two question about fasttable

[Aliaksei Syrel]

On 29 November 2016 at 10:14, Esteban Lorenzano  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

Re: [Pharo-dev] two question about fasttable

[Esteban Lorenzano]

> On 29 Nov 2016, at 10:37, Aliaksei Syrel  wrote:
> 
> 
> On 29 November 2016 at 10:14, Esteban Lorenzano  > 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.

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

Re: [Pharo-dev] two question about fasttable

[Aliaksei Syrel]

On 29 November 2016 at 10:39, Esteban Lorenzano  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:
https://developer.apple.com/reference/appkit/nstableview/1528831-view

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

Cheers,
Alex

Re: [Pharo-dev] 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  wrote:

>
> On 29 November 2016 at 10:39, Esteban Lorenzano 
> 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:
> https://developer.apple.com/reference/appkit/nstableview/1528831-view
>
> I didn't find any NSView related method in DataSource. Am I looking in a
> wrong place?
>
> Cheers,
> Alex
>

Re: [Pharo-dev] two question about fasttable

[Esteban Lorenzano]

> On 29 Nov 2016, at 10:36, Thierry Goubier  wrote:
> 
> 
> 
> 2016-11-29 10:14 GMT+01:00 Esteban Lorenzano  >:
> 
>> On 29 Nov 2016, at 09:58, Aliaksei Syrel > > 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 > > wrote:
>> 
>> 2016-11-29 9:35 GMT+01:00 Esteban Lorenzano > >:
>>> 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.

Re: [Pharo-dev] two question about fasttable

[Thierry Goubier]

2016-11-29 11:07 GMT+01:00 Esteban Lorenzano :

>
> On 29 Nov 2016, at 10:36, Thierry Goubier 
> wrote:
>
>
>
> 2016-11-29 10:14 GMT+01:00 Esteban Lorenzano :
>
>>
>> On 29 Nov 2016, at 09:58, Aliaksei Syrel  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/nstable
>> viewdatasource
>>
>> 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 
>> wrote:
>>
>>>
>>> 2016-11-29 9:35 GMT+01:00 Esteban Lorenzano :
>>>
 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.
>>>
>>
>

Re: [Pharo-dev] two question about fasttable

[Ben Coman]

On Tue, Nov 29, 2016 at 3:45 PM, Esteban Lorenzano  wrote:
>
> On 29 Nov 2016, at 00:00, Ben Coman  wrote:
>
>
>
> On Tue, Nov 29, 2016 at 5:29 AM, Esteban Lorenzano 
> wrote:
>>
>> Hi,
>>
>> On 28 Nov 2016, at 21:32, stepharo  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”,

cool.  I was only reflecting back your first description (and so I
learnt something more about it)

> TableDataSource, TableStore, TableProvider are then better names, IMO…

/refers to thesaurus
TableWidgetSource, TableComponentSource, TableElementSource,
TablePartProvider, TableAspectProvider, TableFacetProvider

cheers -ben

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

Re: [Pharo-dev] two question about fasttable

[stepharo]

Ok so I never understand it that way.
What a bad name.

Stef



On 28 Nov 2016, at 22:25, Henrik Nergaard   
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





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

Re: [Pharo-dev] two question about fasttable

[stepharo]

On Mon, 28 Nov 2016 22:29:08 +0100, Esteban Lorenzano  
 wrote:



Hi,

On 28 Nov 2016, at 21:32, stepharo  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.


What a ugly name then...
Why this is not a CellMorphFactory or something like that.




I got inspired for Cocoa NSTableView design (and NSTableViewDataSource),  
and that’s what it does.See for example here:  
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/TableView/PopulatingView->TablesProgrammatically/PopulatingView-TablesProgrammatically.html

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/







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

Re: [Pharo-dev] two question about fasttable

[stepharo]

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


Please please please.
So I was always confused.




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






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

Re: [Pharo-dev] two question about fasttable

[stepharo]

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?


TableMorphStore?
Because I was really shocked to see that it returned Morph.





Esteban



Christophe






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

Re: [Pharo-dev] two question about fasttable

[stepharo]

On Tue, 29 Nov 2016 09:58:41 +0100, Aliaksei Syrel   
wrote:


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


who said that.
I could say exactly: DataSource is responsible to cut data so that they  
are delivered by row or columns.





I don't see how word "Store" fits here, because DataSource does not  
store anything.


Store in the sense of serving something.

DataSource is also not the best name since it is not a data source  
itself.


Clearly not

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



2016-11-29 9:35 GMT+01:00 Esteban Lorenzano :
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.






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

Re: [Pharo-dev] two question about fasttable

[stepharo]

On Tue, 29 Nov 2016 10:46:09 +0100, Aliaksei Syrel   
wrote:


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



If dataSource does not return view then you are right for the name.
Now in Pharo the name is wrong and may be the design too :)


Cheers,
Alex

On 29 November 2016 at 10:44, Aliaksei Syrel   
wrote:


On 29 November 2016 at 10:39, Esteban Lorenzano   
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:

https://developer.apple.com/reference/appkit/nstableview/1528831-view

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


Cheers,
Alex






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