Re: One-off history for read-string

[Marcin Borkowski <mbork@mbork.pl>]

On 2015-09-27, at 03:20, Emanuel Berg <embe8573@student.uu.se> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>> From Emacs' point of view, it's kind of read-only;
>> while read-string does write to it, it _doesn't
>> matter_ at all. But you can call it what you want.
>> I'm not very good at naming things, apparently.
>
> It is not a good policy to name things after
> properties that doesn't matter.

I didn't _name_ it that way.  I only used that unfortunate wording in
the email, as an explanation.  Seemingly, I failed with that;-).

Also, I didn't say that this property _didn't matter_.  I only said that
it doesn't matter that read-string writes to that variable.  So, while
technically it's of course both read from and written to, its
_purpose/usefulness_ lies in the fact that only the reading-from part
matters.

> Also, most often it is not a good idea to name things
> in terms of technology but rather their
> purpose/usefulness, but there are more and more
> exceptions to that rule the deeper you delve into
> technology and this might be one of them.
>
> This is client-server/remote/distributed history.

In my code, it is just

(let ((comment-history ...)) ...)

I'd be thankful if you could come up with a better, non-generic name.
But I don't see the point in doing that: the scope of the name is
limited to one let-form, whose body is one read-string invocation.  It's
pretty much self-explanatory.

>>> And how will the history be assembled if it is only
>>> clients that fetch it and then never add to it?
>>
>> Who said about never adding? ... Of course it is
>> sent to the server, by some _other_ piece of code.
>
> Then it is even more confusing to call it "read only"
> as both writing and reading is done.

Maybe, but from the standpoint of read-string, which was ALL MY ORIGINAL
POST WAS ABOUT, writing is IRRELEVANT.

I was not asking whether my code design was sane or proper or anything.
If I had asked that, I would include all other info within my first
post.  I asked a technical question of how to handle a one-off history
for read-string.  It was you who assumed that what I'm doing doesn't
make sense, based on very incomplete information about my use-case.

>> and there is _no point_ in keeping the history in
>> two places
>
> Still, there is no gain removing it unless it does
> any harm.

Yes, there is.  The DRY principle.  Also, it does some harm: the
(server-side) history _can (and frequently is) be changed by other
tools_, and then the (Emacs-side) one would be _wrong_.

>>> And again, what is the purpose of all this?
>>
>> To write an actual program which does something
>> actually useful, not to discuss endlessly about why
>> anyone might want to write such a program.
>
> I don't ask in general, I specifically ask why you
> want a server to handle the history?

It's not that I want it or not; it just works that way.  (But I want it,
too, btw.)  It is a service I'm not an author of, nor do I control it.
And there are at least two other clients besides my Emacs one (and
I personally use at least one of them also regularly!), and they all
have a "history" feature.  And it's a good thing they do, because, it is
sometimes needed.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University