[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: declare function/macro private
From: |
Paul W. Rankin |
Subject: |
Re: declare function/macro private |
Date: |
Mon, 07 Jun 2021 14:49:54 +1000 |
User-agent: |
Purely Mail via Roundcube/1.4.10 |
On Sun, 06 Jun 2021 22:54:41 -0400, Stefan Monnier wrote:
No, I'm still wondering what it is you find to be different.
My current guess is that you fear that "--" has currently been used
carelessly and imposing a more "structured" meaning to it after the
fact
will hence introduce problems, whereas your declaration would come
right
away with an associated "precise" meaning.
I was *so sure* I had made this clear having said it four times, but
okay: I do not wish to impose or change anything.
Now, I *know* that someone on emacs-devel will read that and decide it
means "he wants to impose or change something" so again, for that
reader: please put down your pitchfork, re-read the initial email,
understand that it does not suggest imposing or changing anything.
What I am suggesting is that if a programmer wishes to make it
abundantly and extraordinarily clear that a function/macro is internal
and should never be used outside of this program, they would have this
extra declaration which they could explicitly set that would provide a
simple and discoverable warning to other elisp programmers.
An optional addition. That's it. No one forces anyone to use it, just
like we have the interactive-only declaration and no one's house burnt
down.
If so, I agree to some extent, but:
- As mentioned your declaration would suffer from the difficulty of
clarifying "internal to what" since sometimes a function is internal
to a file, sometimes to a multifile package and sometimes to a subset
of a file. Of course, that can be solved by adding an extra argument
to your annotation, but:
I think internal to the file is easiest but if there's some easy way to
make it "internal to the package/library" then cool. But as you've
already said, does Elisp have a definition of what is and isn't part of
a package/library? Not really. It does have plenty of things that work
file-local though.
- your annotation is placed on those functions that are internal, which
(as a coder) are those functions which I'd rather not burden with too
much extra annotations, otherwise I'll just not bother declaring them
as internal (which is what we had before the "--" convention).
For you nothing would change.
- As long as the effect is just a few font-lock-warning faces here and
there, I think the problem is harmless enough (and it does point to
real misfeatures in many cases, so it would help improve the code).
Cool.
Yes, currently it's a bit of a wild west because the "--" has no
effect,
but maybe it's time to impose some order on this, indeed.
I am not suggesting imposing anything. Trying to retroactively impose
some definitive meaning upon people's use of "--" is, as I said, the
path to ruin.
Others do not necessarily know what I know, i.e. while I may know that
"--" is a convention that means "internal" in Elisp, other people may
not (or likely do not). I suspect many programmers use it just because
they've seen it used in other packages. And given that Elisp does not
have any explicit definition of what is "internal" it would make little
sense to impose one now and say "oh well that's what we meant all
along".
So could someone prove how clever they are by making some sort of
heuristic code to treat anything with "--" as internal? Of course. Would
this have the net effect of raising false positives, confusing people,
sparking endless angry emacs-devel threads, kicking your dog, and
increasing bug reports? Absolutely.
This is not and was never part of my suggestion.
Also I just dislike computer heuristics.
It's not a heuristic.
Okay.
But "file" is the wrong granularity for many Gnus-internal definitions
(and same applies to all multifile packages). So what would use for
those if your declaration are only for file-local internal definitions?
This is outside the scope of this suggestion. For them, nothing changes.
So the objection I see is: if this explicit internal declaration were to
be introduced, and say its scope is limited to the file in which it is
declared, and then a programmer explicitly declares a function as
internal knowing full well that this declaration means file-local, and
that programmer then uses this internal function external to that file,
they are rightfully triggering whatever ramifications the warnings are
warning them against. See my alligator analogy.
- Re: declare function/macro private, (continued)
- Re: declare function/macro private, Tassilo Horn, 2021/06/06
- Re: declare function/macro private, Stefan Monnier, 2021/06/06
- Re: declare function/macro private, Paul W. Rankin, 2021/06/06
- Re: declare function/macro private, Arthur Miller, 2021/06/06
- Re: declare function/macro private, Paul W. Rankin, 2021/06/06
- Re: declare function/macro private, Arthur Miller, 2021/06/07
Re: declare function/macro private, Paul W. Rankin, 2021/06/06
Re: declare function/macro private, Boruch Baum, 2021/06/06
- Re: declare function/macro private,
Paul W. Rankin <=
Re: declare function/macro private, Eli Zaretskii, 2021/06/07
Re: declare function/macro private, Stefan Monnier, 2021/06/08