[squeak-dev] The Trunk: Collections-dtl.548.mcz

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Fri Dec 13 17:18:08 UTC 2013


Apart reorganizing and engineering new functionalities, there is a third
activity which is essential: fixing broken features.

Packaging is useful for
- stripping an image
- constructing an image
- replacing some parts by alternatives
If unloading a package has unexpected side effects that affect more
features than expected, then it falls into broken features.

Emergency evaluator is like our insurance, we hope it's never used, but we
subscribe just in case.



2013/12/13 Chris Muller <asqueaker at gmail.com>

> > Dave, the only thing I don't like about this change is I thought we said
>> we
>> > were going to migrate away from using the Dictionary API on Smalltalk.
>>  This
>> > was back when Andreas and community came up with the idea of the wrapped
>> > 'globals'.
>> >
>> > I think it would be better to use
>> >
>> >     (Smalltalk classNamed: #Paragraph) ifNotNil: [ : classParagraph |
>> ... ]
>> >
>> > otherwise we can never find all the places where we try to do logical
>> access
>> > to class.
>>
>> In which case we should have #bindingOf:ifPresent, or similar. An API
>> that forces you to acknowledge the potential not-there-ness of a thing
>> is far preferable, in my book, to a separate-check-then-use. The
>> latter also have fun time-of-check-time-of-use issues in a
>> multiprocessing environment... which we happen to have.
>>
>
> 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.
>
> 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.
>
>
>>
>> >> >> Well, that definitely stops a DNU and such when running in Morphic
>> >> >> (yay!) but it still won't work in a non-MVC/Morphic world. That's
>> when
>> >> >> you accused me of overengineering, David :)
>> >> >
>> >> > Yes you're right, I meant that with a smiley, sorry :)
>> >>
>> >> I knew there was something of a smiley in there :) I just meant that
>> >> if we want to preserve the Transcripter's emergencyEvaluator we would
>> >> need this "complexity" because we'd need an emergencyEvaluator per UI
>> >> framework.
>> >
>> >
>> > -1.  Please be more conservative and lazy about putting new
>> code/elements
>> > into the system.  TSTTCPW demands that we don't start building out
>> > infrastructure for new UI frameworks until those frameworks are being
>> pushed
>> > into existence and such a factoring is actually NEEDED.  Please only
>> write
>> > code for the "now" not for some "potential future".  10 years could go
>> by
>> > with no new graphical frameworks and then someone looking at your
>> > class-hierarchy will regard it as "cruft".
>>
>> (a) The emergency evaluator's there _for good reason_.
>> (b) We HAVE two UI frameworks right now. They're part of the standard
>> image.
>> (c) "Stripped" 4.5 base images do not have ST80, so this code is broken.
>> (d) To fix it _requires_ two separate UI implementations because of point
>> (b).
>>
>> Unless you're specifically saying "we should not have an emergency
>> evaluator". But then say that, not -1 me suggesting a way to fix
>> something broken. (Please feel free to suggest a simpler way of
>> solving the problem that works for all CURRENT UI frameworks.)
>>
>
> 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).
>
> 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.
>
> 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.
>
> 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.
>
> Thanks.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131213/2fcb56d3/attachment.htm


More information about the Squeak-dev mailing list