On May 30, 2013, at 2:22 PM, Goubier Thierry <[email protected]> wrote:
> Le 30/05/2013 14:09, Stéphane Ducasse a écrit :
>>
>> On May 30, 2
>>> Yes. I can say true become: false, too.
>>>
>>> Overrides can be interesting as a temperer hack. E.g. in Opal development,
>>> I might add an override just to test. Then loading Opal makes
>>> the image package dirty. So later, when I know what I want, I will move
>>> that change to the image.
>>>
>>> You should not use overrides as a concept in delivered software (as it does
>>> not work), so modeling it is wrong as then people will use it.
>>> Yes making it impossible is not nice either, because temporarily I want to
>>> be able to just do it, like I can do all sorts of things.
>>>
>>> So this is more something we should add a rule for in Code Crititque…
>>
>> I'm not sure. Because something you really need them.
>
> I'd be worried then.
>
> Either we have a need for extension where only an override will do... Then
> why not modeling it and critique it when appropriate? Hiding it under an
> extension won't make the problem disappear, it will just hide it.
>
>
But it just does not work: two overrides. Which will be called? Overrides are
like halt: you use is while developing and for hacks, but shipped packages just
can not use it, because there is just no semantic
of multiple overrides.
The only solution is to have system where extensions are private to you, but
than the normal use case for overrides is to "hook into something".
Maybe something on the sub-method level? Packages could register methods to be
called before and after like in CLOS…
But as I said: my brain is full. I just can't think about it now.
Marcus
