gog: it should be CLOS based with cells

[Mirko Vukovic]

This is somewhat of a no-brainer, but as I have this natural tendency to avoid objects whenever possible, and sometimes even when not possible, I really wanted to convince myself that CLOS is the best way to go.

After reading The GoG book (chapters 7 and 17), I think CLOS is the way to go.  A GoG specification will be a collection of objects that can pass information to each other and to external programs.

We should also think ahead about a possibility of making it `cells' compatible.  With `cells', changing a specification will propagate the information and regenerate a graphic automatically.

So, the next task is to go through the syntax chapters and start penciling the class families and slots.  All classes should be subclasses of GoG (or some other name like that).  Don't rush that.  At my first cut I rushed a bit too fast, and ended up with a system that was uglier than it ought to have been.

Shall we use Dia to generate the class diagrams?

Mirko

[A.J. Rossini]

apologies for top-post but you mean Kenny Tilton's Cells package?

Sent from my iPod what's-a-ma-jiggy

--
You received this message because you are subscribed to the Google Groups "Common Lisp Statistics" group.
To post to this group, send email to lisp...@googlegroups.com.
To unsubscribe from this group, send email to lisp-stat+...@googlegroups.com.
Visit this group at http://groups.google.com/group/lisp-stat?hl=en.
 
 

[Mirko Vukovic]

On Friday, November 16, 2012 9:30:55 AM UTC-5, A.J. Rossini wrote:

apologies for top-post but you mean Kenny Tilton's Cells package?

Yep  - I should have been more specific.  Here is the link: http://common-lisp.net/project/cells/
 

[David Hodge]

My  copy of GoG arrived a day or so ago and I have been reading.

I will look at Chapter 7 and 17.

My OO experience has always been that the design always changes as we understand more about the domain and a lot of unnecessary work is caused with "refactoring" and associated busy work.

So, before launching into any design, lets be clear on what in GoG we would implement, what we will not and try to have a roadmap in mind so that we can reasonably place capabilities like cells (and the last time I looked at cells I could barely get  it to install, so I wonder if its any better now) and such like.

I think the first target for the roadmap is to be able to display basic graphs using gnuplot as an interim display engine - lets agree on the "basic charts" first and see what parts of GoG need to be considered.

Thoughts?

[Mirko Vukovic]

Aargh, how to reply to top-postings?  People, you are killing me :-)

On Saturday, November 17, 2012 11:00:50 PM UTC-5, David Hodge wrote:

My  copy of GoG arrived a day or so ago and I have been reading.

Alternate (possibly better) intros to GoG:  I have been going through two SPSS GoG/GPL manuals that I found on-line.  If fork my git-repo, the README.org has links to the pdf files.  They are similar, one more recent than the other, and Chapters 1 and 3 are possibly better introductions to the syntax.
 

I will look at Chapter 7 and 17.

My OO experience has always been that the design always changes as we understand more about the domain and a lot of unnecessary work is caused with "refactoring" and associated busy work.

So, before launching into any design, lets be clear on what in GoG we would implement, what we will not and try to have a roadmap in mind so that we can reasonably place capabilities like cells (and the last time I looked at cells I could barely get  it to install, so I wonder if its any better now) and such like.

Two comments

I agree with you.  That is why on the repo, I am now mainly writing text and code examples, but not real code.  I am trying to get a feel how things should look. 

Today, I laid out a class inheritance diagram (using Dia).  Not fully complelete.  It mirrors some of the specifications from the book.  The file is in the doc/developers directory. 

Regarding cells.  I did compile them on clisp + cygwin, and they work.  But they are not necessary in the first cut, or even second.  However, eventually, having cells will enable for graphics to automatically regenerate after changing a parameter.  Again, that is for the further future, and it should not impact the CLOS design.

 

I think the first target for the roadmap is to be able to display basic graphs using gnuplot as an interim display engine - lets agree on the "basic charts" first and see what parts of GoG need to be considered.

Yep.  As for basic charts, I would propose a few from the book or the manuals, and maybe a few from the Gnuplot example page.   Feel free to fork my repo, and add examples in the examples.org files.
 

Thoughts?

Thanks for joining in the adventure