Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Common Lisp Object System (CLOS)

hescaide.me

Post reply on HN
Print view View original

81–90 of 90 posts

Re: Common Lisp Object System (CLOS)

#81

Post by bradrn »

deckard1 wrote: post #67
bradrn wrote: post #2

Alan Kay’s immortal quote about OOP: > OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them. [ http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay... ] His reference to ‘LISP’ is, of course, referring to C…

> His reference to ‘LISP’ is, of course, referring to CLOS. Definitely not. The all-caps "LISP" should be the strongest hint, but he name drops McCarthy and Carl Hewitt. McCarthy's LISP didn't have closures, so I'm thinking Alan is referring to something closer to Scheme. Which might make sense as Scheme is based on ideas from Hewitt (actors, message passing, etc.). But Alan isn't being terribly specific. You have to…

Hmm, this is interesting. Rereading that post, it looks to me like McCarthy and Hewitt are mentioned as influences rather than a manifestation of ‘OOP’ as such, and I can’t quite think of any OOP system in Lisp he could be referring to other than CLOS, but then again I don’t know sufficiently much about this area to be sure either way.

Re: Common Lisp Object System (CLOS)

#82

Post by skissane »

rmckayfleming wrote: post #60
timonoko wrote: post #9

One thing bad is the word 'class'. What it is supposed to even mean? It was some fancy concept by stupid Normen when defining Simula. My Simula teacher said that you could just translate it as "design" as in "design of car and its implementation". Anyways Python's "class" is even worse: class c: a=10 print c.a c.a=13 print c.a I cannot think any English word to replace the "class". The word I am thinking of could be…

This is why I find prototype-based object systems so much more natural. Inevitably any dynamic object system ends up having to represent classes as objects, but that retroactively opens up a lot of mind-bending complexity. Prototypes on the other hand make far more sense in a dynamic context. You just create objects that you can clone and extend. Classes just become a design pattern. It also highlights that the inter…

> Classes just become a design pattern

You haven't really got rid of classes though, you've just moved them from being explicit (something the language itself knows about) to implicit (something the developer keeps in their head). You still have some objects which play the role of "classes" (they are used as prototypes for other objects) and others which play the role of "instances" (no other object will use them as a prototype).

How much of an improvement is there really if the concept still exists, but the language itself is ignorant of it?

Re: Common Lisp Object System (CLOS)

#83

Post by ilyash »

OOP implementation in Next Generation Shell was inspired by CLOS but it's way simpler.

Defining a type: type MyType.

At any point one can declare method: F myMethod(..., mt:MyType, ...) some_code()

Anything defined by F is automatically a multimethod. When invoked, all methods in the multimethod are searched bottom up. The first one where the call arguments match the parameters (by type, with inheritance) is invoked.

That's roughly it.

Re: Common Lisp Object System (CLOS)

#84

Post by dreamcompiler »

arunix wrote: post #70
bradrn wrote: post #2

Alan Kay’s immortal quote about OOP: > OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them. [ http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay... ] His reference to ‘LISP’ is, of course, referring to C…

That reminded me of Peter Norvig's comment: > Depending on your definition, CLOS is or is not object-oriented. It doesn't support encapsulation. Lack of encapsulation would preclude the protection and hiding of state-process.

It depends on what you mean by encapsulation. CLOS classes don't own their methods, which makes CLOS much more flexible than other OOP systems. But it also means there are no "private" methods, or slots for that matter.

One way to "privatize" slots or methods is to put them in a special package, which serves as a private namespace. This doesn't prevent programmers from seeing them but it can flag any use of them as "odd" style in the source code.

Re: Common Lisp Object System (CLOS)

#85

Post by dreamcompiler »

Blackthorn wrote: post #51
zasdffaa wrote: post #31

Earlier quoted context omitted.

This "afterthought ... poorly bolted ... worse than its predecessor" is a type of HN comment that's too common. Not being a CLOS or Lisp user, I have no idea why you say this and can learn nothing from it. HN's really starting to put me off with suchlike rife blanket-damning posts that are uninformative and usually come from people who have little experience.

I don't know what their own thoughts on it are, but I personally think it's poorly bolted on because it's not actually used by the rest of the spec. There's a massive proliferation of functions acting on data structures, and none of them are generic even if they do the same thing. Poorly bolted on indeed.

The CL error system is built with CLOS. If you want to customize error handling you'll basically be writing CLOS.

But I agree about general data structures. Some of the sequence functions are generic but not enough of them. I presume this happened because circa 1990 generic dispatch was too slow to handle high speed data traversal. That's no longer true, and many libraries exist to "generify" more of Common Lisp.

Re: Common Lisp Object System (CLOS)

#86

Post by dreamcompiler »

zachbeane wrote: post #14
EdwardCoffin wrote: post #4

> I don’t know the exact implementation details of CLOS, but I feel that it can be easily replicated in C This makes me think he's barely scratched the surface of what CLOS has to offer.

The class and instance evolution protocols for starters seem not all that easy.

Exactly. Under the sheets you need class wrappers at a minimum to support these things.

Re: Common Lisp Object System (CLOS)

#87

Post by dreamcompiler »

retrac wrote: post #13
timonoko wrote: post #9

One thing bad is the word 'class'. What it is supposed to even mean? It was some fancy concept by stupid Normen when defining Simula. My Simula teacher said that you could just translate it as "design" as in "design of car and its implementation". Anyways Python's "class" is even worse: class c: a=10 print c.a c.a=13 print c.a I cannot think any English word to replace the "class". The word I am thinking of could be…

"Object"? Though that creates ambiguity between definition and instances of the definition.

In CLOS, all classes are instances but not all instances are classes.

It just so happens that the object that describes a class's slots, inheritance, etc is ... an instance. Of what? A metaclass. Which is also an instance.

It's confusing at first but eventually it all gels.

Re: Common Lisp Object System (CLOS)

#88

Post by ynniv »

ynniv wrote: post #55

I don’t know the exact implementation details of CLOS, but I feel that it can be easily replicated in C by adding the needed metadata in the structure and doing the needed type checking in the functions. And thus Objective-C was reborn

For more about ObjC:

https://gnustep.github.io/resources/documentation/ObjectivCB...

https://gnustep.github.io/developers/documentation.html

Re: Common Lisp Object System (CLOS)

#89

Post by wirrbel »

kgwgk wrote: post #71
wirrbel wrote: post #50

Earlier quoted context omitted.

Earlier lisps called it „flavour“ Defflavor instead of defclass

That makes sense only when multiple inheritance is supported though.

Flavours was single dispatch and the term for subclass was „dependent flavor“

Re: Common Lisp Object System (CLOS)

#90

Post by kgwgk »

wirrbel wrote: post #89
kgwgk wrote: post #71

Earlier quoted context omitted.

That makes sense only when multiple inheritance is supported though.

Flavours was single dispatch and the term for subclass was „dependent flavor“

Single dispatch has nothing to do with multiple inheritance.

“Many versions of Lisp added OOP through the addition of an object system called Flavors, which went beyond Smalltalk and included multiple inheritance and method combination.”

http://www.paulgraham.com/chameleon.html

“The power of flavors (and the name flavors) comes from the ability to mix several flavors and get a new flavor.”

https://franz.com/support/documentation/current/doc/flavors....

Post reply on HN