Why do we use prefixes for libraries?

[Alejandro Garcia]

I'm authoring a library, and because of what I have seen other authors do,
I gave all my classes a prefix (RESTLY_*).
But it made me wonder why we, as Eiffel developers, do this at all.

I mean, we can prefix the classes in the library when we reuse them in the client projects as part of the .ecf file

Every library I've read uses a prefix, except the original Eiffel Base.

We have Finnian Reilly's Eiffel Loop with EL_
Nadia Polikarpova's EiffelBase2 with V_
Jimmy Johnson with JJ_
EiffelVision2 with EV_
Eiffel Web Framework with EWF_
  

So why do we hardcode the prefix?

a) Defensive design: the author expects the collisions, so it gets ahead instead of forcing the <rename> on every user's ECF.
b) Stable names: a prefixed name is the same in every project, so documentation and searches are consistent.
c) History: Gobo's DS_, XM_, predate the ECF and maybe the convention stuck.

d) Simple tradition.

I'm asking because I'm personally inclined to NOT use a prefix, and let my domain objects have the shorter names.
But at the same time I want to be a good Eiffel Citizen.

--

Alejandro García F. (elviejo)
https://elviejo79.github.io

Too brief? Here's why! https://www.emailcharter.info
EOM – End Of Message. The whole message is in the subject don't need to open it.
NNTR – No Need To Respond. Help cut down on all those “cool” and “thanks” emails.
SINGLE SUBJECT. Send one email for one topic, this makes replies easy..
CLEAR CALL TO ACTION: Ask for some specific result very clearly.

[Ian Joyner]

Interesting. I’d like to hear other’s views. However, at first thought I’m against any such encoding or metadata in names.

I think it is rather like Hungarian notation, used in BCPL since there weren’t abstract problem-oriented types, but machine-oriented types or byte and word. Hungarian notation gave other programmers a ‘hint’ as to how to process the data in the container.

Abstract types meant this was not necessary, but still programmers perpetuated the practice. Programmers have a habit of being liberated from some constraint, but then perpetuating some practice dependent on the constraint, like removing vowels from names from the constraint of FORTRAN of only six-character identifiers.

Then there was the constraint of Xerox keyboards which had no ‘_’ character so programmers started using the awful camelCase (which doesn’t work on CAPITALS LIKETHIS). Niklaus Wirth himself perpetuated this.

Such conventions bake metadata into names. This is inflexible, since if something changes all instances must be changed.

So, I think it is just bad unthinking practice.

People also use file naming conventions. For example a fellow lecturer had the habit of naming all his lecture slide files <whatever>-class (the whatever was rather non-descriptive of the lecture subject)., or maybe lecture_5_class. So if I wanted to know which lecture in the course was on TCP, the file names were no help. I told him to use a clear name and put everything in a single folder named ‘class’ if that was appropriate. He got really narky. Oh well.

While I like consistent naming, I tend to dislike naming conventions.

Ian

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/CALFgaYCfV39Jk3QxMeb6w-xTczeVy0MQX_0jyX5%2BSehHxAYV1w%40mail.gmail.com.

[Eric Bezault]

On 18/07/2026 8:03, Alejandro Garcia wrote:
> c) History: Gobo's DS_, XM_, predate the ECF and maybe the convention stuck.

The goal of the Gobo libraries was to provide Eiffel
libraries which could compile with all Eiffel compilers.
And not all of them had a renaming mechanism.

In addition to that, for what the DS_ classes are concerned,
most of their class names conflict with those of EiffelBase.
So all users of the Gobo libraries would have to edit their
ECF files and add renaming clauses to use these libraries.
Not very user-friendly...

--
Eric Bezault <er...@gobosoft.com>
Eiffel expert - available for freelance work
https://www.gobosoft.com

[Ulrich Windl]

Interestingly (AFAIK) you can rename features inside Eiffel when inheriting, but to rename classes you need a mechanism outside of the language. So to understand such a program you'll have to see the ecf (formerly LACE) file, too. ECF being XML is probably not the easiest to read by humans, especially when not pretty-printed.

So the prefix known from other languages may have it's justification.
Or foes someone have a better idea to handle the renaming?

Ulrich

[rfo amalasoft.com]

Each class represents something.  Each creator's version/variant/extension of the more common classes represents ALMOST the same things.  Prefixing the almost-the-same-as classes lets the CONSUMER of those classes know they are variants, and which variants they are, without having to do any spelunking in .ecf files or worse.  A LIST class from the core Eiffel library would not be the same as a list class from someone else's library unless there were a reason for the difference.  Giving them the same name is a producer-centric hack and evokes memories of justifying some of C's syntax because it saved keystrokes.  Such thinking compromises the consumability of the classes, and of Eiffel.  If we want Eiffel to be used by more developers, we must not make it less consumable.

---

From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> on behalf of Alejandro Garcia <agarc...@gmail.com>
Sent: Saturday, July 18, 2026 2:03 AM
To: Eiffel Users <eiffel...@googlegroups.com>
Subject: [eiffel-users] Why do we use prefixes for libraries?

 

[Alejandro Garcia]

So in Gobo's case, it seems it was a little bit of 

a) You wanted to make users' lives easier by getting ahead of the conflicts they were going to have. and
c) There were Eiffel compilers that didn't have the renaming mechanism at the time.

Thank you.