November 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] two question about fasttable

by Aliaksei Syrel

On 29 November 2016 at 10:14, Esteban Lorenzano <estebanlm(a)gmail.com> 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

Nov. 29, 2016

Re: [Pharo-dev] two question about fasttable

by Thierry Goubier

2016-11-29 10:14 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 29 Nov 2016, at 09:58, Aliaksei Syrel <alex.syrel(a)gmail.com> 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 <dionisiydk(a)gmail.com> > wrote: > >> >> 2016-11-29 9:35 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >>> 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. >> > > >

Nov. 29, 2016

Re: [Pharo-dev] two question about fasttable

by Esteban Lorenzano

> On 29 Nov 2016, at 09:58, Aliaksei Syrel <alex.syrel(a)gmail.com> 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 <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 <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > > 2016-11-29 9:35 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >> 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. >

Nov. 29, 2016

Re: [Pharo-dev] two question about fasttable

by Aliaksei Syrel

Sorry not souse, but a source :D On 29 November 2016 at 09:58, Aliaksei Syrel <alex.syrel(a)gmail.com> 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 <dionisiydk(a)gmail.com> > wrote: > >> >> 2016-11-29 9:35 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >>> 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. >> > >

Nov. 29, 2016

Re: [Pharo-dev] two question about fasttable

by 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 <dionisiydk(a)gmail.com> wrote: > > 2016-11-29 9:35 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> 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. >

Nov. 29, 2016

Re: [Pharo-dev] two question about fasttable

by Denis Kudriashov

2016-11-29 9:35 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > 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.

Nov. 29, 2016

Re: [Pharo-dev] How to report website text bugs?

by Esteban Lorenzano

yes, but no needâ¦ I already fixed it :) > On 29 Nov 2016, at 09:29, phil(a)highoctane.be wrote: > > Report them on pharo.fogbugz.com <http://pharo.fogbugz.com/> > > http://pharo.org/contribute-report-bug <http://pharo.org/contribute-report-bug> > > Use Project: Websites as the reference. > > Phil > > On Tue, Nov 29, 2016 at 12:57 AM, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: > Hi Guys - how is the best way to report website and text bugs? > > As I know the English is not always a first language (and you guys are busy writing code anyway) - its up to us native English speakers to chip in where we can. > > I was pleased to get the notice that on OSX Sierra I need to do something extra to get Pharo to work, however the text could be slightly corrected eg. (Bolded words changed) > > Are you using macOS Sierra? > Due to changes in security policies of macOS, you will need to put the VM in the /Applications folder. > We are working to fix this temporary inconvenience. > > > Also - the Hello world command line example on the front page doesnât work on a standard Terminal on a Mac (you get an error: > > $ ./pharo Pharo.image eval "Stdio stdout << 'Hello,World!'" > -bash: !'": event not found > > The culprit is of course the â!â Character so a better example might be: > > $ ./pharo Pharo.image eval "Stdio stdout << 'Hello World'" > Hello WorldStdioStream: 'stdout' > > Although, in this case, is it expected that the return string is merged with some other output text (e.g. the StdioStream:â¦.?). I think its an impressive example, but it just doesnât quite look right? > > > Tim >

Nov. 29, 2016

Re: [Pharo-dev] two question about fasttable

by Esteban Lorenzano

> On 29 Nov 2016, at 09:11, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > Hi, > >> Le 29 nov. 2016 Ã 08:45, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> a Ã©crit : >> >>> >>> On 29 Nov 2016, at 00:00, Ben Coman <btc(a)openInWorld.com <mailto:btc@openInWorld.com>> wrote: >>> >>> >>> >>> On Tue, Nov 29, 2016 at 5:29 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>> Hi, >>> >>>> On 28 Nov 2016, at 21:32, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> 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

Nov. 29, 2016

Re: [Pharo-dev] two question about fasttable

by phil＠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/DefaultTableMod… 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 <estebanlm(a)gmail.com> wrote: > > On 29 Nov 2016, at 00:00, Ben Coman <btc(a)openInWorld.com> wrote: > > > > On Tue, Nov 29, 2016 at 5:29 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> Hi, >> >> On 28 Nov 2016, at 21:32, stepharo <stepharo(a)free.fr> 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 > > >

Nov. 29, 2016

Re: [Pharo-dev] How to report website text bugs?

by phil＠highoctane.be

Report them on pharo.fogbugz.com http://pharo.org/contribute-report-bug Use Project: Websites as the reference. Phil On Tue, Nov 29, 2016 at 12:57 AM, Tim Mackinnon <tim(a)testit.works> wrote: > Hi Guys - how is the best way to report website and text bugs? > > As I know the English is not always a first language (and you guys are > busy writing code anyway) - its up to us native English speakers to chip in > where we can. > > I was pleased to get the notice that on OSX Sierra I need to do something > extra to get Pharo to work, however the text could be slightly corrected > eg. (Bolded words changed) > > Are you *using* macOS Sierra? > Due to changes in security policies of macOS, you will need to put the VM *in > the* /Applications folder. > We are working to fix this temporary *inconvenience*. > > > Also - the Hello world command line example on the front page doesnât work > on a standard Terminal on a Mac (you get an error: > > $ ./pharo Pharo.image eval "Stdio stdout << 'Hello,World!'" > -bash: !'": event not found > > The culprit is of course the â!â Character so a better example might be: > > $ ./pharo Pharo.image eval "Stdio stdout << 'Hello World'" > Hello WorldStdioStream: 'stdout' > > Although, in this case, is it expected that the return string is merged > with some other output text (e.g. the StdioStream:â¦.?). I think its an > impressive example, but it just doesnât quite look right? > > > Tim >

Nov. 29, 2016