<div dir="ltr"><div dir="ltr">Hernan,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 18, 2019 at 2:13 PM Hernan Wilkinson <<a href="mailto:hernan.wilkinson@10pines.com" target="_blank">hernan.wilkinson@10pines.com</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"><div dir="ltr">Hi Phil!<div> interesting idea. I agree that we need a better way to show those kind of message.</div></div></blockquote><div><br></div><div>That was the conversation I was trying to kick off ;-)</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"><div dir="ltr"><div> I have two comments on what you sent:</div><div>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. </div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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)</div><div><br></div><div>[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.</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"><div dir="ltr"><div>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.</div></div></blockquote><div><br></div><div>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.</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"><div dir="ltr"><div><br></div><div>I think the best solution would be to show this lint messages in the browser and not when executing code. </div></div></blockquote><div><br></div><div>There are two issues:</div><div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div><div>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.</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"><div dir="ltr"><div>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).</div></div></blockquote><div><br></div><div>Exactly... and even live typing can't catch everything.  Some issues you can only detect at runtime.</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"><div dir="ltr"><div> The same for a non local return in an exc. handler (that is doable).</div><div>The current solution that shows that in the transcript is a good compromise.</div></div></blockquote><div><br></div><div>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.</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"><div dir="ltr"><div><br></div><div>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?</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</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"><div dir="ltr"><div><br></div><div>Cheers!</div><div>Hernan. </div></div><br></blockquote><div><br></div><div>Thanks,</div><div>Phil </div></div></div>