[Cuis-dev] Naming conventions

Phil B pbpublist at gmail.com
Mon Apr 27 11:18:28 PDT 2020


Ken,

On Mon, Apr 27, 2020, 11:45 AM ken.dickey--- via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> On 2020-04-27 08:22, Mariano Montone via Cuis-dev wrote:
> > El 27/4/20 a las 12:13, ken.dickey--- via Cuis-dev escribió:
> ..
> >> Examples?
> >
> > For example, Seaside uses 'WA' prefix for its classes, like:
> > WAHtmlCanvas, WAAuthConfiguration, etc.
>
> Ah.  I might have expected "Web" or "SSWeb".  What is WA? State of WA
> (Washington?) Web Authoring?
>

Web Application?  But in the end, who cares what it actually means as long
as it's consistent within the framework?


> Best to stay away from acronyms.
>

Nice in theory.  If you don't use acronyms and abbreviations you'll end up
with with things like ScalableVectorGraphicsApplicationContextFooBar.
Seriously, I used to try using only meaningful words with no acronyms and
ended up with 30+ character names that *still* didn't convey enough
meaning.  The world is a complicated place.


>
> Also, best to have composable reused/reusable common features.  How many
> HtmlCanvas classes are there?
>

You'd be surprised :-)

Speaking from experience, what you are suggesting only works for a very
limited set of classes and methods in at most a few domains at once... it
simply does not scale.  A couple of quick examples are generic concepts
like context and canvas.  Am I talking about method contexts? OpenGL
contexts? OpenCL contexts? Morphic canvas? SVG canvas? HTML canvas? and so
on...


>
> I can see where this might help with ported code to avoid conflicts.
>

It also helps with forking/working on new versions of a codebase where you
want to reduce naming conflicts or even want both codebases to be able to
be loaded simultaneously.  Also, there is usually more than one way to do
the same thing so you'll end up with different implemantions.  Take web
applications as an example.  In Smalltalk there are at least 3 ways to do
it: roll your own, Seaside and Aida.  Which one owns the name
WebApplication?  If I take the 'chosen' implementation and fork portions of
it, but want to remain inter-operable with it, what do I call my version?


>
> Mariano, thanks much for the examples BTW.  I have seen prefixes used
> based on GUI vs Algorithmic, containers, immutability, style, and so
> forth.
>
> My preference is to simplify, unify, and share function.  One might use
> a prefix in an initial port, but if useful over time I would hope the
> glob of code would be refined into composable features which are easily
> shared.  A comprehensible system, not just one that works.
>

A nice ideal, but rarely achievable in practice.  This only works when 1)
it's baked into the image and/or 2) there is widespread agreement as to the
meaning of a given class/method name.  In my experience, this rarely occurs
in real world code.  I sure haven't seen it in Smalltalk code.  The domain
knowledge of those choosing the names is usually limited to the domains
they are working in along with a lack of time and resources... so do you
constantly rename (breaking code) classes/methods as you learn about and
incorporate new domains?

I would only classify a subset of the method names in the base image as
'good'...  the rest just *are* largely for historical reasons.  And things
deteriorate quickly as you start expanding the universe of names to
packages.  Think there's any kind of consensus on commonly use names?
Start poking around various packages and tell me what #on: #with: and #for:
mean...


>
> When I am testing (e.g. Feature>>require:) I may load scads of packages,
> but for me the result in Cuis has always been way under 900 classes.  I
> don't want to see 9000 classes!
>

That will work for an image where you're working in/with a very limited
number of domains.  As you start scaling up (i.e. you want to make your
application a web app... that talks to a couple of different databases...
using GPU compute... with one or more DSLs etc.) the class and method count
will explode and you will start seeing annoying name conflicts because
every package author thinks their #foo is the only one.  And of course, to
keep it as English-like as possible to compose into sentences they all use
1-2 word method names that are generic (for specialized use cases!) and
conflicting.

My development image is currently ~3000 classes and I've had to work quite
hard to get/keep it that low!  In a perfect world, I'd like to see that
number closer to 1000... but it's far from a perfect world.


> $0.02,
> -KenD
>
>
Thanks,
Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200427/9be05cf9/attachment-0001.htm>


More information about the Cuis-dev mailing list