[Cuis-dev] Runtime linter

[Phil B]

Hernan,

On Fri, Oct 18, 2019 at 2:13 PM Hernan Wilkinson <
hernan.wilkinson at 10pines.com> wrote:

> Hi Phil!
>  interesting idea. I agree that we need a better way to show those kind of
> message.
>

That was the conversation I was trying to kick off ;-)


>  I have two comments on what you sent:
> 1) This is a functional/user experience comment: I think the current idea
> is not to interfere with the programmers flow of work... You proposal
> signals an exception and the debuggers shows up stoping the execution and
> taking the user out of context. I think this kind of messages should not
> bother the programmer that much.
>

I agree with what you're saying... unfortunately, the history of how this
stuff has been implemented contradicts  your statement.[1]  My position is
that current/previous approaches absolutely interfere with the (or at least
this ;-) programmer's flow of work (or worse: dialog pops in a server
application) which is what initially sparked the idea.  All this proposal
attempts to do is *replicate* what has done previously in terms of dialog
pops.  That way, people who were fine with how things are would see minimal
changes while providing people like me the ability to reduce or eliminate
them while still tracking/being able to look at the thing being reported at
my convenience.

Part of the reason I stopped where I did and sent the changesets to the
list was the realization that perhaps all we really need is a specific
Exception subclass (LintNotification?) that provides the context, category
and priority of an issue.  I think utilizing the existing Exception
mechanism would allow for more flexibility at an individual level as to how
to deal with them. (I won't even pretend to have the answers for all
situations... I just want flexibility for each of us to customize/craft the
solution that fits us)  Then I could re-target what I was doing as the
handler for that class of Exception.  Then let's say that you just wanted
to see it all logged to Transcript and Juan wanted to see dialog pops or
some mash-up of ideas, we could all implement our own default handlers as
appropriate and be happy.  However, I didn't want to spend more time on
this unless there was agreement on this as a general concept and direction
(i.e. it's pointless for me to implement if you guys won't use it)

[1] Variable shadowing, non-local returns and deprecation all started life
doing dialog pops.  Then after complaining, two of them now emit Transcript
messages which interrupts my flow in a different dimension.


> 2) This is an implementation comment: To check if it is the first time you
> are saving the method's printString. If the method or class get renamed it
> will be recognized as first time even though it is not... not a big deal
> and I'm not sure it can be solved.
>

For the deprecation warnings, you're right.  It wasn't intended to be a
live view of issues on the system like a browser but rather a consolidated
snapshot over a period of time.  Literally think of it more as a lint
filter on a clothes dryer: you only check it periodically to see what's in
it.  For things like renamed methods, you toss those in the trash and move
on.


> I think the best solution would be to show this lint messages in the
> browser and not when executing code.
>

There are two issues:

1) Some things like variable shadowing can be shown in the browser since
static analysis can catch them.  The question is: what if you want to see
them in the browser but I don't?

2) Some things like deprecation warnings can't be shown in the browser...
they are runtime issues.  (while you could certainly indicate that the
method itself is deprecated in the browser, you can't with any degree of
certainty find all senders of it statically without running the risk of
false positives or missing some dynamically generated sends)  Again, the
question is: what if you want to see them either as dialog pops or as
transcript messages but I want to track them in the background and only
look at them periodically?

The flippant response is 'well just override the methods that do whatever
it is you don't like'.  Well, I've tried that... you guys keep
adding/changing them and it's hard to keep up.  Then you change something
and my override breaks or my override breaks something you've changed.
There needs to be a better way.


> For example, I would like to see in the browser that a message I'm sending
> is deprecated (not really possible unless you use Live Typing).
>

Exactly... and even live typing can't catch everything.  Some issues you
can only detect at runtime.


> The same for a non local return in an exc. handler (that is doable).
> The current solution that shows that in the transcript is a good
> compromise.
>

No it's not!  That's the issue: for non-critical, non-urgent things like
this different people have different needs and preferences.  So what I'm
proposing is that we try to accommodate that.  I don't want to dictate to
you how you see/deal with these types of things and am asking for the same
consideration.  That's what the changesets intended to show: it doesn't
have to be an either/or decision.


>
> Why you do not like those messages to be shown in the transcript? Is it
> because you are using it to show other things or because it is showing too
> many messages?
>

Because I just had 36k (just loading OMeta) and 2M+ (trying to rebuild my
base image) Transcript messages related to non-local returns... that's not
useful.  All I needed to know is that I had *a* non-local return in an
exception handler for a given method.  When it happened or how many times
it happened is irrelevant... it happened once and that's all I need to
know.  I want it flagged so I can run my code for a period of time and then
see a consolidated list of issues I need to look at rather than a constant
stream of Transcript messages (which crowd out the messages I find
important to track in realtime) or dialog pops (which I find unhelpful for
non-critical, non-urgent issues.)  I've had similar issues with things like
deprecation warnings.

I think how we handle important/subjective issues like these should be
distinctly different from urgent/critical  (i.e. think FileDoesNotExist,
OutOfMemory) and other time-sensitive issues.  The important/subjective
issues don't necessarily need to be handled right now, the user doesn't
necessarily need to be informed about them right away and in some cases
frankly some users may not care about some types of them ever.  So let's
not make it a one-size-fits-all solution.


>
> Cheers!
> Hernan.
>
>
Thanks,
Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20191018/c698ef30/attachment.htm>