<div dir="ltr"><div>Apart reorganizing and engineering new functionalities, there is a third activity which is essential: fixing broken features.<br><br>Packaging is useful for<br></div><div>- stripping an image<br></div><div>
- constructing an image<br></div><div>- replacing some parts by alternatives<br></div><div>If unloading a package has unexpected side effects that affect more features than expected, then it falls into broken features.<br>
</div><div><br></div><div>Emergency evaluator is like our insurance, we hope it's never used, but we subscribe just in case.<br></div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/12/13 Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div>> Dave, the only thing I don't like about this change is I thought we said we<br>
> were going to migrate away from using the Dictionary API on Smalltalk. 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>
> otherwise we can never find all the places where we try to do logical access<br>
> to class.<br>
<br>
</div></div>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></blockquote><div><br></div></div><div>I used to prefer Potential-not-thereness API's in "my book" too until one day I found it unnecessarily expanding and complicating API's. Users of API's must write defensive code anyway. The ifNotNil: approach allows a simpler API that can provide either existence-testing OR access via one simple message rather than two.<br>
</div><div><br></div><div>As for "fun time-of-check-time-of-use issues" that's just bunk. You think the ifPresent: method doesn't do the same ifNotNil: check or could not be interrupted? Unless you're thinking to put a Mutex into SmalltalkImage to make it "thread safe". What, for background unloading? If you need that guard it from the outside.</div>
<div class="im">
<div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><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 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 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 pushed<br>
> into existence and such a factoring is actually NEEDED. Please only write<br>
> code for the "now" not for some "potential future". 10 years could go by<br>
> with no new graphical frameworks and then someone looking at your<br>
> class-hierarchy will regard it as "cruft".<br>
<br>
</div>(a) The emergency evaluator's there _for good reason_.<br>
(b) We HAVE two UI frameworks right now. They're part of the standard 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 (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></blockquote><div><br></div></div><div>Ok, all I'm saying is, part of your work is about reorganizing, and other parts are about engineering new functionality just to accomodate the reorganizations. (What's worse is when you want to remove functionality just to accomodate but I'll be lazy about addressing that).</div>
<div><br></div><div>Whenever there's an arbitrary piece of new functionality (e.g., Morphic-based emergency evaluator) just to avoid crossing package boundaries you don't want to cross, then engineering "solutions" to that I think could end up being code for ghost situations.</div>
<div><br></div><div>Because there has been no concrete vision/requirement for a Morphic-based emergency evaluator (EE). EE is a relatively rare occurrence (one would hope!) and for developers only. But developers typically use _development images_ which tend to be fat, not "Stripped", and so might probably include ST80 anyway..? The cases seem pretty uncertain and so that's why I'm questioning engineering new stuff like this into the image.</div>
<div><br></div><div>Particularly we're at a time when I want to get 4.5 out the door, so that may be contributing to my aversion to new engineerings. I ask you to at least consider simple stub error-handling in situations where packages/functionality would be unfulfilled. We can fill in implementations later, if needed, but at least you'll have made the structure.</div>
<div><br></div><div>Thanks.</div></div></div></div>
<br><br>
<br></blockquote></div><br></div>