Hi Marcel,

> That is, I don't care about shadowing the instVar name -- just locally
> focused readability. That is, I am a fan of accessors and thus rarely (?
> never ?) bitten by confusing instVar access and tempVar access. :-) For
> classes with longer methods and extensive instVar access (...Compiler?),
> shadowing can be an issue for code readability, though.

That is an interesting insight. Personally, I have stumbled upon unintended
shadows a number of times, which is probably related to my way of dealing
with tempvars - usually, I do not declare any of them manually but have them
added by the compiler when accepting the method. With this approach, it can
happen quickly that you miss a tempvar declaration because a variable with
the same name already exists. Analogously sometimes, I remove all
declarations after refactoring a method when I am unsure whether all
tempvars are still in use - and in this situation, I would be irritated if
no tempvar declaration is generated because a prior author of the method
(most likely a stupid former self) has shadowed an instvar.

But as it depends on the individual coding style, as you write, do you think
we should provide a toggle/preference to decriminalize instvar shadows?

***


> > linter/compiler annotations ...

> How come?

Well, there might be a lot of opinions on this issue and probably I did not
express my perspective in the right way. Please give me a second chance. :-)

Just to make sure what we are talking about - when I said annotations, I
meant something like this:
<http://web.archive.org/web/20200504234326/http://www.peachpie.io/wp-content/uploads/2017/02/syntax-error.png>
That is, visual highlight + additional information that is shown upon
interaction (hover or click). Are we talking about the same kind of
annotations? :-)

Such annotations could be used for different things: Compiler warnings
(undeclared/undefined/unused temp, shadowed variable, deprecated syntax such
as underscore assignments), syntax errors (if we manage to make the Compiler
more robust), linter warnings (for example SwaLint), spelling errors, etc.
At the moment, we communicate all this information in several different
ways: Some (syntax errors) are displayed via Shout, which is nice but lacks
proper self-explanation ("Why is this all red? What is wrong with this?")
(and also requires us to maintain two separate parsers); others (compiler
warnings) are shown only when a method is accepted, so here we have a chance
to shorten feedback loops and make the compilation experience more live;
even others are shown in the Transcript only, which only a few people will
notice at all; and some others will just not be shown unless you use another
tool such as the SwaLint UI to see these messages.
A common solution that we can see in many modern tools is interactive
(sometimes expandable/explorable) annotations that are fed by multiple
sources. A good example (maybe even the gold standard?) might be the
language server API in Visual Studio Code. I think the popularity of this
concept is just based on its usefulness: You do not need to check multiple
tools but can union all their outputs in a single view (sink), combined with
the ability to filter different sources individually.

> While structured information is nice, I am opposed to introducing more
> things that are prone to errors. :-)

What kind of errors do you mean exactly? If robustness is a thing, I would
not give up the entire concept instead of using a few #ifError's. :-)

> yes, linter and compiler are tools

Hmm ... when I work with the source code pane of a CodeHolder, I actually
have the impression to work with the compiler itself, at least I can't name
any other tool that would be more close to writing code. See interactive
compilation. The compiler is a necessary step in the pipeline of making the
entered code executable.

> Tool-specific configuration/annotation [...] should not interfere with an
> artifact's primary representation. [...] That does not scale; it can also
> obfuscate the object's interface.

I think I see your point, too many annotations could be distracting. But I
am confident that we could overcome this problem by adding a simple but
powerful filter mechanism. And very of course, these annotations should be
configurable using preferences. Besides, at the moment, there would be only
two or three kinds of annotation sources at all, so this might also be a
problem for the not-so-near future. :-)

> For example, it's problematic that there is only a single #inspectorClass
> or #explorerContents per domain object.

> various annotations for all kinds of supported compilers/parsers/linters
> etc. ... nah.

Yeah, we could add another indirection for dispatching access to such tools.
But I do not see how this would restrict our abilities to filter this
(hypothetical) mass of tools? Also, in the case of compilers, we already
have #compilerClass. In the context of a CodeHolder, you would need to
decide on one of many compilers anyway ...

> There are already pragmas, which can be used to annotate methods.

That confuses me. :-) This is a completely different kind of annotations,
isn't it? Pragmas are used to store additional, intrinsic information
attached to the source code, hover annotations are used to display derived
information from different tools - they are transient but not a part of the
primary object itself. My proposal was *not* to insert any durable
artifacts/comments into the source code while analyzing it.


And perhaps one last, more general thought: I think I don't have to
emphasize that I'm a big fan of the Squeak tools like most people who will
read this. :-) Nevertheless, I have to admit that many other (I call them
"modern") editors/IDEs are based on architectures that appear to be more
flexible, more scalable, more composed than our CodeHolder and our Browser
are. I'm thinking about Visual Studio and Visual Studio Code when making
this statement. They provide great opportunities for third-party tools to
integrate potentially useful enhancements into the existing IDEs. I don't
like to say it, but my impression is that their approach would be more
suitable than our tooling which has grown over time when you try to
customize the entire development system for a specific domain. Think of
exciting additions such as Babylonian programming or also Fabio's new
CallTargetBrowser. It's a pity that you still need to subclass from the main
tool class (Browser) in all these situations to install such small but
useful extensions. VS Code, on the other hand, has a more extensible design
and provides lots of APIs that make the development of a small utility more
simple.

That being said, I don't want to say that the Squeak/Smalltalk approach of
designing tools is wrong and should be abandoned - the opposite is true, the
liveness and self-description of Squeak are still unmatched! But I think
that we need to make more efforts to modularize the Squeak tools and provide
more extension points. The new InspectorField API might be a good step in
this direction, but we need much more of these APIs. It would be a shame if
developers preferred a system like VS Code over Squeak/Smalltalk because
it's easier to extend - in particular in the light that Squeak is frequently
used for research and experiments. That's why I said in my previous message,
"If Squeak does not want to get left behind, we should support something
like this [annotations]". :-)


Well, I am glad that you survived this massive wall of text and I'm looking
forward to your thoughts. :-)

Best,
Christoph



-----
Carpe Squeak!
--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html