Am Mo., 24. Feb. 2020 um 14:37 Uhr schrieb Thiede, Christoph
<
[hidden email]>:
>
> Now I have to ask the question of whether you should use self environment or self selectedEnvironment here. What's the difference?
>
Seems like there is not much difference left between
Browser>>environment and Browser>>selectedEnvironment, hmm. Before
Marcel's change in 2018, environment would either answer the browsed
environment, or, if not defined, answer the environment of the
selectedClass. You can get the environment of the selected class with
self selectedClass environment anyway (who would have thought).
selectedEnvironment was once "connected" to the selected system
category, but would only answer Smalltalk or nil. In a hierarchy
browser, selectedEnvironment nowadays answers either the browsed
environment or the environment of the class on which the browser was
opened ("centralClass"). When I changed the browsers to be more
environments-friendly in 2016/17, I seem to have preferred self
environment as a replacement for Smalltalk, except in one case
(defineClass:notifying:, which I probably aligned with
defineTrait:notifying:). But maybe I just didn't know about
selectedEnvironment for most of that time.
These use environment:
Browser copyClass {class functions} {Tools-Browser}
Browser findClass {system category functions} {Tools-Browser}
Browser hierarchicalClassList {class list} {Tools-Browser}
HierarchyBrowser classList {class list} {Tools-Browser}
These use selectedEnvironment:
Browser defineClass:notifying: {class functions} {Tools-Browser}
Browser defineTrait:notifying: {traits} {Tools-Browser}
Browser dragFromClassList: {drag and drop} {Tools-Browser}
Browser dropOnSystemCategories:at: {drag and drop} {Tools-Browser}
Browser selectedClass {class list} {Tools-Browser}
I suppose one could sort this out, better define and distinguish the
two messages, and change the message sends where appropriate. For
example, if at some point we might have a browser that shows
categories from different environments, selectedEnvironment could
answer the environment from which the selected category comes.
Independent of what we have now, the browser should use the
environment of the selected class for evaluating snippets of methods
in the code pane or for arguing about the selected class. But to
create new objects, such as subclasses, or to enumerate objects it
should always use the "browsed" environment instead, even if the
currently selected class comes from a different environment. For
example, when you browse environment X, open a hierarchy browser on
one of its classes, then select a superclass from Smalltalk and create
a new subclass of that, the new class should go into environment X.
Otherwise you cannot easily create subclasses in environments other
than Smalltalk.
Locked
