Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Scott Meyers: non-member functions are better encapsulation.
92 views
Skip to first unread message
Kaz Kylheku
Apr 2, 2012, 3:33:16 PM4/2/12
to
This is from a year 2000 issue of Dr. Dobbs:
http://drdobbs.com/184401197
From a CLOS perspective it is really funny, and it is material that you can
use in explaining or preaching CLOS.
The next time someone (in particular some C++ programmer) asks, how the heck
can it be object oriented and encapsulated, etc, if methods not be inside the
class? Just point to that article.
Evidently, some 12 years ago, Scott Meyers came to the conclusion that a class
with "n+1" public methods is less encapsulated tha one with "n" methods.
So, for the sake of encapsulation, you should prefer to introduce new
functions as non-member functions wherever this is possible.
*Cough*. Generic functions, anyone?
Thus, since in CLOS everything is a "nonmember" function, it must provide ideal
encapsulation.
http://drdobbs.com/184401197
From a CLOS perspective it is really funny, and it is material that you can
use in explaining or preaching CLOS.
The next time someone (in particular some C++ programmer) asks, how the heck
can it be object oriented and encapsulated, etc, if methods not be inside the
class? Just point to that article.
Evidently, some 12 years ago, Scott Meyers came to the conclusion that a class
with "n+1" public methods is less encapsulated tha one with "n" methods.
So, for the sake of encapsulation, you should prefer to introduce new
functions as non-member functions wherever this is possible.
*Cough*. Generic functions, anyone?
Thus, since in CLOS everything is a "nonmember" function, it must provide ideal
encapsulation.
Barry Margolin
Apr 2, 2012, 4:00:28 PM4/2/12
to
In article <201204021...@kylheku.com>,
There's a big difference.
His point was to minimize the number of functions that can access the
implementation directly, and would have to be modified if the
implementation changes. But in CLOS, any function can access the
implementation (i.e. call SLOT-VALUE). So from the perspective of C++
programming, every function in CLOS is a member function, and there's no
encapsulation.
In CLOS, as with much of the rest of Common Lisp, we address this
through culture and convention rather than restrictive language design.
We say that even though you CAN access slots directly, you SHOULDN'T.
You should use accessor methods, which can be replaced when the
implementation changes. But we don't have any special way of
distinguishing these methods, like you do in C++.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
His point was to minimize the number of functions that can access the
implementation directly, and would have to be modified if the
implementation changes. But in CLOS, any function can access the
implementation (i.e. call SLOT-VALUE). So from the perspective of C++
programming, every function in CLOS is a member function, and there's no
encapsulation.
In CLOS, as with much of the rest of Common Lisp, we address this
through culture and convention rather than restrictive language design.
We say that even though you CAN access slots directly, you SHOULDN'T.
You should use accessor methods, which can be replaced when the
implementation changes. But we don't have any special way of
distinguishing these methods, like you do in C++.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Juanjo Garcia
Apr 4, 2012, 7:19:24 AM4/4/12
to
Correct me if I'm wrong:
In Common Lisp, encapsulation is considered
as a concept completely independent from the
object system.
There are 2 ways of getting encapsulation,
one is by using the package system and
the other is by using closures.
From time to time, I see lispers
(even notable ones like Greenblat)
confused by other cultures unfounded
prejudice that they must be related concepts.
In Common Lisp, encapsulation is considered
as a concept completely independent from the
object system.
There are 2 ways of getting encapsulation,
one is by using the package system and
the other is by using closures.
From time to time, I see lispers
(even notable ones like Greenblat)
confused by other cultures unfounded
prejudice that they must be related concepts.
Pascal J. Bourguignon
Apr 4, 2012, 8:47:40 PM4/4/12
to
Juanjo Garcia <kod...@gmail.com> writes:
> Correct me if I'm wrong:
>
> In Common Lisp, encapsulation is considered
> as a concept completely independent from the
> object system.
>
> There are 2 ways of getting encapsulation,
> one is by using the package system and
> the other is by using closures.
FSVO "encapsulation". And also uninterned symbols.
> Correct me if I'm wrong:
>
> In Common Lisp, encapsulation is considered
> as a concept completely independent from the
> object system.
>
> There are 2 ways of getting encapsulation,
> one is by using the package system and
> the other is by using closures.
Ie. the point is that in a highly introspective system (and CL is not
very introspective actually, other lisps, or implementations may be way
more introspective), encapsulation is just lip service.
So CL recognize it, and doesn't provide any feature to _enforce_
encapsulation: this is archived only by way of convention and programmer
discipline.
Nothing prevents you to write:
(list (pack:method obj (pack:public-accessor obj))
(pack::protected-method? obj (pack::protected-accessor other-obj))
(pack::%private-method?? obj (slot-value other-obj 'pack::%private-slot)))
Eg. while CL doesn't provide any way to introspect a closure,
implementation may provide some way, in particular with their debugger.
So it's only programmer discipline (or ignorance) that prevents access
to the enclosed bindings. Or the garbage collector could provide a
function to scan all the live objects on the heap, which would include
uninterned symbols. Or you coul have access to low-level pointers and
scan the memory yourself. etc.
> From time to time, I see lispers
> (even notable ones like Greenblat)
> confused by other cultures unfounded
> prejudice that they must be related concepts.
there's no classes or objects. There is Modula-3 which provides classes
and objects, but still uses modules to encapsulate, ie. to allow access
to exported symbols and prevent access to internal symbols. Same with
Object Pascal which distinguishes classes and units.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
0 new messages