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

Eliot Miranda eliot.miranda at gmail.com
Fri Dec 13 20:21:21 UTC 2013


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.


> Dave
>
> > frank
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131213/86c1e594/attachment.htm


More information about the Squeak-dev mailing list