Re: Duplicate identifiers in a single namespace

On 9/29/2024 11:10 AM, Don Y wrote:

On 9/29/2024 11:06 AM, Jeroen Belleman wrote:

On 9/29/24 14:15, Don Y wrote:

How does (e.g., Windows) tolerate/differentiate between
multiple *identical* identifiers in a given namespace/context?
>
And, what *value* to supporting this capability?
>

>
Is that an electronics subject?

 Yes -- in that one uses computers (electronic devices, for the
most part) in the design and fabrication of other electronic
products.  As such, where and how such things are implemented
is of importance.
 Considerably more on-topic than visualization or quantum
speculations.
 Granted, folks here are probably not as qualified as they might be
in other forums to contribute to such answers -- beyond their
personal experiences USING (e.g. Windows) same.

Here, for example, is a situation that I suspect many folks have
encountered on their own workstations -- but ignored due to a curiosity
deficit:
<https://mega.nz/file/krwmlBCL#Im_HcJFa6i6IaR6m3ziL4GadXO3uZnam0iAAWk-xkPI>
Note the two icons having the same name (desktop.ini) but different
contents.  I can create many such "duplicates" presented in the
"Desktop" namespace.
Inspecting the properties of each reveal that they are, in fact, different
objects in the *file* system.  Their coexistence in the "Desktop"
namespace is the result of the desktop being (effectively) implemented
as a union mount.  You can note the pathnames to the individual files.
[Similar behaviors exist with the "Start Menu", etc.]
This has been a feature of computer systems for at least 35 years,
though most folks aren't savvy enough to have availed themselves of
its utility.
In a more conventional union mount, the name collision would be resolved
through some sort of predefined precedence.  E.g., *layering* the mounts
so any names/identifiers present on an upper layer hide any objects having
the same names on *lower* layers.
This is a win in writing applications as it lets the developer create
immutable objects that define "APPLICATION defaults" without fear
that the user may inadvertently alter them.
The *user's* "settings" are stored in a file having the same name as
the application's.  If the file doesn't exist, the file containing
the defaults is exposed (by the absence of anything having the same
layered name ON TOP of it).  If the user's file *does* exist, then
the defaults file is hidden.
As nothing dictates the size of number of layers of such a hierarchy,
one can create a folder called "application_X_settings" that has
"files" (i.e., identifiers) bearing names whose presence (or absence)
indicates the state of binary options; and, whose *contents* indicate
values for those named settings.  So, "voltage" could contain "12.7"
while "current_limit" could contain "3.5".
[This is becoming increasingly commonplace as folks use the typical
file system as a central namespace for everything that might want to
be named:  "write '9600' to .../COM1/baudrate and '8N1' into
../COM1/character_format; and, if you ever want to KNOW what these
settings are, currently, just *read* those 'files'!"]
The user can then have *his* "application_X_settings" layered atop
the immutable "defaults" defined by the developer.  Or, a set of
site-specific (or project-specific) settings.
Otherwise, the application embeds a set of defaults in its binary.
Then, goes looking for a set of "global" defaults that reside in
a file in the filesystem.  Then, a set that reside in the user's
$HOME, etc.  Deliberately writing code to parse each of these
"sources", in turn.
For each application.
However, MS's implementation exposes every object in the union
without a way of (easily) identifying which is which.  E.g., how
do YOU know that the PROPERTIES windows I displayed haven't been
reversed?
But, hey, if your products only need 1970's vintage software
design techniques, why learn something new, right?  :>  Was a
time when BASIC, FoRTRAN and COBOL ruled the world -- why change?!