This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Simple example program to illustrate Goops




--- Neil Jerram <neil@ossau.uklinux.net> wrote:
> Right.  You would like to see a whole program
> written using GOOPS, to
> get a better idea of how an object-oriented style
> program in Guile
> fits together.

Yup.

> Well you're definitely asking in the best possible
> place,
I suppose so given that I didn't find a mailing list
about guile-oops.

> but it may
> be that such a program does not yet exist, since
> GOOPS is still a
> relatively new addition to Guile.

While reading the tutorial it said that it was an OO
system that is like CLOS but adapted to Guile/Scheme,
do you think I could find what I am looking for in a
common Lisp program using a CLOS system? Given that my
only experience with Lisp is Scheme (by SICP and
Guile) and that my only experience in functional
programming is Scheme and Caml (a ML family language
that is quite cool I think), do you thiunk it would be
hard for me to understand a CL program (I have heard
that it is quite big)???

> And another thought (enter vague, handwaving
> mode)...  I have a
> feeling that it is easier and more natural in Scheme
> than in other
> languages to mix OO and non-OO styles.

I think so too, personnaly when I was looking at the
power of OO in declarative languages like C++ (which I
don't like, mostly because of a bad teacher), and when
I was looking at the power and elegance of functional
languages I was wondering what the mix of the two
would give.

>  Even when you do find a
> substantial program that uses GOOPS, it may not
> necessarily follow
> that the program uses GOOPS in all its parts,

Thursday I rewrote a lot of parts of a project I do
for my school to use GOOPS, I used it in things that
are not OO in themselves but mostly because there were
things I didn't understood well with the module system
and I found it easier to create an object that would
have all the global variables used in different
modules rather than have many variables/functions. So
even if it is not good OO programming it still is
easier to understand for me.

>    Ok, let me comment it to see if I have understood
>    goops correctly.
> 
> Thank you for the compliment!

Don't take it personally but it wasn't a compliment,
if I would have done one I would have said "Thanks,
it's a great example" or something like that ;)

> All of your comments
> are correct ---

Well, thank YOU for the compliment

> do you mind if I keep them in my source code? ---

Not at all, and I take it as another compliment.

> except for three
> corrections/clarifications:

> 1. It is possible for (db-file-name db) to be non-#f
> and (db-port db)
> #f if the file named in db-open doesn't yet exist. 
> The named file
> will be created the first time that db-sync or
> db-close is called.

yup, exact, (set! (db-file-name db) file-name) is
calle dwhatever the result of the if nested inside the
preceeding set! is.


> 2. mkpath is like mkdir, except that it creates all
> the required
> intervening directories:

>     ;; mkpath PATH
>     ;;
>     ;; Create the sequence of directories required
> for the pathname PATH.
>     ;; The component of PATH after the last forward
> slash is interpreted
>     ;; as a file name, not as a directory path
> component.  This makes it
>     ;; convenient to call mkpath with the full file
> name of a file that
>     ;; you are about to create, as a way of ensuring
> that the containing
>     ;; directories exist.

So it's a little bit different from mkdir -p givne
that mkdir -p just create directories (at least under
OSF1)

> 3. The term "generic method" is incorrect.  A
> "generic function" is a
> collection of "methods" (or sometimes "generic
> function methods").  A
> generic function is what you apply to a set of
> arguments in the code.
> Application of a generic function considers the
> types of the
> arguments, and the methods that belong to the
> generic function, and
> works out which of the methods should be applied to
> those arguments.

Ok, terminology error, so the generic function is the
dispatch center that select the correct method.

> ... And I only used map in db-close because I didn't
> know about
> for-each at the time!  for-each would indeed be
> clearer here, since I
> am interested in side effects, not in the mapped
> values.

And I find it more easy to understand than map, just
because the name "for-each" is easier to understand
even for somebody that never saw it before (IMHO).

> Taking this code on its own, there is no benefit in
> using generic functions.

That's what I thought, but there may have been some
other thing about it not covered by the tutorial.

> But a very common idea with databases is
> to have several different database implementations 
> that all support the same
> interface.  So that's what I had in mind.

That makes sense given that it is exactly the kind of
thing we are waiting from a generic function: not to
care that much about the underlying implementation.

> If you're
> interested, this other implementation is at
> http://www.ossau.uklinux.net/hierarchical.scm.)

Ok, thanks

> (For completeness w.r.t. databases, I should say
> that there are already several proper database
> implementations for Guile

There is a mention of a guile-db mailing list on
Guile's page.

> - see Greg Harvey's projects page,

Is there a Guile project he isn't implicated in ?? ;)

> and that there was discussion on the
> list a few months ago about implementing a generic
> database interface with multiple implementations
> along the lines of Perl's DBI. 

That would be great, and even greater if it was
Linux/Unix wide rather than language wide (I remember
reading an article saying that this kind of thing was
coming to Linux but don't remember where I saw it).

> My stuff is very basic
> compared to those.)

So it is also easier to understand. I certainly
wouldn't want to learn C programming by looking at the
Linux source.
 
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]