<div dir="ltr"><div>Ken,</div><div><br></div><div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 27, 2020, 11:45 AM ken.dickey--- via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2020-04-27 08:22, Mariano Montone via Cuis-dev wrote:<br>
> El 27/4/20 a las 12:13, ken.dickey--- via Cuis-dev escribió:<br>
..<br>
>> Examples?<br>
> <br>
> For example, Seaside uses 'WA' prefix for its classes, like:<br>
> WAHtmlCanvas, WAAuthConfiguration, etc.<br>
<br>
Ah.  I might have expected "Web" or "SSWeb".  What is WA? State of WA <br>
(Washington?) Web Authoring?<br></blockquote><div><br></div><div>Web Application?  But in the end, who cares what it actually means as long as it's consistent within the framework? </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Best to stay away from acronyms.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Also, best to have composable reused/reusable common features.  How many <br>
HtmlCanvas classes are there?<br></blockquote><div><br></div><div>You'd be surprised :-)</div><div><br></div><div>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...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I can see where this might help with ported code to avoid conflicts.<br></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Mariano, thanks much for the examples BTW.  I have seen prefixes used <br>
based on GUI vs Algorithmic, containers, immutability, style, and so <br>
forth.<br>
<br>
My preference is to simplify, unify, and share function.  One might use <br>
a prefix in an initial port, but if useful over time I would hope the <br>
glob of code would be refined into composable features which are easily <br>
shared.  A comprehensible system, not just one that works.<br></blockquote><div><br></div><div>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?</div><div><br></div><div>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...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
When I am testing (e.g. Feature>>require:) I may load scads of packages, <br>
but for me the result in Cuis has always been way under 900 classes.  I <br>
don't want to see 9000 classes!<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
$0.02,<br>
-KenD<br><br></blockquote><div><br></div><div>Thanks,</div><div>Phil </div></div></div></div>
</div>