Knowing you are open to the idea, I will!

Wrapping up a couple of other dev tasks, but I'll add this to my list.

Thank you!

 - Chris

On Sat, Dec 1, 2018 at 12:03 PM Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> Hi Chris,
>
>     I think you have a point.  Are you going to propose a change?
>
> _,,,^..^,,,_ (phone)
>
> > On Nov 30, 2018, at 2:34 PM, Chris Muller <asqueaker at gmail.com> wrote:
> >
> > Unrelated to the change itself, here's another example of the
> > deleterious effects of trying to improve performance at the expense of
> > proper encapsulation and late-binding dynamism.
> >
> > I'm referring to the use of an IdentityDictionary for the Smalltalk
> > Environment instead of a regular Dictionary.
> >
> > Not ONLY does force ALL clients to make assumptions about internal
> > implementation,
> >  - not ONLY duplicating this poor #asSymbol coding style again and again,
> >  - it actually screws them over on performance in the real world
> >   -- where the class names are likely to have come from an external source,
> >   therefore as a String, forcing an extra lookup in the Symbol table
> > that is worse than the original single Dictionary lookup.
> >
> > See?
> > _______
> > | iddict dict |
> > iddict := Smalltalk globals instVarNamed: 'declarations'.
> > dict := iddict as: Dictionary.
> > {
> > [ iddict at: 'Integer' asSymbol ] bench.
> > [ dict at: 'Integer' ] bench
> > }
> >
> > #('1,490,000 per second. 669 nanoseconds per run.' '3,620,000 per
> > second. 276 nanoseconds per run.')
> > _______
> >
> > Optimization is like whack-a-mole.  Optimizing one thing invariably
> > incurs a cost on something else.  So would it not be best to choose
> > the trade-offs that actually *gain in the real-world* than ones that
> > gain only in the lab?  Chasing that last 1% gain achieved in the lab,
> > narrowed the usability, resulting in across-the-board losses for the
> > real world:  in code-quality, dynamism AND performance by a whopping
> > 50%.
> >
> > Regards,
> >  Chris
> >
> >
> >> On Thu, Nov 29, 2018 at 4:00 PM <commits at source.squeak.org> wrote:
> >>
> >> Eliot Miranda uploaded a new version of ShoutCore to project The Trunk:
> >> http://source.squeak.org/trunk/ShoutCore-eem.62.mcz
> >>
> >> ==================== Summary ====================
> >>
> >> Name: ShoutCore-eem.62
> >> Author: eem
> >> Time: 29 November 2018, 2:00:34.775887 pm
> >> UUID: 45629ac9-52a5-412c-9bf1-493a0ac2ea36
> >> Ancestors: ShoutCore-tpr.61
> >>
> >> Fix a bug in SHMCClassDefinition>>sharedPools that answered nil as the pool for a missing pool, and hence broke khighlighting in the Monticello package browser when browsing older version s with different pool dictionary definitions.
> >>
> >> =============== Diff against ShoutCore-tpr.61 ===============
> >>
> >> Item was changed:
> >>  ----- Method: SHMCClassDefinition>>sharedPools (in category 'act like a class') -----
> >>  sharedPools
> >>        | d |
> >>        d := Set new.
> >> +       classDefinition poolDictionaries do:
> >> +               [:poolName|
> >> +               (Smalltalk at: poolName asSymbol ifAbsent:[nil]) ifNotNil: [:pool| d add: pool]].
> >> -       classDefinition poolDictionaries do:[:each |
> >> -               d add: (Smalltalk at: each asSymbol ifAbsent:[nil]) ].
> >>        ^d!
> >>
> >>
> >