I'm sure this is probably a topic of debate, but why even have :: ?
Seems a nice way to abstract data, declare local package functions,
etc. Either way, thanks for the quick response.
Jeff
In article <··········@odak26.prod.google.com>,
"Jeff" <········@volition-inc.com> wrote:
> I'm sure this is probably a topic of debate, but why even have :: ?
> Seems a nice way to abstract data, declare local package functions,
> etc. Either way, thanks for the quick response.
Because the designers of Common Lisp didn't believe in enforced access
rules. If you really want to get at the internals of a package, you're
allowed to, but you have to use a special syntax to make it clear that
you know you're bypassing the public interface.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin <······@alum.mit.edu> writes:
> In article <··········@odak26.prod.google.com>,
> "Jeff" <········@volition-inc.com> wrote:
>
> > I'm sure this is probably a topic of debate, but why even have :: ?
> > Seems a nice way to abstract data, declare local package functions,
> > etc. Either way, thanks for the quick response.
>
> Because the designers of Common Lisp didn't believe in enforced access
> rules. If you really want to get at the internals of a package, you're
> allowed to, but you have to use a special syntax to make it clear that
> you know you're bypassing the public interface.
Also, you have to have a way to denote internal symbols:
(defpackage :example (:use :common-lisp) (:export :run))
(in-package :example)
(defun run () (print 'my-internal-stuff))
(in-package :common-lisp-user)
(example:run)
--> EXAMPLE::MY-INTERNAL-STUFF
--
__Pascal Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he does not
want merely because you think it would be good for him. -- Robert Heinlein
Pascal Bourguignon <····@thalassa.informatimago.com> wrote in message news:<··············@thalassa.informatimago.com>...
>
> Also, you have to have a way to denote internal symbols:
>
> (defpackage :example (:use :common-lisp) (:export :run))
> (in-package :example)
> (defun run () (print 'my-internal-stuff))
> (in-package :common-lisp-user)
> (example:run)
>
> --> EXAMPLE::MY-INTERNAL-STUFF
That's a really good point!
--tim
In article <····························@posting.google.com>,
··········@tfeb.org (Tim Bradshaw) wrote:
> Pascal Bourguignon <····@thalassa.informatimago.com> wrote in message
> news:<··············@thalassa.informatimago.com>...
>
> >
> > Also, you have to have a way to denote internal symbols:
> >
> > (defpackage :example (:use :common-lisp) (:export :run))
> > (in-package :example)
> > (defun run () (print 'my-internal-stuff))
> > (in-package :common-lisp-user)
> > (example:run)
> >
> > --> EXAMPLE::MY-INTERNAL-STUFF
>
> That's a really good point!
But the syntax doesn't have to be readable, it could have been:
#<INTERNAL-SYMBOL EXAMPLE::MY-INTERNAL-STUFF>
There's precedent for this: uninterned symbols have a printed
representation, but reading it doesn't get you the same symbol.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin <······@alum.mit.edu> wrote in message news:<····························@comcast.dca.giganews.com>...
> But the syntax doesn't have to be readable, it could have been:
>
> #<INTERNAL-SYMBOL EXAMPLE::MY-INTERNAL-STUFF>
>
> There's precedent for this: uninterned symbols have a printed
> representation, but reading it doesn't get you the same symbol.
Yes, but it's nice to have read-print consistency when it's easy to
do, especially for things (internal symbols) that will often be part
of source code, which you might want to print in the debugger and,
well, anywhere really. Sometimes it's too hard obviously, but if it's
easy, it's nice to have, I think.
--tim
Jeff wrote:
> I'm sure this is probably a topic of debate, but why even have :: ?
> Seems a nice way to abstract data, declare local package functions,
> etc. Either way, thanks for the quick response.
One of the hardest things in programming libraries is to anticipate what
aspects of your library users are most interested in and how they want
to use it. In general, libraries evolve over time until they have the
right amount of flexibility and customizability on the one hand and the
right amount of stability and guarantees on the other hand. It is
unlikely that you will get these things right the first time, especially
in new domains.
There is no technical solution for solving such issues, but they can
only be solved by a "sociological process", i.e., by communicating
requirements and issues between providers and users of libraries over a
certain period of time. Most programming languages enforce an indirect
way for such communication, though. They opt for unbreakable
abstractions by default, i.e. for example, module systems whose private
definitions you cannot access at all. This forces you to communicate
requirements for more flexibility by way of natural language. On the
other hand, a few programming languages provide breakable abstractions,
and Common Lisp's package system is one example. They allow you declare
what you intend to be publicly accessible and customizable aspects of
your library without prohibiting access to internal details. This has
the advantage that users can get to solutions of concrete problems
faster because they don't need to wait for providers to update their
libraries according to your needs. Later on, they can give providers
more concrete information of what is actually needed based on actual
experience.
Both approaches have their advantages and disadvantages. In the former
approach you might not be able to solve concrete problems at all while
in the latter you may break important invariants of a library which may
lead to problems later on. The latter approach requires a higher level
of responsibility on the user's side whereas the former approach
requires a higher level of omniscience on the provider's side.
In this specific case - Common Lisp's package system - it is generally
better to use the documented, publicly accessible definitions of a
library and only revert to internals when all else fails. The
possibility to access internals just means that by default, people trust
you more than elsewhere. Don't abuse this trust.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
From: Christopher C. Stacy
Subject: Re: Difference between : and :: in a package
Date:
Message-ID: <uy8lujjwi.fsf@news.dtpq.com>
>>>>> On Thu, 08 Jul 2004 22:25:31 +0200, Pascal Costanza ("Pascal") writes:
Pascal> In this specific case - Common Lisp's package system - it is generally
Pascal> better to use the documented, publicly accessible definitions of a
Pascal> library and only revert to internals when all else fails. The
Pascal> possibility to access internals just means that by default, people
Pascal> trust you more than elsewhere. Don't abuse this trust.
Here's another way of looking at this.
When someone violates the package interface abstraction by using
the double-colon syntax, they are simultaneously indicating
a bug report and a workaround.
Other languages have no provision for either: you're just screwed!
Actually Java gives you the worst of both worlds, the protection mechanisms
prevent some useful things, while using reflection you can circumvent most
of them...
Kidding aside, I have plenty experience with running a Java server project
(see the link to dawn below). While it is nice to have a lot of checking
by the compiler, you get all the same by just grepping for "::" over your
Lisp code. But it is absolutely infuriating, if you try to patch your
running server, and fail because some functions/variables are protected.
Besides, there are some nice errors you can produce if you try to access
package protected fields from code loaded by custom classloaders.
(The compiler does not prevent you from doing so...)
On the other side, while developing Ltk and experimenting with it, it
was very helpful to gain access to everything buy just using :: instead
of :. When I needed access to an internal to try something out, I do not
have to to change my library. I only need to to it, after my experiments
show that something needs to be made public. So the Lisp convention may
actually help with creating "clean" code, as you do not need to make
everything public just in case but can publish a minimal interface to
your code, as the access to non-public symbols is there if a need
arises.
Peter
--
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
From: Alex Mizrahi
Subject: Re: Difference between : and :: in a package
Date:
Message-ID: <2l5o6iF91ed5U1@uni-berlin.de>
(message (Hello 'Jeff)
(you :wrote :on '(8 Jul 2004 12:23:35 -0700))
(
J> I'm sure this is probably a topic of debate, but why even have :: ?
J> Seems a nice way to abstract data, declare local package functions,
J> etc. Either way, thanks for the quick response.
it's nice when one doesn't have to face issues that another one manualy does
because "it seems nice" 8-]
in my opinion, public/private stuff are hints to developers - using private
stuff can be wrong and cause troubles.
however, when you know what you're doing - why not? if there is a need - for
example, for debugging or testing something - it would be very bad if
language is making some stupid restrictions. i remember i was very angry
when i needed to call some function for debug purposes - and C++ language
did not allow me to because someone thought that it's private
function(microsoft c++ debugger does not allow to call functions directly
from itself)..
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
(prin1 "Jane dates only Lisp programmers"))
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Jeff wrote:
> > I'm sure this is probably a topic of debate, but why even have :: ?
>
> Why do you have 'friend' in C++?
Every C++ programmer knows the conviction that, sooner
or later, descends with great force: that the language's
designers must have had some sort of personal vendetta
against him, some kind of deep-rooted antipathy. It seems
the only way to explain all the pain.
So, the designers took care to incorporate a few terms
with positive, warm, *friendly* connotations. "Friend"
is the most obvious example. "Protected" is another.
They're there as a subliminal countermeasure against
that feeling of paranoid despair.
Don't be taken in. C++ was designed by someone who
thinks that the reason for friendship is so that
your friends can touch your private parts. Unless
you *want* that sort of abuse, you're much better
off with Lisp.
--
Gareth McCaughan
.sig under construc
From: Karl A. Krueger
Subject: Re: Difference between : and :: in a package
Date:
Message-ID: <cd263l$o4e$1@baldur.whoi.edu>
Marco Antoniotti <·······@cs.nyu.edu> wrote:
> Jeff wrote:
>> I'm sure this is probably a topic of debate, but why even have :: ?
>
> Why do you have 'friend' in C++?
To allow people to make jokes about who gets to access your private
members.
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews