autoAccessors broken in 4.1 rc5

hello,

Preferences autoAccessor when turned on seems to break badly the Object
#doesNotUnderstand logic.

try this is the latest image:

        Preferences enable: #autoAccessors.
        5 annoyWith: 7

(beware it will hang the image for good)

Stef

I don't understand how these sorts of fragments get into the image.
When you look at 3.9, the only senders of autoAccessors are for a
remove-script apparently to get rid of it.

So my question is:  Given that we are all trying to make the image
smaller and cleaner, how did this happen?

We know better than to half-introduce a feature or half-remove a
feature.  What happened here and do we need to consider additional
quality-control measures to catch these sorts of things?

Here is one example:  Before I version anything in MC, I review the
"Changes" list, and review every single change, to understand and
confirm why it was made.  I *assume* that everyone else does this too;
but then I won't tell you what my mother told me about "assume"..



2010/4/16 Stéphane Rollandin <[hidden email]>:

> We know better than to half-introduce a feature or half-remove a
> feature.

Unfortunately this is quite frequent...

Stef

On Sun, 18 Apr 2010, Chris Muller wrote:
Probably Eliot's closure changes were developed in a 3.8 image, that's how
it was reintroduced. I think it's safe to remove this part from Object >>
#doesNotUnderstand:

(Preferences autoAccessors
  and: [self tryToDefineVariableAccess: aMessage]) ifTrue:
  [^aMessage sentTo: self].


Levente

On 4/18/2010 9:12 AM, Chris Muller wrote:
> So my question is:  Given that we are all trying to make the image
> smaller and cleaner, how did this happen?

Lack of tests.

> We know better than to half-introduce a feature or half-remove a
> feature.  What happened here and do we need to consider additional
> quality-control measures to catch these sorts of things?

More tests.

> Here is one example:  Before I version anything in MC, I review the
> "Changes" list, and review every single change, to understand and
> confirm why it was made.  I *assume* that everyone else does this too;
> but then I won't tell you what my mother told me about "assume".

I do, but what you're seeing here is likely the result of unexpected
side-effects in an infrequently used part of the system. Given the
infrequent use, the only thing that helps us tracking it is more tests.
In particular when we find issues that had been broken as the side
effect of other changes, documenting and testing these relationships is
important.

Cheers,
   - Andreas

I think it's safe to remove this part from Object >>
> #doesNotUnderstand:
>
> (Preferences autoAccessors
>   and: [self tryToDefineVariableAccess: aMessage]) ifTrue:
>   [^aMessage sentTo: self].
>
>
> Levente

I agree, for the meantime there will be no automatic generation of accessors.

I you search for 'auto' in the Preferences Browser you do not find an
entry for enabling the generation of them.

Hannes