<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Dec 13, 2013 at 11:38 AM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, Dec 13, 2013 at 06:37:19PM +0000, Frank Shearar wrote:<br>
> On 13 December 2013 16:59, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br>
> >> > Dave, the only thing I don't like about this change is I thought we said<br>
> >> > we<br>
> >> > were going to migrate away from using the Dictionary API on Smalltalk.<br>
> >> > This<br>
> >> > was back when Andreas and community came up with the idea of the wrapped<br>
> >> > 'globals'.<br>
> >> ><br>
> >> > I think it would be better to use<br>
> >> ><br>
> >> > (Smalltalk classNamed: #Paragraph) ifNotNil: [ : classParagraph |<br>
> >> > ... ]<br>
> >> ><br>
> >> > otherwise we can never find all the places where we try to do logical<br>
> >> > access<br>
> >> > to class.<br>
> >><br>
> >> In which case we should have #bindingOf:ifPresent, or similar. An API<br>
> >> that forces you to acknowledge the potential not-there-ness of a thing<br>
> >> is far preferable, in my book, to a separate-check-then-use. The<br>
> >> latter also have fun time-of-check-time-of-use issues in a<br>
> >> multiprocessing environment... which we happen to have.<br>
> ><br>
> ><br>
> > I used to prefer Potential-not-thereness API's in "my book" too until one<br>
> > day I found it unnecessarily expanding and complicating API's. Users of<br>
> > API's must write defensive code anyway. The ifNotNil: approach allows a<br>
> > simpler API that can provide either existence-testing OR access via one<br>
> > simple message rather than two.<br>
> ><br>
> > As for "fun time-of-check-time-of-use issues" that's just bunk. You think<br>
> > the ifPresent: method doesn't do the same ifNotNil: check or could not be<br>
> > interrupted? Unless you're thinking to put a Mutex into SmalltalkImage to<br>
> > make it "thread safe". What, for background unloading? If you need that<br>
> > guard it from the outside.<br>
> ><br>
> >><br>
> >><br>
> >> >> >> Well, that definitely stops a DNU and such when running in Morphic<br>
> >> >> >> (yay!) but it still won't work in a non-MVC/Morphic world. That's<br>
> >> >> >> when<br>
> >> >> >> you accused me of overengineering, David :)<br>
> >> >> ><br>
> >> >> > Yes you're right, I meant that with a smiley, sorry :)<br>
> >> >><br>
> >> >> I knew there was something of a smiley in there :) I just meant that<br>
> >> >> if we want to preserve the Transcripter's emergencyEvaluator we would<br>
> >> >> need this "complexity" because we'd need an emergencyEvaluator per UI<br>
> >> >> framework.<br>
> >> ><br>
> >> ><br>
> >> > -1. Please be more conservative and lazy about putting new<br>
> >> > code/elements<br>
> >> > into the system. TSTTCPW demands that we don't start building out<br>
> >> > infrastructure for new UI frameworks until those frameworks are being<br>
> >> > pushed<br>
> >> > into existence and such a factoring is actually NEEDED. Please only<br>
> >> > write<br>
> >> > code for the "now" not for some "potential future". 10 years could go<br>
> >> > by<br>
> >> > with no new graphical frameworks and then someone looking at your<br>
> >> > class-hierarchy will regard it as "cruft".<br>
> >><br>
> >> (a) The emergency evaluator's there _for good reason_.<br>
> >> (b) We HAVE two UI frameworks right now. They're part of the standard<br>
> >> image.<br>
> >> (c) "Stripped" 4.5 base images do not have ST80, so this code is broken.<br>
> >> (d) To fix it _requires_ two separate UI implementations because of point<br>
> >> (b).<br>
> >><br>
> >> Unless you're specifically saying "we should not have an emergency<br>
> >> evaluator". But then say that, not -1 me suggesting a way to fix<br>
> >> something broken. (Please feel free to suggest a simpler way of<br>
> >> solving the problem that works for all CURRENT UI frameworks.)<br>
> ><br>
> ><br>
> > Ok, all I'm saying is, part of your work is about reorganizing, and other<br>
> > parts are about engineering new functionality just to accomodate the<br>
> > reorganizations. (What's worse is when you want to remove functionality<br>
> > just to accomodate but I'll be lazy about addressing that).<br>
> ><br>
> > Whenever there's an arbitrary piece of new functionality (e.g.,<br>
> > Morphic-based emergency evaluator) just to avoid crossing package boundaries<br>
> > you don't want to cross, then engineering "solutions" to that I think could<br>
> > end up being code for ghost situations.<br>
> ><br>
> > Because there has been no concrete vision/requirement for a Morphic-based<br>
> > emergency evaluator (EE). EE is a relatively rare occurrence (one would<br>
> > hope!) and for developers only. But developers typically use _development<br>
> > images_ which tend to be fat, not "Stripped", and so might probably include<br>
> > ST80 anyway..? The cases seem pretty uncertain and so that's why I'm<br>
> > questioning engineering new stuff like this into the image.<br>
><br>
> This is a bug. It needs to be fixed. It's not new functionality,<br>
> unless by "new" you mean "it actually works in Morphic".<br>
><br>
> > Particularly we're at a time when I want to get 4.5 out the door, so that<br>
> > may be contributing to my aversion to new engineerings. I ask you to at<br>
> > least consider simple stub error-handling in situations where<br>
> > packages/functionality would be unfulfilled. We can fill in implementations<br>
> > later, if needed, but at least you'll have made the structure.<br>
><br>
> So you'll be happy with<br>
><br>
> * move the current EE to ST-80,<br>
> * fix the EE for Morphic (at some point),<br>
> * add an AppRegistry for the EE (which is just a hook like ToolSet and<br>
> friends, so we don't tangle the two UI frameworks we have so carefully<br>
> untangled)<br>
><br>
<br>
</div></div>No.<br>
<div class="im"><br>
> ? If there's a simpler solution, I'm all ears.<br>
><br>
<br>
</div>Hopefully there is a simpler solution, aalthough I cannot look into it right now.<br></blockquote><div><br></div><div>Do we have a place-holder? It is much better to have a string appear in top-left that says "The Morphic emergency evaluator is current;y unimplemented. this is an oversight it is intended to fix." than have the system lock-up silently. I'm worried that in a few weeks or months we'll have completely orgotten about the Morphic EE and it'll present a mystery when it is needed.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Dave<br>
<br>
> frank<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>