<div dir="ltr"><div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 11 Jun 2020 at 1:46 AM, <<a href="mailto:ken.dickey@whidbey.com" target="_blank">ken.dickey@whidbey.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
<br>My thought is to use a Color swatch/icon to mark Environment Class names <br>
and have the tooltip give the Environment name prefix.  Use this in <br>
place of the extended name prefix to reduce clutter.<br>
</blockquote><div dir="auto"><br></div><div dir="auto">Sounds interesting. Anyway I would try to find a better place for things like color or icon, perhaps in theme? Not sure, but environments seem to me something that should be independent of GUI stuff... and I can imagine for example that a color that works well in the default theme looks bad in a dark theme. Just a thought.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">My thought again is to allow one to use a Feature (or Feature set) to be <br>
imported as a (set of) Environment(s).  So Packages can be used either <br>
way.<br>
<br>
More complex UI management, but perhaps simplifies/unifies <br>
description/usage of Packages.</blockquote><div dir="auto"><br></div><div dir="auto">Yes, I like it! I was thinking about allowing a package to be installed in a namespace, and also allowing an already loaded package to be moved to a namespace, but I never implemented this part.</div><div dir="auto"><br></div><div dir="auto">Also, I tried different approaches to solve the problem of referring to classes in a namespace from a workspace. I considered having a global setting for a default namespace, or a local setting in each workspace, but I didn't like either option very much. I like the idea of having environments as globals in Smalltalk, and using the doesNotUnderstand: mechanism for resolving, for example if you want to instantiate a Cat in an environment called Animals, I would write in a workspace: 'Animals Cat new'. The lookup is not super fast, but I like it because it is simple, readable and dynamic, and I think it would be used mostly for doIts so it doesn't need to be super fast (and there are options anyway, you can still do 'Animals at: #Cat', or come up with a mechanism to automatically compile the required methods, etc). Goran mentioned that Dan wanted it to work like this too, but I don't know if he was talking about Dan Ingalls, maybe another Dan...<br></div><div dir="auto"><br></div><div>In other tools like the debugger or an inspector, you know what environment you're in (self class environment). And for the class browser, what I did was to derive the namespace from the system category name ('Animals-Mamals' would give you the environment Animals if it exists, allowing you to subclass Cat for example by sending #subclass:... to the class Cat).<br></div><br></div></div>
</div>