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

Frank Shearar frank.shearar at gmail.com
Sat Dec 14 20:09:48 UTC 2013


On 13 December 2013 20:21, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
>
> On Fri, Dec 13, 2013 at 11:38 AM, David T. Lewis <lewis at mail.msen.com>
> wrote:
>>
>> On Fri, Dec 13, 2013 at 06:37:19PM +0000, Frank Shearar wrote:
>> > On 13 December 2013 16:59, Chris Muller <asqueaker at gmail.com> wrote:
>> > >> > 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.
>> >
>> > This is a bug. It needs to be fixed. It's not new functionality,
>> > unless by "new" you mean "it actually works in Morphic".
>> >
>> > > 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.
>> >
>> > So you'll be happy with
>> >
>> > * move the current EE to ST-80,
>> > * fix the EE for Morphic (at some point),
>> > * add an AppRegistry for the EE (which is just a hook like ToolSet and
>> > friends, so we don't tangle the two UI frameworks we have so carefully
>> > untangled)
>> >
>>
>> No.
>>
>> > ? If there's a simpler solution, I'm all ears.
>> >
>>
>> Hopefully there is a simpler solution, aalthough I cannot look into it
>> right now.
>
>
> 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.

At the moment it ought to tell you that the emergency evaluator's
kicked in, but that could be amended to give a better error message,
along the lines of what you suggest.

frank

>> Dave
>>
>> > frank
>>
>
>
>
> --
> best,
> Eliot


More information about the Squeak-dev mailing list