Is classless worth consideration

[Terry Reedy]

"Dave Benjamin" <ramen at lackingtalent.com> wrote in message
news:slrnc96kat.20s.ramen at lackingtalent.com...
> PHP and JavaScript both try to blur the distinction between object and
> dictionary. The result is that you can't tell a key from an attribute,
and
> this can sometimes be problematic. PHP goes a step further and removes
the
> distinction between array and dictionary. Perhaps this is easier for
people
> to learn, since they can master one concept and apply it everywhere, but
I
> much prefer having arrays, dictionaries, and objects as separate concepts
> with their own protocols. I like having classes and modules for the same
> reasons.

In thinking about dictionaries versus modules (and classes/instances), I
come up with two reasons to have both.

1. A dictionary is a generic association mechanism, with the key being any
hashable object.  A module is a association mechanism specialized for the
important and common special case of keys that are name strings, and which
therefore can be written in code without quotes.

2. A module, because of its specialization, has a more graceful syntax for
accessing objects bound to a name known at the time of coding (and
compilation): mod.name versus dic['name'].  A dictionary, because of its
generalization, has a more graceful syntax for accessing objects bound to a
(name) key that is only accessible indirectly, at runtime, via a name bound
to the (name) key: dic[namename] versus getattr(mod, namename) (or
hasattr() or setattr()).  (For multiple indirect accesses, one can avoid
hasattr, etc by doing modic = mod.__dict__; modic[namename]; ...)

One could propose to combine the syntaxes by allowing dict.name instead of
dic['name'], but this conflicts with the fact the dicts have several
instance methods, and that dicts therefore need an attribute namespace in
addition to and separate from the association they represent.

Allowing mod[namename] as a substitute for hasattr(mod, namename) might be
more feasible (by giving the module type object __xxxitem__ methods), but I
can see objections.  One-way unification and indexing restricted to
namestrings both could be confusing.  It would also make it easier to write
syntacitically valid but sematically invalid code, whereas the xxxattr
names remind that the access key must be a valid attribute name.

Quoting from a previous post quoting by someone else:
> Modules are an encapsulation mechanism, just like class instances, so
> I'd say the large and obvious overlap counts as unnecessary

I don't see this.  'Class instance' is an abstract concept, not a
particular object.  A particular module *is* an instance of the module
typeclass, so of course modules are like 'class instances': they are a
particular type of class (type) instance.  Or, if you will, instances of a
particular classtype.  In other words, module and modules are part of the
current typeclass and instance system, not a disposable alternative.
(Classic classes are duplicative and are only kept for back-compatibility,
so I ignore them in discussions like this.)

The particular features of the module type are dual.  First, it has a
specialized __init__ method that initializes instances from a file rather
than a set of arguments.  Second, while it does have the standard minimal
set of special attributes (__doc__, etc) it does not have any attributes
intended for post-initialization access via the instances.  Therefore, we
are free to give module instances any attributes we want.  This freedom is
what makes them usable as generic name capsules.  (Modules do have
individual __init__-set __name__, __file__, and __doc__ attributes, but
these can usually also be overriden also without problem.)

Terry J. Reedy