> But Chris, Dictionary>>#at: has already been heavily optimized via scanFor:.
> Here's the original Smalltalk-80 v2 code:
>
> Dictionary methods for accessing
> at: key
> "Answer the value at key.  If key is not found, create an error message."
>
> ^self at: key ifAbsent: [self errorKeyNotFound]

No it hasn't, what do you mean?     See, ^^^ right there, there's no
call to #scanFor:, and nor should there be, ever.  Please don't do it.

> at: key ifAbsent: aBlock
> "Answer the value at key.  If key is not found, answer the
> result of evaluating aBlock."
>
> | index |
> index _ self findKey: key ifAbsent: [^aBlock value].
> ^(self basicAt: index) value

This method takes a block.  I said in my note that methods that take a
block are fine to be optimized because passing a block requires
writing code which is a 'developer' role anyway.

> ... snip...

> Here's the current Squeak code
>
> at: key
> "Answer the value associated with the key."
>
> ^ self at: key ifAbsent: [self errorKeyNotFound: key]

Yup.  No #scanFor:.  Good.  This is a method that absolutely should
_not_ be inlined unless the VM can do it outside the users eyes.

> In the v2.0 code, at: always creates a block, at:ifAbsent: always creates a
> block (which means two block activations on error), and the scan for
> elements is three activations deep.
>
> In Squeak, at: always creates a block, but at:ifAbsent: never creates a
> block (which means one block activation on error), and the scan is two
> activations deep.  Note also that findKeyOrNil: wraps around, making more
> than a single pass if it can't find an element whereas scanFor: makes at
> most a single pass.
>
>  The Squeak code is much better.  Has the optimization made the code any the
> less reusable or elegant?  I find it no less reusable and more elegant.
> scanFor: is a better thought-out kernel than findKeyOrNil:.  So optimization
> doesn't always make things less readable, reusable or elegant.

As I said, methods that take a block are fine to be optimized because
passing a block requires writing code which is a 'developer' role
anyway.

 - Chris