From: Peter Michaux
Subject: eshewing CLOS-style OOP in Common Lisp?
Date: 
Message-ID: <1171813833.623843.51530@h3g2000cwc.googlegroups.com>
Hi,

I'm new to Lisp in the last couple days. After reading the first few
articles about Lisp I breathed a sigh of relief. Finally the language
for which I've been searching!

Then I got to the CLOS chapters of "Practical Common Lisp" and thought
"Yikes!"

The defgeneric macro seems odd when two classes each have a method
whose names are merely homographs. For example, what is the logical
connection requiring the two "run" methods of "Athlete" and "Engine"
classes to share the same defgeneric. If I was writing in another
human language the two methods would need separate defgenerics which
would make more sense to me.

The multiple inheritance stuff in CLOS-style OOP seems way over the
top for almost everything I do.

Are there many people that just ignore the CLOS-style OOP built in
features of Common Lisp and just roll their own OOP? The first
impression I got about Lisp was it is a language that lets the
programmer work the way he wants to work. Is rolling my own message
passing OOP into (Common) Lisp considered a sin? Was incorporating
CLOS into Common Lisp a big controversy for these types of concerns?
Seems to me CLOS could have been left out as a library.

I may be late the the party but I'm happy to be here.

Thank you,
Peter

From: Ken Tilton
Subject: Re: eshewing CLOS-style OOP in Common Lisp?
Date: 
Message-ID: <KM%Bh.236$Ms3.130@newsfe10.lga>
Peter Michaux wrote:
> Hi,
> 
> I'm new to Lisp in the last couple days. After reading the first few
> articles about Lisp I breathed a sigh of relief. Finally the language
> for which I've been searching!
> 
> Then I got to the CLOS chapters of "Practical Common Lisp" and thought
> "Yikes!"
> 
> The defgeneric macro seems odd when two classes each have a method
> whose names are merely homographs. For example, what is the logical
> connection requiring the two "run" methods of "Athlete" and "Engine"
> classes to share the same defgeneric.

Well it is not as if CLOS invented the problem of how we programmers 
deal with homographs when (reasonably enough) using natural language to 
name stuff in our programs.

Me, I have an instinct that prevents me from using words just begging to 
clash with orthogonal uses. One /could/ use the package system and then 
package qualifiers all over the map, but I have never had a problem with 
homographs that could not be solved by thinking up a different name or 
prefixing the homograph with something to distinguish it.

I feel a naggum coming on. All that is really going on here is that you 
are accustomed to a particular syntactic trick (overloading based on 
signature) and are freaking out over its absence. You'll get over it -- 
Lisp just has different tricks.

> If I was writing in another
> human language

I know that is just a typo (unless there is some human language with 
defgeneric) but it makes my point: you are merely stuck in a mindset 
where overloading is The Only Way. I realize it is cute and  clever and 
lets me reuse the same word all over the place, but then I have the same 
word all over the place with the only differentiating marking being /the 
paramaters passed/ -- that's actually a little weird, if you think about 
it. I would rather see xxx-run and yyy-run and zzz-run and just be able 
to /read/ the function name to know at what I am looking.

> the two methods would need separate defgenerics which
> would make more sense to me.
> 
> The multiple inheritance stuff in CLOS-style OOP seems way over the
> top for almost everything I do.

So... don't use it? :) But, dude, it does come up. And when it does, boy 
does it suck to have to cut and paste all that code. Even languages 
without MI admit that, by providing "interfaces", which translates as 
"Oh, snap. We /do/ need MI."

Similarly, method combinations other than the default are rarely needed, 
but when they are...

> 
> Are there many people that just ignore the CLOS-style OOP built in
> features of Common Lisp and just roll their own OOP? 

Some guy named Paul Graham, I think. Oh, and Greenspun has some code you 
can use. Meanwhile, don't be such a wuss, do what most newbies do when 
they discover Lisp: break out CodeWarrior and write your own Lisp.

> The first
> impression I got about Lisp was it is a language that lets the
> programmer work the way he wants to work. Is rolling my own message
> passing OOP into (Common) Lisp considered a sin?

No, have fun, let us know when you decide to incorporate MI and 
alternate method combinations. :) Note that it will run slower than CLOS 
because it will be unoptimized by the compiler.

> Was incorporating
> CLOS into Common Lisp a big controversy for these types of concerns?
> Seems to me CLOS could have been left out as a library.

You are looking for Scheme. It comes without anything. Then you add 
everything missing as a an add-on library as you need it. When you are 
done you have something as big as CL but is unlike anyone elses's and 
none of it is optimized by the compiler.

Wasn't there an application you wanted to write?

> 
> I may be late the the party but I'm happy to be here.

Don't forget to register: http://wiki.alu.org/The_Road_to_Lisp_Survey

kenny

-- 
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
                                   -- Elwood P. Dowd

In this world, you must be oh so smart or oh so pleasant.
                                   -- Elwood's Mom
From: Peter Michaux
Subject: Re: eshewing CLOS-style OOP in Common Lisp?
Date: 
Message-ID: <1171823648.576762.82220@a75g2000cwd.googlegroups.com>
On Feb 18, 9:11 am, Ken Tilton <·········@gmail.com> wrote:
> Peter Michaux wrote:
> > Hi,
>
> > I'm new to Lisp in the last couple days. After reading the first few
> > articles about Lisp I breathed a sigh of relief. Finally the language
> > for which I've been searching!
>
> > Then I got to the CLOS chapters of "Practical Common Lisp" and thought
> > "Yikes!"
>
> > The defgeneric macro seems odd when two classes each have a method
> > whose names are merely homographs. For example, what is the logical
> > connection requiring the two "run" methods of "Athlete" and "Engine"
> > classes to share the same defgeneric.
>
> Well it is not as if CLOS invented the problem of how we programmers
> deal with homographs when (reasonably enough) using natural language to
> name stuff in our programs.
>
> Me, I have an instinct that prevents me from using words just begging to
> clash with orthogonal uses. One /could/ use the package system and then
> package qualifiers all over the map, but I have never had a problem with
> homographs that could not be solved by thinking up a different name or
> prefixing the homograph with something to distinguish it.
>
> I feel a naggum coming on. All that is really going on here is that you
> are accustomed to a particular syntactic trick (overloading based on
> signature) and are freaking out over its absence. You'll get over it --
> Lisp just has different tricks.

Good point.



> > Was incorporating
> > CLOS into Common Lisp a big controversy for these types of concerns?
> > Seems to me CLOS could have been left out as a library.
>
> You are looking for Scheme.

I think you might be right.


> It comes without anything. Then you add
> everything missing as a an add-on library as you need it. When you are
> done you have something as big as CL but is unlike anyone elses's and
> none of it is optimized by the compiler.
>
> Wasn't there an application you wanted to write?

Not really. I won't exactly be able to switch JavaScript to Lisp in
browsers any time soon. Luckily there are some similarities. Part of
my interest in rolling OOP myself is the oddball OOP in JavaScript.
However using JavaScript's prototype-based OOP is the right thing to
use for the reasons you mentioned for using CLOS. That doesn't mean
that JavaScript's OOP is good in many situations. And rolling my own
in JavaScript may be a necessity at times. Hence my skepticism of a
built in OOP paradigm like CLOS.


Thanks for you thoughts.

Peter
From: Rainer Joswig
Subject: Re: eshewing CLOS-style OOP in Common Lisp?
Date: 
Message-ID: <joswig-1051C3.20415718022007@news-europe.giganews.com>
In article <·······················@a75g2000cwd.googlegroups.com>,
 "Peter Michaux" <············@gmail.com> wrote:

> On Feb 18, 9:11 am, Ken Tilton <·········@gmail.com> wrote:
> > Peter Michaux wrote:
> > > Hi,
> >
> > > I'm new to Lisp in the last couple days. After reading the first few
> > > articles about Lisp I breathed a sigh of relief. Finally the language
> > > for which I've been searching!
> >
> > > Then I got to the CLOS chapters of "Practical Common Lisp" and thought
> > > "Yikes!"
> >
> > > The defgeneric macro seems odd when two classes each have a method
> > > whose names are merely homographs. For example, what is the logical
> > > connection requiring the two "run" methods of "Athlete" and "Engine"
> > > classes to share the same defgeneric.
> >
> > Well it is not as if CLOS invented the problem of how we programmers
> > deal with homographs when (reasonably enough) using natural language to
> > name stuff in our programs.
> >
> > Me, I have an instinct that prevents me from using words just begging to
> > clash with orthogonal uses. One /could/ use the package system and then
> > package qualifiers all over the map, but I have never had a problem with
> > homographs that could not be solved by thinking up a different name or
> > prefixing the homograph with something to distinguish it.
> >
> > I feel a naggum coming on. All that is really going on here is that you
> > are accustomed to a particular syntactic trick (overloading based on
> > signature) and are freaking out over its absence. You'll get over it --
> > Lisp just has different tricks.
> 
> Good point.
> 
> 
> 
> > > Was incorporating
> > > CLOS into Common Lisp a big controversy for these types of concerns?
> > > Seems to me CLOS could have been left out as a library.
> >
> > You are looking for Scheme.
> 
> I think you might be right.
> 
> 
> > It comes without anything. Then you add
> > everything missing as a an add-on library as you need it. When you are
> > done you have something as big as CL but is unlike anyone elses's and
> > none of it is optimized by the compiler.
> >
> > Wasn't there an application you wanted to write?
> 
> Not really. I won't exactly be able to switch JavaScript to Lisp in
> browsers any time soon. Luckily there are some similarities. Part of
> my interest in rolling OOP myself is the oddball OOP in JavaScript.
> However using JavaScript's prototype-based OOP is the right thing to
> use for the reasons you mentioned for using CLOS. That doesn't mean
> that JavaScript's OOP is good in many situations. And rolling my own
> in JavaScript may be a necessity at times. Hence my skepticism of a
> built in OOP paradigm like CLOS.

There was a JavaScript implementation for Lisp, btw.
For many years it has been in the source tree
of the Netscape browser. It has been used to prototype
new Javascript features.

http://www.koders.com/info.aspx?c=ProjectInfo&pid=7C19S1KPRPXXFXU213HRXZ7
DLC

> 
> 
> Thanks for you thoughts.
> 
> Peter
From: Ken Tilton
Subject: Re: eshewing CLOS-style OOP in Common Lisp?
Date: 
Message-ID: <bR%Bh.238$Ms3.23@newsfe10.lga>
Ken Tilton wrote:
> 
> 
> Peter Michaux wrote:
> 
>> Hi,
>>
>> I'm new to Lisp in the last couple days. After reading the first few
>> articles about Lisp I breathed a sigh of relief. Finally the language
>> for which I've been searching!
>>
>> Then I got to the CLOS chapters of "Practical Common Lisp" and thought
>> "Yikes!"
>>
>> The defgeneric macro seems odd when two classes each have a method
>> whose names are merely homographs. For example, what is the logical
>> connection requiring the two "run" methods of "Athlete" and "Engine"
>> classes to share the same defgeneric.
> 
> 
> Well it is not as if CLOS invented the problem of how we programmers 
> deal with homographs when (reasonably enough) using natural language to 
> name stuff in our programs.
> 
> Me, I have an instinct that prevents me from using words just begging to 
> clash with orthogonal uses. One /could/ use the package system and then 
> package qualifiers all over the map, but I have never had a problem with 
> homographs that could not be solved by thinking up a different name or 
> prefixing the homograph with something to distinguish it.
> 
> I feel a naggum coming on. All that is really going on here is that you 
> are accustomed to a particular syntactic trick (overloading based on 
> signature) and are freaking out over its absence. You'll get over it -- 
> Lisp just has different tricks.
> 
>> If I was writing in another
>> human language
> 
> 
> I know that is just a typo (unless there is some human language with 
> defgeneric) but it makes my point: you are merely stuck in a mindset 
> where overloading is The Only Way. I realize it is cute and  clever and 
> lets me reuse the same word all over the place, but then I have the same 
> word all over the place with the only differentiating marking being /the 
> paramaters passed/ -- that's actually a little weird, if you think about 
> it. I would rather see xxx-run and yyy-run and zzz-run and just be able 
> to /read/ the function name to know at what I am looking.
> 
>> the two methods would need separate defgenerics which
>> would make more sense to me.
>>
>> The multiple inheritance stuff in CLOS-style OOP seems way over the
>> top for almost everything I do.
> 
> 
> So... don't use it? :) But, dude, it does come up. And when it does, boy 
> does it suck to have to cut and paste all that code. Even languages 
> without MI admit that, by providing "interfaces", which translates as 
> "Oh, snap. We /do/ need MI."
> 
> Similarly, method combinations other than the default are rarely needed, 
> but when they are...
> 
>>
>> Are there many people that just ignore the CLOS-style OOP built in
>> features of Common Lisp and just roll their own OOP? 
> 
> 
> Some guy named Paul Graham, I think. Oh, and Greenspun has some code you 
> can use.

I stand corrected:

http://philip.greenspun.com/bboard/q-and-a-fetch-msg?msg_id=000tgU

"I was always more interested in application programs... I'm an 
impatient pragmatist and hate to spend time working on tools."

Well whaddya know, just another simple application programmer.

kzo

-- 
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
                                   -- Elwood P. Dowd

In this world, you must be oh so smart or oh so pleasant.
                                   -- Elwood's Mom
From: Tayssir John Gabbour
Subject: Re: eshewing CLOS-style OOP in Common Lisp?
Date: 
Message-ID: <1171830337.702886.22400@a75g2000cwd.googlegroups.com>
On Feb 18, 4:50 pm, "Peter Michaux" <············@gmail.com> wrote:
> The multiple inheritance stuff in CLOS-style OOP seems way over the
> top for almost everything I do.

You have multiple options.

* Use DEFSTRUCT.
As I recall, structures support only single-inheritance. Nice 'n weak.

* Just don't use what you don't want to use.
Keep the power in your back pocket until you're ready.

* Customize CLOS with the metaobject protocol.
Why not leverage Lisp's built-in OOP? Carve away unneeded features,
rather than building from scratch. (I suppose you'd just check for
single inheritance in compute-class-precedence-list.)

* Define your own OOP system.
Could be fun. Lots of Lisp/Scheme books do this.


> Is rolling my own message
> passing OOP into (Common) Lisp considered a sin?

Nothing's a sin in Lisp, except bad taste.

I just made that up, I have no idea. ;) But Lisp is a rather
permissive, hedonistic tool. Why not experiment? Then you'll find out
whether something's a bad idea.


> Seems to me CLOS could have been left out as a library.

Common Lisp is an object-oriented language:
CL-USER> (class-of 42)
#<BUILT-IN-CLASS FIXNUM>

But you don't have to be particularly aware of it until you care.


Tayssir
From: Tayssir John Gabbour
Subject: Re: eshewing CLOS-style OOP in Common Lisp?
Date: 
Message-ID: <1171915736.524096.180430@h3g2000cwc.googlegroups.com>
On Feb 18, 9:25 pm, "Tayssir John Gabbour"
<············@googlemail.com> wrote:
> On Feb 18, 4:50 pm, "Peter Michaux" <············@gmail.com> wrote:
> > The multiple inheritance stuff in CLOS-style OOP seems way over the
> > top for almost everything I do.
>
> You have multiple options.
>
> * Customize CLOS with the metaobject protocol.
> Why not leverage Lisp's built-in OOP? Carve away unneeded features,
> rather than building from scratch. (I suppose you'd just check for
> single inheritance in compute-class-precedence-list.)

In fact, it's ~20 lines of code, unless I'm missing something:
<http://paste.lisp.org/display/37070>

As you can see from the examples, you just need to set the :metaclass
option:
(defclass foo ()
  ((slot-1))
  (:metaclass single-inheritance-class))

And if you want syntactic sugar, you can define the macro DEFCLASS-
SINGLE or something...
(defclass-single foo ()
  ((slot-1)))


This demonstrates the Lisp motif of inviting the user into the system,
for when the defaults aren't sufficient. Maybe this motif is close to
a definition of Lisp.


Tayssir
From: Kaz Kylheku
Subject: Re: eshewing CLOS-style OOP in Common Lisp?
Date: 
Message-ID: <1171839916.732033.173160@v33g2000cwv.googlegroups.com>
On Feb 18, 7:50 am, "Peter Michaux" <············@gmail.com> wrote:
> If I was writing in another
> human language the two methods would need separate defgenerics which
> would make more sense to me.

If you were writing in some of the other popular programming
languages, you'd run into problems.

This is where Lisp gets it right with its package system:

  (defpackage :lottery ...)

  (defpackage :graphics ...)

  (in-package :lottery)

  (defgeneric draw ...) ;; this is LOTTERY::DRAW

  (in-package :graphics)

  (defgeneric draw ...) ;; this is GRAPHICS::DRAW

You can easily define a class which multiply inherits from something
that supports GRAPHICS::DRAW as well as something which supports
LOTTERY::DRAW.

Consider what happens in C++ when you try to do the same thing:

  class Lottery {
  public:
    virtual void Draw() = 0;
  };

  class GraphicsObject {
  public:
    virtual void Draw() = 0;
  };

The symbol Draw is not properly namespaced in C++; in fact the
language doesn't have a clean concept of a symbol So when you perform
inheritance from these classes, there is a clash:

  class LotteryWidget : public Lottery, public GraphicsObject {
  public:
    void Draw(); // oops, what is this?
  };

There is no such problem in Lisp, where classes do not serve as half-
baked symbol namespaces.

> The multiple inheritance stuff in CLOS-style OOP seems way over the
> top for almost everything I do.

If multiple inheritance doesn't suit the problem, don't use it.

Or are you by chance thinking of multiple dispatch? That is actually
so overwhelmingly useful that you will wonder how people work without
it.

> Seems to me CLOS could have been left out as a library.

Err, you mean it wasn't?
From: John Thingstad
Subject: Re: eshewing CLOS-style OOP in Common Lisp?
Date: 
Message-ID: <op.tnyya2fqpqzri1@pandora.upc.no>
On Mon, 19 Feb 2007 00:05:16 +0100, Kaz Kylheku <········@gmail.com> wrote:

>
> The symbol Draw is not properly namespaced in C++; in fact the
> language doesn't have a clean concept of a symbol So when you perform
> inheritance from these classes, there is a clash:
>
>   class LotteryWidget : public Lottery, public GraphicsObject {
>   public:
>     void Draw(); // oops, what is this?
>   };
>
> There is no such problem in Lisp, where classes do not serve as half-
> baked symbol namespaces.
>
>> The multiple inheritance stuff in CLOS-style OOP seems way over the
>> top for almost everything I do.
>

Erm.. C++ understands symbols. And it has namespaces.
In fact namespaces in C++ function about as packages in Lisp.

class LotteryWidget : public lottery:Lottery, public  
graphics:graphicsobject
{
   public:
   void Draw(): lottery:Draw() graphis:draw() {}
};

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Kaz Kylheku
Subject: Re: eshewing CLOS-style OOP in Common Lisp?
Date: 
Message-ID: <1171850380.147593.303570@s48g2000cws.googlegroups.com>
On Feb 18, 4:00 pm, "John Thingstad" <··············@chello.no> wrote:
> On Mon, 19 Feb 2007 00:05:16 +0100, Kaz Kylheku <········@gmail.com> wrote:
>
> > The symbol Draw is not properly namespaced in C++; in fact the
> > language doesn't have a clean concept of a symbol So when you perform
> > inheritance from these classes, there is a clash:
>
> >   class LotteryWidget : public Lottery, public GraphicsObject {
> >   public:
> >     void Draw(); // oops, what is this?
> >   };
>
> > There is no such problem in Lisp, where classes do not serve as half-
> > baked symbol namespaces.

[ snip ]

> Erm.. C++ understands symbols. And it has namespaces.
> In fact namespaces in C++ function about as packages in Lisp.

You must be working with some different C++ from the one that I have
been using to earn a living for more than a decade now.

The C++ that I think I know doesn't have anything as cleanly layered
and organized as Lisp symbols or packages.

> class LotteryWidget : public lottery:Lottery, public  
> graphics:graphicsobject
> {
>    public:
>    void Draw(): lottery:Draw() graphis:draw() {}

Is this some new syntax? The most recent C++ document I have is ISO
14882:2003, which still only defines a :: operator for scope
resolution. A colon after the function parameter list is allowed only
in constructor definitions, to introduce the member initializer list.
From: John Thingstad
Subject: Re: eshewing CLOS-style OOP in Common Lisp?
Date: 
Message-ID: <op.tnzaahy8pqzri1@pandora.upc.no>
On Mon, 19 Feb 2007 02:59:40 +0100, Kaz Kylheku <········@gmail.com> wrote:

> On Feb 18, 4:00 pm, "John Thingstad" <··············@chello.no> wrote:
>> On Mon, 19 Feb 2007 00:05:16 +0100, Kaz Kylheku <········@gmail.com>  
>> wrote:
>>
>> > The symbol Draw is not properly namespaced in C++; in fact the
>> > language doesn't have a clean concept of a symbol So when you perform
>> > inheritance from these classes, there is a clash:
>>
>> >   class LotteryWidget : public Lottery, public GraphicsObject {
>> >   public:
>> >     void Draw(); // oops, what is this?
>> >   };
>>
>> > There is no such problem in Lisp, where classes do not serve as half-
>> > baked symbol namespaces.
>
> [ snip ]
>
>> Erm.. C++ understands symbols. And it has namespaces.
>> In fact namespaces in C++ function about as packages in Lisp.
>
> You must be working with some different C++ from the one that I have
> been using to earn a living for more than a decade now.
>
> The C++ that I think I know doesn't have anything as cleanly layered
> and organized as Lisp symbols or packages.
>
>> class LotteryWidget : public lottery:Lottery, public
>> graphics:graphicsobject
>> {
>>    public:
>>    void Draw(): lottery:Draw() graphis:draw() {}
>
> Is this some new syntax? The most recent C++ document I have is ISO
> 14882:2003, which still only defines a :: operator for scope
> resolution. A colon after the function parameter list is allowed only
> in constructor definitions, to introduce the member initializer list.
>

Sorry went a bkit fast there.
class definitions do indeed use ::

void Draw(): lottery::Draw(), graphis::draw() {}


class singelton
{
   static int var;
   static int get () { return var; }
   static void set(int val) { var = val; }
}

singelton::set(5);

Anyhow I was thinking of namespaces.
These have the same function as packages except they can be nested.
(some implementations extend the package definition to allow nesting like  
ACL)

int i;

namespace A
{
    int a, b, c;

    namespace B
    {
       int i, j, k;
    }
}

int main()
{
    A::a++;
    A::B::i++;   // B's i
    ::i++;   // the global I
}


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Kaz Kylheku
Subject: Re: eshewing CLOS-style OOP in Common Lisp?
Date: 
Message-ID: <1171864310.038634.3250@p10g2000cwp.googlegroups.com>
On Feb 18, 8:19 pm, "John Thingstad" <··············@chello.no> wrote:
> On Mon, 19 Feb 2007 02:59:40 +0100, Kaz Kylheku <········@gmail.com> wrote:
> > On Feb 18, 4:00 pm, "John Thingstad" <··············@chello.no> wrote:
> >> On Mon, 19 Feb 2007 00:05:16 +0100, Kaz Kylheku <········@gmail.com>
> >> wrote:
>
> >> > The symbol Draw is not properly namespaced in C++; in fact the
> >> > language doesn't have a clean concept of a symbol So when you perform
> >> > inheritance from these classes, there is a clash:
>
> >> >   class LotteryWidget : public Lottery, public GraphicsObject {
> >> >   public:
> >> >     void Draw(); // oops, what is this?
> >> >   };
>
> >> > There is no such problem in Lisp, where classes do not serve as half-
> >> > baked symbol namespaces.
>
> > [ snip ]
>
> >> Erm.. C++ understands symbols. And it has namespaces.
> >> In fact namespaces in C++ function about as packages in Lisp.
>
> > You must be working with some different C++ from the one that I have
> > been using to earn a living for more than a decade now.
>
> > The C++ that I think I know doesn't have anything as cleanly layered
> > and organized as Lisp symbols or packages.
>
> >> class LotteryWidget : public lottery:Lottery, public
> >> graphics:graphicsobject
> >> {
> >>    public:
> >>    void Draw(): lottery:Draw() graphis:draw() {}
>
> > Is this some new syntax? The most recent C++ document I have is ISO
> > 14882:2003, which still only defines a :: operator for scope
> > resolution. A colon after the function parameter list is allowed only
> > in constructor definitions, to introduce the member initializer list.
>
> Sorry went a bkit fast there.
> class definitions do indeed use ::
>
> void Draw(): lottery::Draw(), graphis::draw() {}
>
> class singelton
> {
>    static int var;
>    static int get () { return var; }
>    static void set(int val) { var = val; }
>
> }
>
> singelton::set(5);
>
> Anyhow I was thinking of namespaces.
> These have the same function as packages except they can be nested.
> (some implementations extend the package definition to allow nesting like
> ACL)
>
> int i;
>
> namespace A
> {
>     int a, b, c;
>
>     namespace B
>     {
>        int i, j, k;
>     }
>
> }

These aren't symbol namespaces, but rather denotation namespaces. THe
identifiers a b and c are still just a, b and c. They cannot just name
anything you want; they can only name file-scope entities. For
instance, A::b could never refer to a class member, if A is a
namespace.

Moreover, given

 namespace Lottery { class Game { virtual void Draw(); }; }

 namespace Graphics { class Object { virtual void Draw(); }; }

you can do this:

 class LotteryGameWidget : public Lottery::Game, public
Graphics::Object {
   virtual void Draw();
 };

There is an ambiguity w.r.t Draw(), even though it comes from
different classes in different namespaces. The Draw() defined in
LotteryGameWidget will shadow the Draw() functions defined in Lottery
and Graphics. In addition, it overrides both of them, which isn't what
you want: you want two separate overrides.

The rules of C++ are such that Draw is treated as an independent name
some of the time, and class scoped at other times.

One way out of this one is to do a silly renaming through intermediate
classes:

  class GameDrawAdapter : public Game {
    virtual void GameDraw() = 0;
    virtual void Draw() { GameDraw(); }
  };

Likewise for the other class. Then inherit from these intermediaries,
and then you have the GameDraw and ObjectDraw functions that you can
override. Callers using Draw can use scope resolution to pick which
base's Draw they are calling. Yuck!

This comes right from the old Brown Book (_C++ Annotated Reference
Manual_, Stroustrup & Ellis), section 10.11c.

My point is that Lisp doesn't suffer from this type of braindamage.
The two DRAW-s will be different symbols in separate packages.
Inheritance, etc, are based on straight symbol identity. Problem
solved. Or should we say, problem not introduced.
From: Pascal Bourguignon
Subject: Re: eshewing CLOS-style OOP in Common Lisp?
Date: 
Message-ID: <877iufa0lc.fsf@thalassa.informatimago.com>
"Peter Michaux" <············@gmail.com> writes:

> Hi,
>
> I'm new to Lisp in the last couple days. After reading the first few
> articles about Lisp I breathed a sigh of relief. Finally the language
> for which I've been searching!
>
> Then I got to the CLOS chapters of "Practical Common Lisp" and thought
> "Yikes!"
>
> The defgeneric macro seems odd when two classes each have a method
> whose names are merely homographs. For example, what is the logical
> connection requiring the two "run" methods of "Athlete" and "Engine"
> classes to share the same defgeneric. If I was writing in another
> human language the two methods would need separate defgenerics which
> would make more sense to me.

Nothing prevents you to name the generic functions: BIPEDE-RUN and ENGINE-RUN

This is not a problem specific to CLOS, in any programming language,
you have to manage the terminology.


> The multiple inheritance stuff in CLOS-style OOP seems way over the
> top for almost everything I do.
>
> Are there many people that just ignore the CLOS-style OOP built in
> features of Common Lisp and just roll their own OOP? 

There are alternative object systems running in Common Lisp.  For
example, there's KR, (Knowledge Representation).  And you can easily
design your own object system (this is a trival exercise that used to
be given to students...).  But I don't have the impression a lot of
people use an alternative object system, since CLOS is in general more
powerful than other object systems.  Note that with CLOS you can
define your own metaclasses so you can derive your own object system
inside the CLOS framework.


> The first impression I got about Lisp was it is a language that lets
> the programmer work the way he wants to work. Is rolling my own
> message passing OOP into (Common) Lisp considered a sin? 

Not at all.  But is it worth the trouble?


> Was incorporating CLOS into Common Lisp a big controversy for these
> types of concerns?  Seems to me CLOS could have been left out as a
> library.

CLOS HAS been left out as a library.  A _standard_ library.  



That said, note that generic functions are _unrelated_ to CLOS.

C/USER[129]> (defgeneric mylen (object)
               (:method ((object null))  0)
               (:method ((object cons)) (1+ (mylen (cdr object))))
               (:method ((object t))    (error "MYLEN applied to a non-proper list.")))
#<STANDARD-GENERIC-FUNCTION MYLEN>
C/USER[130]> (mylen '(a b c))
3

Not a CLOS object in sight!


This is the main differentiator between CLOS and the other object
systems: methods are not attached to objects, but to generic
functions.


> I may be late the the party but I'm happy to be here.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

"You question the worthiness of my code? I should kill you where you
stand!"
From: John Thingstad
Subject: Re: eshewing CLOS-style OOP in Common Lisp?
Date: 
Message-ID: <op.tnyfdi0hpqzri1@pandora.upc.no>
On Sun, 18 Feb 2007 16:50:33 +0100, Peter Michaux <············@gmail.com>  
wrote:

> Hi,
>
> I'm new to Lisp in the last couple days. After reading the first few
> articles about Lisp I breathed a sigh of relief. Finally the language
> for which I've been searching!
>
> Then I got to the CLOS chapters of "Practical Common Lisp" and thought
> "Yikes!"
>
> The defgeneric macro seems odd when two classes each have a method
> whose names are merely homographs. For example, what is the logical
> connection requiring the two "run" methods of "Athlete" and "Engine"
> classes to share the same defgeneric. If I was writing in another
> human language the two methods would need separate defgenerics which
> would make more sense to me.
>
> The multiple inheritance stuff in CLOS-style OOP seems way over the
> top for almost everything I do.
>
> Are there many people that just ignore the CLOS-style OOP built in
> features of Common Lisp and just roll their own OOP? The first
> impression I got about Lisp was it is a language that lets the
> programmer work the way he wants to work. Is rolling my own message
> passing OOP into (Common) Lisp considered a sin? Was incorporating
> CLOS into Common Lisp a big controversy for these types of concerns?
> Seems to me CLOS could have been left out as a library.
>
> I may be late the the party but I'm happy to be here.
>
> Thank you,
> Peter
>

In some ways separating the method from the object it works on
makes perfect sense and is nicer than the approach used in other languages.

What if you need a function to see the contents of two classes?

I C++ you would have to make a friend function in one class for
the method in the other class to use it.
If you want the method to be available in the other class as well
the that must too have declared the other friend and another function must
be written. This actually happens a lot in the implementation of streams.
With generic functions it is simple to implement this type of behaviour.
Just make a method with two class arguments one for the first class and the
second for the other.

Simularly multiple inheritance if properly implemented is a better and more
naural solutin than single inheritance and interfaces.
It is much due to the crappy implementation in C++ that Java guys chose to
discard it.

CLOS is a bit intimidating at first. And it will take some time getting  
used to.
But I recommend giving it a lot more than two days before going out to  
create
your own object system. Perhaps you will find that the power it provides
will will help your object oriented thinking.

This is not that uncommon. I see people complaining that functional  
programming is
too hard as well. Is it possible that the main problem is your  
unwillingness to do
things in a way you are not used to?

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Peter Michaux
Subject: Re: eshewing CLOS-style OOP in Common Lisp?
Date: 
Message-ID: <1171822658.496568.140870@k78g2000cwa.googlegroups.com>
Hi John,

Thanks for the reply.

On Feb 18, 9:11 am, "John Thingstad" <··············@chello.no> wrote:

[snip]

> CLOS is a bit intimidating at first. And it will take some time getting
> used to.
> But I recommend giving it a lot more than two days before going out to
> create
> your own object system. Perhaps you will find that the power it provides
> will will help your object oriented thinking.

I just wanted to get a feel for the room. If replies to my post said
50% of people ditched CLOS on a regular bases then that would be
something to really pay attention to. I will be studying CLOS much
more.


> This is not that uncommon. I see people complaining that functional
> programming is
> too hard as well. Is it possible that the main problem is your
> unwillingness to do
> things in a way you are not used to?

I'm trying Lisp voluntarily. I think the answer has to be no.


Thanks,
Peter
From: Richard M Kreuter
Subject: Re: eshewing CLOS-style OOP in Common Lisp?
Date: 
Message-ID: <87odnrosz4.fsf@progn.net>
"Peter Michaux" <············@gmail.com> writes:

> The defgeneric macro seems odd when two classes each have a method
> whose names are merely homographs. For example, what is the logical
> connection requiring the two "run" methods of "Athlete" and "Engine"
> classes to share the same defgeneric. If I was writing in another
> human language the two methods would need separate defgenerics which
> would make more sense to me.

Like this?

;; File: athlete.lisp
(defpackage athlete
  (:use :cl))

(in-package athlete)

(defgeneric run (thing event))

(defclass athlete ()
  ()

(defmethod run ((a athlete) event)
  <athlete method>)

;; EOF

;; File: engine.lisp

(defpackage engine
  (:use :cl))

(in-package engine)

(defgeneric run (thing &key))

(defclass engine ()
  ())

(defmethod run ((e engine) &key fuel)
  <engine method>)

;; EOF

Two generic functions named by two distinct symbols (both called
"run", but in different packages neither of which imports from the
other).  The different generic functions have different lambda lists,
too.

> The multiple inheritance stuff in CLOS-style OOP seems way over the
> top for almost everything I do.

Of course, nothing compels you to take advantage of multiple
inheritance in your programs, but can be a handy way to organize code.
Additionally, because of some guarantees about ordering of class
precedence and method execution, multiple inheritance turns out to be
pretty easy to use in CLOS.

> Are there many people that just ignore the CLOS-style OOP built in
> features of Common Lisp and just roll their own OOP? 

IIUC, some folks did so when CLOS was new, either because CLOS was
missing desired features, or perhaps because of performance questions
about early CLOS implementations, but not, AFAICT, in order to develop
OO systems intended to be proper subsets of what CLOS could already
do.  (Some such OO systems can be implemented using a MetaObject
Protocol, which was not standardized and is not officially part of CL,
but most implementations provide a MOP.)

> The first impression I got about Lisp was it is a language that lets
> the programmer work the way he wants to work. Is rolling my own
> message passing OOP into (Common) Lisp considered a sin? 

If you want to roll your own as a learning experience, by all means
have a good time.

If you just want to develop some programs, you can do single dispatch
and single inheritance in CLOS by simply avoiding multiple dispatch
and multiple inheritance.  It won't be message passing, exactly, but
it'll have approximately the semantics of some other OO systems.  A
bit of macrology can wrap CL's defclass/defmethod to provide a
stylistically satisfactory notation for the CLOS subset of your
preference.

If you want to be able to use other people's Lisp code, you might want
to get used to CLOS, of course.

> Was incorporating CLOS into Common Lisp a big controversy for these
> types of concerns?

I can't say whether CLOS was controversial at the time, but
incorporating object orientation into the Common Lisp standard was one
of the mandates of the ANSI X3J13 commitee.  As others have mentioned,
CLOS was something like a fifth or tenth generation object system for
most of its designers, and its core ideas had already been tested in
the Lisp community of the 80s.

> Seems to me CLOS could have been left out as a library.

Common Lisp was never meant to be small, but instead to be useful for
writing applications.  Usefulness often has less to do with being
unobjectionable than with being ubiquitous.

Have fun,
RmK
From: Rainer Joswig
Subject: Re: eshewing CLOS-style OOP in Common Lisp?
Date: 
Message-ID: <joswig-180F88.20270818022007@news-europe.giganews.com>
In article <·······················@h3g2000cwc.googlegroups.com>,
 "Peter Michaux" <············@gmail.com> wrote:

> Hi,
> 
> I'm new to Lisp in the last couple days. After reading the first few
> articles about Lisp I breathed a sigh of relief. Finally the language
> for which I've been searching!
> 
> Then I got to the CLOS chapters of "Practical Common Lisp" and thought
> "Yikes!"
> 
> The defgeneric macro seems odd when two classes each have a method
> whose names are merely homographs. For example, what is the logical
> connection requiring the two "run" methods of "Athlete" and "Engine"
> classes to share the same defgeneric. If I was writing in another
> human language the two methods would need separate defgenerics which
> would make more sense to me.

Yeah, why not.

> The multiple inheritance stuff in CLOS-style OOP seems way over the
> top for almost everything I do.

Much of CLOS will be too powerful for a beginner.

> 
> Are there many people that just ignore the CLOS-style OOP built in
> features of Common Lisp and just roll their own OOP? The first
> impression I got about Lisp was it is a language that lets the
> programmer work the way he wants to work. Is rolling my own message
> passing OOP into (Common) Lisp considered a sin? Was incorporating
> CLOS into Common Lisp a big controversy for these types of concerns?

CLOS is a second or even third generation system.
Before CLOS there were several, even widely used, object systems
for Lisp.

To list a few examples:

* Flavors. CLOS got a lot from Flavors.
* LOOPS. CLOS also got a lot from LOOPS.
* Object Lisp.
* KEE Units.

And probably a ten others, some with lots of complicated and
powerful knowledge-representation features.

CLOS had as one of the design goals that it either allows to
incorporate another object system or that it is possible
to integrate its critical features. The goal was to
make it possible to port most of the applications from
these systems to CLOS over time.

My personal feeling is that CLOS is one of the better
designed parts of Common Lisp. I haven't seen much
controversy around CLOS.

Generally you won't see other object-systems
for routine tasks in Common Lisp. There are some
systems which provide different services and which may
sometimes be integrated into CLOS.

But if you want to write an application like a graphics
editor, a mail program, a web server in Common Lisp - CLOS
is just fine.

CLOS enables some kinds of software architectures that
you might have to learn - like Mixins (which came from
Flavors).

Just another datapoint. Macintosh Common Lisp had a pretty
nice UI library (those with buttons, views, windows, ...)
written in Object Lisp. Object Lisp was a prototype-based
object system (no classes and no inheritance, but delegation
to prototypes). When CLOS came at the time of CLtL2,
this UI library got ported to CLOS. Due to good
library developers and the general good design
of CLOS, this library feels as good as before for the
application writer.


A last remark: Alan Kay (the Alan 'Smalltalk' Kay) always
speaks very highly of Lisp and he thinks that the
book "Art of the Meta-object Protocol" is one of
the best computer science books ever written. The
book describes the principles behind a Meta-object-based
implementation of CLOS. The code presented there is
very clean. Highly recommended for a more advanced
view on how you design software with Lisp/CLOS.

Alan Kay at an OOPSLA97 keynote:
"The Art of the Metaobject Protocol is the best book written in 
computing in ten years."

And who wants to argue with Alan Kay?

> Seems to me CLOS could have been left out as a library.

Not really, since CLOS is kind of operated into the language
(type/class system, ...).

> 
> I may be late the the party but I'm happy to be here.

:-)

> 
> Thank you,
> Peter
From: Tim Bradshaw
Subject: Re: eshewing CLOS-style OOP in Common Lisp?
Date: 
Message-ID: <eraijc$6rh$1$8302bc10@news.demon.co.uk>
On 2007-02-18 15:50:33 +0000, "Peter Michaux" <············@gmail.com> said:

> The defgeneric macro seems odd when two classes each have a method
> whose names are merely homographs. For example, what is the logical
> connection requiring the two "run" methods of "Athlete" and "Engine"
> classes to share the same defgeneric. If I was writing in another
> human language the two methods would need separate defgenerics which
> would make more sense to me.

Well, obviously org.tfeb.people.athlete:run and org.tfeb.engine:run are 
not actually the same thing.  CL has a package system for a reason.

> 
> The multiple inheritance stuff in CLOS-style OOP seems way over the
> top for almost everything I do.

So, um, Why use it?  Nothing is compelling you to use all the features 
of the language all the time.
From: Wade Humeniuk
Subject: Re: eshewing CLOS-style OOP in Common Lisp?
Date: 
Message-ID: <E77Ch.107445$Oa.5451@edtnps82>
Dude, been there done that...

http://www.cs.indiana.edu/scheme-repository/SCM/slib_2.html#SEC16

Written by someone named Wade Humeniuk, hmm... he seems to attribute
some of the design to CLOS.

Another....

http://chicken.wiki.br/tinyclos#Introduction

By Gregor Kiczales.  Also seems to have CLOS as an inspiration.

Another....

file://ftp.inria.fr/INRIA/Projects/icsla/WWW/Meroon.html

By Christian Queinnec


And ... And ... And...

http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/scheme/oop/0.html

Go crazy if you want, the world could always use yet another
object system.

Wade