Hi Stepharo,

Thanks very much for your feedback.

On Wed, Apr 20, 2016 at 08:24:55AM +0200, stepharo wrote:
> Le 19/4/16 16:41, Alistair Grant a écrit :
> > Hi All,
> > 
> > I've been working on the ODS importer for the Tabular package
> > (http://ss3.gemtalksystems.com/ss/Tabular.html) and wanted to offer the
> > opportunity for feedback before updating the code as it is likely to
> > affect existing users.
> 
> cool
> > While the class structure of Tabular is designed to support multiple
> > formats in theory, in practice the existing implementation is quite XLSX
> > specific.
> > 
> > I think that trying to extend the core Tabular classes to be a superset
> > of all the functionality from the various formats (XLSX, ODS, etc.) will
> > not be practical - I don't have a good enough understanding of all the
> > formats to implement it in the first place, and certainly not to resolve
> > conflicting attributes in any sensible way.
> > 
> > The approach I've taken is to make the existing classes, which were
> > intended to be format independent, abstract and create format specific
> > subclasses, i.e. the existing TabularCell and TabularStyle become:
> > 
> >      TabularCell
> >          TabularXLSXCell
> >          TabularODSCell
> >      TabularStyle
> >          TabularXLSXStyle
> >          TabularODSStyle
> > 
> > The modified code runs the existing test suite successfully without any
> > modifications.
> 
> Sounds correct and if you add a factory or specific importer then you get it
> :)

Yep, the importers were already format specific.


> > 
> > I welcome any comments, suggestions, etc.
> > 
> > 
> > Also, Tabular currently loads PharoExtras/XMLWriter and
> > PharoExtras/XMLParser as dependencies.
> This is good because these are the clean versions.
> 
> 
> > I've been using XMLSupport,
> > which I thought I remembered reading was a replacement for XMLWriter and
> > XMLParser, but now I can't find the reference.  Is one generally
> > preferred over the other?
> 
> XMLSupport is a union of too many things. Modularity is not stupid Union.

Thanks, I'll switch to XMLParser and XMLWriter.

I've also realised that I built all my changes on an older version of
Tabular. :-(

So, time to learn more about Monticello...  Reading the Updated PbE is
helpful, however I did notice one thing which doesn't match my
experience.  On page 150 it is discussing how you can't lose code...

"This is because all of the code that you executed is saved in the
.changes file. All of it!  This includes one liners that you evaluate in
a workspace, as well as code that you add to a class while programming."

Should "workspace" be changed to "playground"?

My experience has been that code evaluated in the playground is *not*
saved to the changes file (Pharo 4.0 and 5.0).  Is there a way to tell
Pharo to save evaluated code to the changes file?  (I admit to being
lazy and not trying to figure this one out myself yet).


Finally, in Section 8.2 on versions of a method, my impression from
reading the section was that it would always display all versions of a
method, i.e. I have 24 versions of a package in my package cache, so
expected to see each modification to each method in the package.
However because I had switched to a new image and loaded the newest
package, only the latest version was shown.

Re-reading the section, it does say that you can see each version that
you save, however it might be worthwhile adding a sentence that
explicitly states that only versions loaded into the image are shown (I
guess it is actually versions in the changes file?).


Thanks again,
Alistair



# vim: tw=72

Reply via email to