Re: Associate non-named functions to a high level group

On Sunday, April 5th, 2026 at 8:41 PM, Jean Louis <[email protected]> wrote:

> On 2026-04-05 03:49, Heime wrote:
> > On Sunday, April 5th, 2026 at 11:32 AM, Jean Louis <[email protected]>
> > wrote:
> >> rcd-vc- in rcd-vc.el package and so on.
> >>
> >> How about you try that way? > Jean Louis
> >
> > Prefix naming schemes with multiple components have become
> > too cumbersome.  I prefer tools with single-prefix names only.
> > Additional associations must occur in the background, as longer
> > names sacrifice the brevity of short prefixes too much.
> 
> I have 5496 functions. Having same prefix for each will not tell me
> straightforward where is that function or where it should be located.
> 
> So I keep multiple packages, like rcd-mail.el or rcd-mailing.el or
> image-stamp.el and so use different prefixes. Sometimes I have to rename
> the function in hyperscope.el instead of hyperscope- to something like
> rcd-db- which would mean that I need to put function in different file
> or package as it is more generic than package I am working in.
> 
> The more there is the more difficult it becomes.

Have noticed that.
 
> I am even thinking of quite a different system.
> 
> I am envisioning a programming paradigm where I treat function
> definitions as strict, immutable database records rather than mutable
> named entities. In this model, each of my 5400+ functions would have a
> canonical identity (like a primary key) rather than just a name, and any
> change I make to a function's name or definition would automatically
> propagate to all other functions that reference it, maintaining
> referential integrity across my entire codebase. This would replace the
> traditional symbolic lookup system with a relational database approach
> where function dependencies are explicitly tracked and enforced,
> preventing the silent breakage that occurs when I rename a function but
> miss updating some of its callers.
> 
> In fact, automatic error verification would be one of the most powerful
> benefits of such a system.
> 
> Because every function reference is tracked as an explicit dependency
> rather than a symbolic name lookup, the database would instantly know
> when a change creates an inconsistency. Before I even attempt to run the
> code, the system could verify that every function call matches its
> target's current arity, argument types, and return signature. If I
> rename a function, the database immediately flags every caller that
> still references the old name. If I change a function's parameter count,
> the system can detect all callers passing the wrong number of arguments.
> This shifts error detection from runtime (discovering breakage when
> execution hits a specific code path) to definition-time or load-time,
> essentially giving me a continuously validating, referentially
> integrated codebase where many classes of errors become impossible to
> commit.
> 
> --
> Jean Louis
> 
>