Re: package frenzy
- From: Joris Bleys <jorisb@xxxxxxxxxxxxxx>
- Date: Mon, 30 May 2005 15:42:44 +0200
Hi Pascal,
Don't I know you from somewhere? ;)
Maybe, I was a bit unclear with my problem statement. The symbol is not part of the API and should remain unvisible for the users of :exporting-package. So I guess what I want to do is to make sure that the result of the call to the read-line fn returns a symbol inside the :exported-package, but I don't know how to do so. Both ep-internal-fn and ep-external-fn are defined in the package :exporting-package (using in-package).
Ok, I tried to abstract my problem a bit, trying to make the problem as clear as possible, but my attempt ended in a disaster :).
The :exporting-package really is a client. This client uses simple crlf-ended lines over a tcp-connection. Now for extracting the commands they receive, the first word of this line always resembles the command sended and is implemented in ep-internal-fn (the real name is
reply->command. It is actually implemented as a (read-from-string reply nil nil).
The ep-external-fn is of a higher-level like 'start-client' and checks the incoming commands from the server are eq to the expected command. So the comparisons are used inside the ep-external-fn and should not be visible to the user of the :exporting-package.
Maybe you want (intern string :exporting-package) instead of read-line?
This might indeed be the function I'm looking for. It seems more elegant than setting *package* by hand. Oops, just read your reply :p, so I might look very stupid now :). But I indeed want to make the read-from-string result internal. Problem is, that has got no name, as it is just past as the return value of a function straight in the eq-test.
However, doing so requires the programmer to be realy careful when employing packages. I'd like to think that calling internal functions should automagically change the *package* to the package it was internal in, but I guess there are good reasons, which I don't yet fully (and might never :)) understand, for not doing so.
But indeed this sounds like a strange attempt. It sounds as if you wanted to use packages just to get more efficient string comparisons. Wouldn't a hashtable be good enough for such a purpose?
This package is actually used to get to a higher level of commands and thus does more than a simple string comparisons. Hashtables are a good idea, but the protocol used is very straight forward and this might result in overkill, at least in the client.
Thanks for your advice and the time for writing it down!
Joris
.
- Follow-Ups:
- Re: package frenzy
- From: Brian Downing
- Re: package frenzy
- From: Pascal Costanza
- Re: package frenzy
- References:
- Re: package frenzy
- From: Pascal Costanza
- Re: package frenzy
- Prev by Date: Re: package frenzy
- Next by Date: Re: package frenzy
- Previous by thread: Re: package frenzy
- Next by thread: Re: package frenzy
- Index(es):
Relevant Pages
|