* Markku Laukkanen | Well, I consider myself a good Lisp programmer, and it took me over a | year to MASTER the Common Lisp. Of course, if you mean some C/C++ like | programming, it is possible to grab CL quite soon, but to learn CL in two | weeks.. That is a good joke.
more anecdotal evidence: I don't know how much time I spent learning the basics in Lisp, because I don't think I spent any conscious time on it. The Little Lisper lay on a table in the "pause area" where I once worked, and I picked it up and read it. reading that book was probably all it took to get most of the basics down pat. (I was somewhere between 13 and 15 at the time, probably very impressionable.) the rest has just sort of floated my way, _except_ for the more advanced aspects of CLOS and the condition system, which I still find troubling -- philosophical misalignment, I guess. (`change-class' still makes me queasy, but I was on the road to reinventing it, so I have come to conclude it can be the Right Thing when state-changes are easier to express with class changes.)
most of my journey in Common Lisp has been a series of incidents like this: a week of programming, realizing that I'm doing "grunt work", having a flash of anxiety that this is "bad", reading up on some of the stuff I didn't see any use for or didn't understand in Steele or the HyperSpec, and getting much relieved, then deleting 500 lines of code and doing that week's work over in two hours. very satisfied, I write my observations down in a "programmer's log", take the rest of the day off, and play with the concept (and my cat). two years of that, and I think I have a pretty good grasp of the language. (Scheme, in contrast, gives me the feeling that this kind of "grunt work" is _not_ bad -- Scheme programmers implement complex stuff with basic buildings blocks over and over, it seems.)
however, and this is what I find important, at no point in my using Common Lisp have I been _stumped_, or feeling that I was banging my head against a wall of minutiae or any such thing. I didn't _need_ to "master" Common Lisp to use it well. the simpler aspects of CLOS was shown to me by a friend not long ago -- it's just been saving me time, not the insufferable hair that I had to fight myself through in C++. I'm sure C++ can be as easy to learn as CLOS (Andrew Koenig's ever-present counter-argument that C++ is hard is that he can teach people this stuff in mere days), but _mistakes_ in C++ devour you (and sometimes your machine), and face you with language details you didn't even know _could_ exist. a C++ programmer might very easily see his program do something completely insane and spend the next three days trying to figure out what the hell happened, just to find that he had declared a new function and some other function was called with an argument of the wrong type and some constructor was called that he didn't even know would be affected by his new function. contrast this kind of incident (I had one of them a week, not all equally severe, when I tried to use C++ in a project in 1993) with the Common Lisp incidents I described above. C++ instilled in me a fear of mistakes that crippled my ability to experiment with the language, because I was unable to see the chain of events that led to the compiler's decisions, and I don't think I should have had to, either. Common Lisp provided me with an environment where mistakes had a _very_ low cost and offered early and precise detection to boot. this provided me with an early warning system for anything I might need to look up or study more. in C++, I would tend to think "sh*t, this _should_ work", whereas in Common Lisp, I would think "hmm, that's odd", and reach for the documentation. (I have subtracted for the normal bug-hunting in all the software I use in these descriptions.)
concluding from the way I have learned many different programming languages (and CPU's) over the years, I'd say that the _only_ thing that matters to a student of a language is that he can _trust_ the language. I can trust C, I can trust Common Lisp, but I _could not_ trust C++. most of today's programmers _don't_ trust their programming language or environment and thus have a hard time with the "trust" concept, or so it seems, anyway.
(speaking of trust, allow me a digression: people will associate feelings of distrust and the resulting powerlessness with some part of the learning experience, but not necessarily the right one. I suspect that some of this distrust from other languages is hurting Lisp. I speculate (I haven't made the slightest effort to test this idea on others, however) that when a programmer in a syntax-rich language reaches for the parens, it is because he cannot trust the compiler to do what he wants. I know from my own experience that I have had to add parens to oddly misbehaving expressions in C, but I haven't associated the pain of the debugging with the parens -- I have associated it with the infix syntax. if you associate the pain with the parens, how will you feel about a language where there are parens all over the place? now, if you're into conspiracy theories, or just enjoying them, consider that the most overloaded of all the horribly overloaded operators in C++ are the parens. if you were desinging a language, and you understood this feeling of distrust and the associative nature of the human brain, would it not be a great idea to make parens the most painful of all your operators if you wanted to keep your victims from discovering Lisp?)
#\Erik -- if you think big enough, you never have to do it
In article <3066031941459...@naggum.no> Erik Naggum <e...@naggum.no> writes: > the simpler aspects of CLOS was shown to me by a friend not long ago
Which reminds me: I used to program in Common Lisp, and hence CLOS. One thing which bothered me was the apparent lack of information hiding in using classes and methods. Did I just not understand the way to do it, or is the way somewhat non-obvious? I may have been too set in thinking in terms of public and private parts in class declarations like in C++; even so, I would like to know...
* Ola Rinta-Koski | I used to program in Common Lisp, and hence CLOS. One thing which | bothered me was the apparent lack of information hiding in using classes | and methods.
why do you want information hiding in the first place?
#\Erik -- if you think big enough, you never have to do it
In article <3066034061855177...@naggum.no> Erik Naggum <e...@naggum.no> writes: > * Ola Rinta-Koski > | I used to program in Common Lisp, and hence CLOS. One thing which > | bothered me was the apparent lack of information hiding in using classes > | and methods.
> why do you want information hiding in the first place?
I find it convenient to be able to see from the declaration which methods and slots are to be available to other classes and which are internal to the class, and even more importantly that I won't accidentally (or that someone using my class won't be tempted to) use internal parts where I shouldn't. In my opinion the environment should help me attain that goal.
I suppose there is a good reason why CLOS does not have information hiding (or if it has, does things differently from, say, C++). I just never came across that reason.
o...@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
> In short, "the way the majority of software people work" is the way to avoid. > The reality is terrifying. People of good will must strive against that way.
Even more terryfying is the fact that multi-million, even multi-billion development flops happen again and again and again, and STILL people keep on talking as if there was all these extremely structured, well- educated programmers using all these industrial-strength foolproof systems out there in the real world.
I have a theory that the main loop of one of the most popular programs of the world has a main loop that starts by asking itself whether the user just entered the 3987th palindromic prime number and ends up by investigating whether any windows are open....
* Ola Rinta-Koski | I find it convenient to be able to see from the declaration which methods | and slots are to be available to other classes and which are internal to | the class, and even more importantly that I won't accidentally (or that | someone using my class won't be tempted to) use internal parts where I | shouldn't.
the package system should be able to separate the externally visible from the internal methods and the accessor functions publish the accessability for slots, don't they? a class in CLOS doesn't contain its methods, so the class cannot hide them, either. in effect, a class in C++ is like a package as far as the accessibility of symbols are concerned.
| I suppose there is a good reason why CLOS does not have information | hiding (or if it has, does things differently from, say, C++). I just | never came across that reason.
the purported reasons for having "information hiding" in the first place have actually eluded me all these years. the "friend" concept in C++ tells me that its information hiding is at a much too fine granularity, too.
I don't know what the right level of information hiding would be, but I "grew up" with Simula (at the U of Oslo), and I still think information hiding is the least useful aspect of object-oriented programming. I think "black box" pertains to the user of a system, not that it is an intrinsic quality of the system itself.
actually, the more I think about this information hiding stuff, the more I get the feeling that it's most suitable to ex-post-facto-programming: after you have done all your design work, learned all there is to learn about the problem domain, you or somebody else sits down to code it all to a defined specification. this is not a useful model for me, since I learn about the problem while I solve it and frequently revise my opinion on the design and the implementation. (I think the same is true for _any_ creative work, and it's much more important to me to be able to explore and learn than just to code a solution. it could be that C++ is not creative work -- that the creative part should precede coding -- but I don't think that is a good approach to programming, at least not for me.)
I have never felt the need for information hiding, and it's always been in my way, but I'd like to hear of cases where it has been invaluable. I'm sure this stuff isn't _all_ drummed up by marketing boys. :)
#\Erik -- if you think big enough, you never have to do it
In article <3066042341749...@naggum.no> Erik Naggum <e...@naggum.no> writes: > the package system should be able to separate the externally visible from > the internal methods and the accessor functions publish the accessability > for slots, don't they?
So am I supposed to put every class in its own package, and do the necessary imports and exports, if I want to achieve the effect public and private parts have in C++?
> actually, the more I think about this information hiding stuff, the more I > get the feeling that it's most suitable to ex-post-facto-programming: after > you have done all your design work, learned all there is to learn about the > problem domain, you or somebody else sits down to code it all to a defined > specification.
I like to think more in terms of publishing an interface.
> I have never felt the need for information hiding, and it's always been in > my way, but I'd like to hear of cases where it has been invaluable.
Theoretically it perhaps should not play a very large part. However, my experience has unfortunately been that if it's possible to bypass a published interface and get at the internals, then someone will think of a reason, perhaps even perfectly valid (at least to them), to do so. It's at the point where someone else has to maintain that code when something breaks. Theoretically good programming practice would ensure there wouldn't be many problems. In practice, it seldom does, because all too often there is none.
And like I said, maybe I just haven't understood how to achieve similar or better results in CLOS. Certainly none of the other programmers in the project had. Not everyone who programs in Common Lisp, or of course any other language, is a fully-qualified wizard.
In article <gmn2sqe7gk....@pelle.som.fi> Ola.Rinta-Ko...@iki.fi (Ola Rinta-Koski) writes:
> I suppose there is a good reason why CLOS does not have information >hiding (or if it has, does things differently from, say, C++). I just >never came across that reason.
I believe it's a consequence of the MOP. By default, the insides of all classes, methods, and objects are visible because the MOP uses the same primitives used by programmers to allow extension of the core CLOS.
You could have information hiding in CLOS by using a little discipline:
* Define reader/writer/accessors for your slots, and don't use slot-value.
* Define a package for each of your classes, and only export the accessors and other method names you want to be public.
Granted, to do this right you'd need a little environmental support, like macros to automatically create the packages and ensure they shared and exported the right symbols, and your own versions of things like with-slots that enforced the hiding, but this is at least possible in principle. -- Internet: b...@tove.cs.umd.edu Voice: 301-352-5617
In article <5f1jr9$mu...@news.hal-pc.org>, Jonathan Guthrie <jguth...@brokersys.com> wrote:
>Although you can do this in a so-called "Object Oriented" language, the >languages in question can do it in a cleaner fashion. That is because >the natural way to extend a language is with function calls and LISP and >its variants are built around function calls and things that look like >them. In C++ (unless you do lots of operator overloading, which has its >own dangers) your "extensions" look different from the base language >whereas in LISP, it looks the same.
You make it sound like this was an afterthought in C++, where it was actually central to the language design. I would not argue with you if you said that it was a *failure* in C++, but clearly C++ was designed so that you could extend it in ways that looked "natural" as if they were built-in.
I have heard people slam languages in the Pascal/Modula family for not attempting this (as if there were not enough things to slam Pascal/Modula about!), but I am not yet convinced it really matters. By analogy: we have argued that despite the fact that prefix will look non-obvious to most people raised on infix mathematics, the learning curve to jump from infix to prefix is small. Similarly, the leap from:
matrix1 = matrix2 + matrix3;
to
matrix1.add( matrix2, matrix3)
is pretty small. I can understand the perfectionist argument that if builtins can be manipulated with a particular syntax then extensions should be manipulable with the same syntax, but sugar is sugar -- I don't consider it a serious argument against a language. I don't think that the equivalent Scheme built-in vs. extension are that much closer:
You still have to learn the name and semantics of the "matrix+" operator. That's the time consuming part (in any language), not checking whether the syntax is infix or prefix, functional or operator-based. I suspect that the real reason that Scheme and Lisp are nicely extensible languages are because the *semantics* are more regular (e.g. "Who is responsible for this object?", "When does this get destroyed?", "Is this a copy or the original object?").
> In article <3066031941459...@naggum.no> Erik Naggum <e...@naggum.no> writes: > > the simpler aspects of CLOS was shown to me by a friend not long ago
> Which reminds me: I used to program in Common Lisp, and hence CLOS. > One thing which bothered me was the apparent lack of information > hiding in using classes and methods. Did I just not understand the way > to do it, or is the way somewhat non-obvious? I may have been too set > in thinking in terms of public and private parts in class declarations > like in C++; even so, I would like to know...
Very roughly (and I know this is a flame bait :) ) In C++ you really mix the problems of "information hiding" with those of "OO programming". I.e. you really use classes for both purposes. In CL you have two separate mechanisms for doing that: packages and CLOS.
You have effectively hidden 'slot2' from use outside "THE-CLASS-PACKAGE".
Cheers -- Marco Antoniotti - Resistente Umano =========================================================================== ==== International Computer Science Institute | marc...@icsi.berkeley.edu 1947 Center STR, Suite 600 | tel. +1 (510) 643 9153 Berkeley, CA, 94704-1198, USA | +1 (510) 642 4274 x149 =========================================================================== ==== ...it is simplicity that is difficult to make. ...e` la semplicita` che e` difficile a farsi. Bertholdt Brecht
Erik Naggum wrote: > (`change-class' still makes me queasy, but I was on the road to > reinventing it, so I have come to conclude it can be the Right Thing when > state-changes are easier to express with class changes.)
I've found changing the class of an object in Smalltalk to be useful when *behavior* changes are easier to express with class changes than they are by replacing BlockClosures (lambda functions) stored by the object. When you think of the class as being part of the *state* of the object then this does not seem like such a bad idea. (Although I must admit I haven't used this idea very often in practice.)
Not knowing CLOS very well, I'm not sure how well this idea translates.
> most of my journey in Common Lisp has been a series of incidents like this: > a week of programming, realizing that I'm doing "grunt work", having a > flash of anxiety that this is "bad", reading up on some of the stuff I > didn't see any use for or didn't understand in Steele or the HyperSpec, and > getting much relieved, then deleting 500 lines of code and doing that > week's work over in two hours.
My experience learning Smalltalk was very much the same. I don't know whether I should be suprised by this. I suppose the learning of any elegant language might follow this pattern. When I replaced many day's work with a few hours' it was because after having done it once I had a much clearer understanding of the problem.
> very satisfied, I write my observations down in a "programmer's log",
Good idea. I wish I'd done the same.
> (Scheme, in contrast, gives me the feeling > that this kind of "grunt work" is _not_ bad -- Scheme programmers implement > complex stuff with basic buildings blocks over and over, it seems.)
I'm trying to learn Scheme--I'm almost finished with SICP--but I don't understand your statement. Could you elaborate?
-- Paul G. Schaaf, Jr. Smalltalk Consultant Versant Object Technology paul_sch...@acm.org
Chris.Bitm...@Alcatel.com.au (Chris Bitmead) writes: >Also, C seems to be a common denominator for most languages. If you >can talk to C, most likely you can talk to anything via C.
This is a common misunderstanding.
In pratice, you usually cannot mix two languages that both interface to C, because of incompatible behaviour of runtimes (GC, threads, stack-handling in general), object creation policy and such.
You talk to C and to C only, *not* to other languages that interface to C also. The only exceptions are languages that use runtimes written in normal C without messing with the stack, Objective-C for example. No GC, no threads.
Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %% Martin_Craca...@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536 "As far as I'm concerned, if something is so complicated that you can't ex- plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
In article <33149519.2...@acm.org> Sin-Yaw Wang <sin...@acm.org> writes: >It is possible to define a Scheme->C interface, that a Scheme function >can call a C function. I am not sure it is possible to define a >C->Scheme interface at the same time. The stumbling block is the >continuation, a concept really does not exist in C.
>Imagine a C function calling a user-level Scheme funciton that calls >call/cc. Later, another Scheme function invokes that continuation.
Are you saying in the case where the C function returned and then later a scheme function invokes the continuation?
I think as long as you specify that the continuation should not depend on any state within the C code, and as long as you don't care that the continuation eventually returns back to the C entry point, even though you jumped all over the place within the Scheme, it's ok. Seems like a reasonable restriction.
-- --------------------------------------------------------------- | Chris Bitmead.....................................9690 5727 | | Chris.Bitm...@Alcatel.com.au............................... | --------------------------------------------------------------- The sum of the intelligence of the world is constant. The population is, of course, growing.
In article <3314B47C.3...@sonic.net> Ray Dillinger <b...@sonic.net> writes: >I'm more of the opinion that the services provided by the operating >system should be unspeakably simple -- dealing perhaps with disk >sectors even rather than files -- and the entire abstraction supported >by languages then ought to be built in the language implementations.
>The benefit of course is that you'd not have people trying to do the >square-peg-in-the-round-hole business that you get with, eg, trying >to support file security on DOS, or all of the open options on UNIX, >or whatever.
That's never going to happen because the implementation of files always has to be separate from the language to allow sharing between processes.
Wouldn't it be funny if a C program couldn't read a file because it was created by Scheme?
-- --------------------------------------------------------------- | Chris Bitmead.....................................9690 5727 | | Chris.Bitm...@Alcatel.com.au............................... | --------------------------------------------------------------- The sum of the intelligence of the world is constant. The population is, of course, growing.
>>>>> "Marco" == Marco Antoniotti <marc...@crawdad.icsi.berkeley.edu> writes:
Marco> Ola.Rinta-Ko...@iki.fi (Ola Rinta-Koski) writes: Marco> both purposes. In CL you have two separate mechanisms for Marco> doing that: packages and CLOS.
Marco> You have effectively hidden 'slot2' from use outside Marco> "THE-CLASS-PACKAGE".
As an additional note, I believe Graham's "ANSI Common Lisp" book shows how to make slot1 and slot2 completely hidden so that the only way to get to them is through the accessor. The key is to make the slot names gensym'ed or something like that. I don't have the book with me, but you may want to look at it. It's one of the notes in the CLOS chapter of the book, I think.
> So, would you say that it is not possible to define such a standard > interface because it would require uniform implementation details ? > [...] > I think from the user's point of view a standarized foreign-function > interface would be great.
There is a good chance that Guile's high level C API (the gh_ interface) will be adopted by most of the Scheme implementors. I have designed with that in mind.
Huh? Being one of those Scheme implementors myself, and not having even heard about this API until just now, I find this statement a bit preposterous.
In article <3066042341749...@naggum.no> Erik Naggum <e...@naggum.no> writes:
[...] for slots, don't they? a class in CLOS doesn't contain its methods, so the class cannot hide them, either. in effect, a class in C++ is like a [...]
It should perhaps be noted that CLOS' generic functions dispatch on the type of all arguments. Thus, not only a class does not contain `its' methods, but methods do not belong to a particular class. Multimethods / generic functions obviously do not combine well with information hiding as seen in message passing OO systems (incl. C++).
a. rsrod...@wam.umd.edu (Robert Rodgers) writes: a. I found Lisp very *difficult* to parse. From what I've been told by a. people who can actually read lisp without difficulty, it took them a a. good two years or so before they had this skill polished.
b. I wrote b. This sounds very odd. It took _me_ about two weeks, and I've never met b. *anyone* with good Lisp skills who took even *one* year let alone two.
c. Markku Laukkanen <markku.laukka...@research.nokia.com> writes:
c. Well, I consider myself a good Lisp programmer, and it took me over a c. year to MASTER the Common Lisp. Of course, if you mean some C/C++ like c. programming, it is possible to grab CL quite soon, but to learn CL in c. two weeks.. That is a good joke.
The joke is exclusively of Markku Laukkanen's twisting.
I did not write that I mastered Common Lisp in two weeks. What I mastered in two weeks was the syntax of Lisp 1.5 and the elements of list processing in it.
I was not speaking of "C/C++ like programming". I learned Lisp before there *was* such a thing as C. Seriously. I had written an interpreter for a language that was a cross between Lisp and Pop-2, maintained an early BBN-Lisp port, and written a Lisp interpreter that someone else ported to the P400 (via a rewrite in Fortran, assisted by a SNOBOL program that converted the Algol...) before I ever heard of C. And _that_ was before UNIX V7.
Lisp was the fourth programming language I learned after Fortran, Algol, and PL/I. I learned it from that wonderful little "Recursive Programming Techniques" book in the Methuen series.
The code I was writing after reading that book and the Lisp 1.5 manual was Lispy, to the extent that that was possible before LET, DO, and other structured alternatives to PROG.
Mastering Common Lisp requires a thorough understanding of the built in types and functions, and the extension mechanisms. I still haven't used CLOS at all in any of my code, so cannot pretend to have mastered the whole of CLtL2. But that is quite irrelevant to a discussion of the difficulty of mastering the *syntax*.
How many people have mastered *C* at that level? I mean, by the time you've learned how to drive the 150 or so standard library functions, the 1170 or so UNIX functions, &c, you've had to master a lot more than you'll find in CLtL2. Indeed, the C++ draft standard is bigger and harder. (Indeed, the C++ standard *without* annotations is a thicker book than the Ada95 standard *with* annotations!)
In article <5f49r0$...@tove.cs.umd.edu> b...@cs.umd.edu (John R. "Bob" Bane) writes:
>> In article <gmn2sqe7gk....@pelle.som.fi> Ola.Rinta-Ko...@iki.fi (Ola Rinta-Koski) writes: >> I suppose there is a good reason why CLOS does not have information hiding >> (or if it has, does things differently from, say, C++). I just never came >> across that reason. > You could have information hiding in CLOS by using a little discipline: > * Define reader/writer/accessors for your slots, and don't use slot-value. > * Define a package for each of your classes, and only export the accessors > and other method names you want to be public. > Granted, to do this right you'd need a little environmental support, like > macros to automatically create the packages and ensure they shared and > exported the right symbols, and your own versions of things like with-slots > that enforced the hiding, but this is at least possible in principle.
I think there is an article in Journal of Object Oriented Programming (must be a 1994-96 edition) , that discusses info hiding in CLOS. I recall that the use of packages was a key feature of the scheme.
Hopefully this will give you some hints/ptrs to more info.
Regards, Steven Perryman perry...@cpd.ntc.nokia.com
* Erik Naggum | (Scheme, in contrast, gives me the feeling that this kind of "grunt | work" is _not_ bad -- Scheme programmers implement complex stuff with | basic buildings blocks over and over, it seems.)
* Paul Schaaf | I'm trying to learn Scheme--I'm almost finished with SICP--but I don't | understand your statement. Could you elaborate?
the lack of generalized functionality and the general low-level standard substrate of Scheme means that you need to implement a very large number of functions that are already there in Common Lisp. that is, this is true if you program in Scheme, not in some particular Scheme _implementation_ or Scheme + some non-standard library.
SICP doesn't teach you Scheme as much as it teaches you to think in terms consonant with the computer, and I firmly believe that programmers need to implement low-level stuff to learn how they work and how to use them, but I draw a sharp line between learning and working; learning is a continuous progression through new material, while working is mostly repeating a large number of already well-known tasks as a means to create something new or learn something so new that nobody can teach you. it's the repetitive part of work in "real life" that I find to be "grunt work", and which I want to minimize.
#\Erik -- if you think big enough, you never have to do it
In article <...> Ola.Rinta-Ko...@iki.fi (Ola Rinta-Koski) writes: > In article <...> Erik Naggum <e...@naggum.no> writes: >> * Ola Rinta-Koski >> | I used to program in Common Lisp, and hence CLOS. One thing which >> | bothered me was the apparent lack of information hiding in using classes >> | and methods. >> >> why do you want information hiding in the first place? > > I find it convenient to be able to see from the declaration which > methods and slots are to be available to other classes and which are > internal to the class, and even more importantly that I won't > accidentally (or that someone using my class won't be tempted to) use > internal parts where I shouldn't. In my opinion the environment should > help me attain that goal.
As far as slots go, one convention for implementing hiding would be to only specify accessors and readers for those slots that are meant to be public. The private slots could then be accessed internally using slot-value of the with-slots macro. This isn't quite as heavily enforced as in C++, but see below.
As far as methods go, they are tougher since they don't really belong to any particular class (as another poster noted).
> I suppose there is a good reason why CLOS does not have information > hiding (or if it has, does things differently from, say, C++). I just > never came across that reason.
There are at least two reasons that I can think of. First, the lisp programming tradition has been to allow you to do most anything and rely on the presence of good programmers and good programming practice to avoid doing bad things. (This could be called the "enough rope philosophy"). In other words, although you can easily subvert attempts to have hidden information, it is expected that a programmer would not do such subversion in most cases. The power is there to allow it in the rare (unforseen) instances where it might be necessary. In contrast, many other languages force you to either revise the public interface or forget about sharing the code and reimplement the functionality. Lisp assumes that you don't need to protect your system from the programmers. (Whether this is a wise idea or not is perhaps debatable).
The other reason, and the one with a better theoretical foundation, is that Lisp is a highly introspective language. You can find out a lot about the system by using standard Lisp function calls. For example, you can discover the names of a class' slots starting with an instance of the class. There is no standard way to do this in C++, but a lot of systems have implemented their own meta-information structures for C++ in order to enable what is built in to CLOS.
Besides, I don't think that C++ itself is fundamentally better at information hiding than CLOS. By using pointers, knowing how the compiler lays out storage for classes and method vtables, you can subvert information hiding in C++ as well. It just takes a lot more work. I suppose that one could call that an advantage.
-- Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu
In article <33160ED0.5...@acm.org>, Paul Schaaf <paul_sch...@acm.org> writes: >> Erik Naggum wrote: >> > (`change-class' still makes me queasy, but I was on the road to >> > reinventing it, so I have come to conclude it can be the Right Thing when >> > state-changes are easier to express with class changes.)
>> I've found changing the class of an object in Smalltalk to be useful when >> *behavior* changes are easier to express with class changes than they are >> you think of the class as being part of the *state* of the object then this
This is a very useful mechanism in some cases. My real-world simple example is having the classes 'employee' and 'manager', where manager inherits from employee. If someone gets promoted to a manager, their class changes, but the instance retains its same identity and any existing employee slots, like name, address, etc, carry over. The manager instance will now have different applicable methods for it than before, such as the method used to report their work hours (no longer on an hourly bases, but perhaps daily, or not at all)
[...] As an additional note, I believe Graham's "ANSI Common Lisp" book shows how to make slot1 and slot2 completely hidden so that the only way to get to them is through the accessor. The key is to make the slot names gensym'ed or something like that. I don't have the book with me, but you may want to look at it. It's one of the notes in the CLOS chapter of the book, I think.
Unintern the slot name after the definitions that refer to the slot, or use uninterned symbols as slot names. The latter option is a bit tricky, since all references to the uninterned symbol should occur within the same expression; e.g. you can wrap a PROGN around the definitions. Cf. P.Graham, ANSI CL, p.191 and note 191.
In article <1997Feb27.172251....@wavehh.hanse.de> craca...@wavehh.hanse.de (Martin Cracauer) writes: >>Also, C seems to be a common denominator for most languages. If you >>can talk to C, most likely you can talk to anything via C.
>This is a common misunderstanding.
>In pratice, you usually cannot mix two languages that both interface >to C, because of incompatible behaviour of runtimes (GC, threads, >stack-handling in general), object creation policy and such.
If two languages both have a C interface, and reasonable hooks, then you can always glue them together somehow. It may not be easy, and it may require work, but it can always be done. You may have to use mutexes around calls to the foreign language for example.
-- --------------------------------------------------------------- | Chris Bitmead.....................................9690 5727 | | Chris.Bitm...@Alcatel.com.au............................... | --------------------------------------------------------------- The sum of the intelligence of the world is constant. The population is, of course, growing.
