Overrides. Evil. Need to do something with it.

Hello,

there is a certain critial places in system, which should not be
overridden by external packages.
Otherwise, it becomes a mess and usually leads to malfunction in key
system parts: compiler, special objects etc.

I'd like to propose to introduce a special marker pragma for methods,
which should _never_ be overridden by external package.

myMethod
  <doNotOverride>

an MC code loader should honor this pragma, and do not attempt to
override this method when installing a package
or at least ask user that there is a risk of getting serious problems,
if you override this method.

What you think?

--
Best regards,
Igor Stasenko AKA sig.

> myMethod
>    <doNotOverride>

> What you think?

It seems to me that this is half-way from proper defining of an API.
Why not be more explicit by specifying which API relies on that method,
like:

myMethod
   <API: myGreatApp>

This would imply that it should not be overidden, but then if the user
wants to override it nonetheless he would know what API he is messing up
with.

Stef

2010/5/5 Stéphane Rollandin <[hidden email]>:
>> myMethod
>>   <doNotOverride>
>
>> What you think?
>
> It seems to me that this is half-way from proper defining of an API.
> Why not be more explicit by specifying which API relies on that method,
> like:
>
I don't think so. A method, which should not be overridden belongs to
a class where its defined.
And a class belongs to certain package.
So, there is already enough information what API owns that method.

And if you are talking about overriding an extension provided by
another external package...
i.e. when original method has category: *Foo-extensions
and installed package tries to override with with own *Bar-extensions
it should be prohibited at all, without giving any chances to load
this package into a system.


> myMethod
>  <API: myGreatApp>
>
> This would imply that it should not be overidden, but then if the user wants
> to override it nonetheless he would know what API he is messing up with.
>
> Stef
>


--
Best regards,
Igor Stasenko AKA sig.

On 05.05.2010, at 07:15, Igor Stasenko wrote:
>
> 2010/5/5 Stéphane Rollandin <[hidden email]>:
>>> myMethod
>>>   <doNotOverride>
>>
>>> What you think?

I think that's nonsense ;)

Overrides are evil, period.

I'd simply make loading an override a warning the user has to click through. That will teach package authors to not use them willy-nilly. For private use they could override the warning, but their users will probably be annoyed which is a Good Thing.

- Bert -

Hi,

On Wed, May 5, 2010 at 5:12 PM, Bert Freudenberg <[hidden email]> wrote:
> Overrides are evil, period.

question mark.

Imagine some class being loaded that right- and joyfully overrides a
method whose implementation solely consists of sending
#subclassResponsibility to self. I do *not* want to confirm that. It's
*intended*.

Specialisation is an important feature in OOP, right? From time to
time, it's just needed.

Now imagine someone who is not too experienced in Squeak and who wants
to load some interesting package for playing around with it. Those
"Override! Warning! Careful!" messages will quickly repel that person
(at least: deeply unsettle them), and BOOM! we have one more Ruby
programmer. ;-)

Best,

Michael

On 5/5/2010 8:12 AM, Bert Freudenberg wrote:
It's not that people don't understand that overrides are evil. It's
that, at times, if you want to ship something there is simply no
alternative. And yes, I *hate* them.

But if anything I'd push the responsibility the other way around. Show a
warning when you *commit* a package. That way the developer gets to see
it every time they save a new version and hopefully learn about it and
avoid it in the future. Punishing the user of a package doesn't sound
like a good idea to me.

Cheers,
   - Andreas

On 5 May 2010 18:34, Michael Haupt <[hidden email]> wrote: I think we confusing the terms here.
An MC's override is not 'implementing different version of some method
in subclass, while base class already having this method implemented'.
An MC's override is 'overWrite/replace existing method in 3-rd party
class by own version'.
See the difference?

> Specialisation is an important feature in OOP, right? From time to
> time, it's just needed.
>
> Now imagine someone who is not too experienced in Squeak and who wants
> to load some interesting package for playing around with it. Those
> "Override! Warning! Careful!" messages will quickly repel that person
> (at least: deeply unsettle them), and BOOM! we have one more Ruby
> programmer. ;-)
>
A subclass overrides are fine, since they not replacing a method in a
base class.

> Best,
>
> Michael
>
>



--
Best regards,
Igor Stasenko AKA sig.

On 05.05.2010, at 08:34, Michael Haupt wrote:
If something is declared as subclassResponsibility then you are supposed to implement the same method in a subclass, not patch the method itself. Patching is evil.


- Bert -

2010/5/5 Bert Freudenberg <[hidden email]>:

> I'd simply make loading an override a warning the user has to click through. That will teach package authors to not use them willy-nilly. For private use they could override the warning, but their users will probably be annoyed which is a Good Thing.

It would instead be a job fit for Lint. :)

Ian.
--
http://mecenia.blogspot.com/

"Evil" is too strong a word.  Perhaps "unfortunate".   Ideally we would not need overrides, but people do not write ideal code.  Given the fact that people are constantly publishing packages that are imperfect, it is useful for people who use their packages to be able to override things in them.  You can argue that we really ought to fix the packages, but perhaps we don't know enough to fix it properly.

On 5 May 2010 18:35, Andreas Raab <[hidden email]> wrote: err.. how you think its possible? Suppose that i implemented some
extension method.
Then someone else implemented a very same extension method for very same class.
And then user tries to load these two packages one after another and
so, depending of order of loading
this method will be mine or somebody's else.
And depending on order of loading, a package which loaded first, will be broken.
So, you wanna warn developer, like:  'hey.. you know, that there's
somebody else can implement the same extension method?'

> Cheers,
>  - Andreas
>
>



--
Best regards,
Igor Stasenko AKA sig.

On 5/5/2010 8:52 AM, Igor Stasenko wrote:
I think we're talking about different things. What I referred to is
'-override' categories in Monticello, commonly referred to as
'overrides'. It seems you mean situations where the same method is
defined in multiple conflicting packages (what I would call 'method
stealing')?

In this case, yes, you're right there's no way to anticipate that. I
guess informing the user that loading package B conflicts with package A
would be one way to address this (in the same way that missing
dependencies are handled, i.e., giving you the option to proceed through
but strongly discouraging it).

Cheers,
   - Andreas

+1

Freedom to override anything, anywhere, anytime is essential for Smalltalk. It is not evil, just as a DNU hack is not evil, but it does have serious consequences once your code leaves your image and enters another. Freedom comes with responsibilities and consequences.
Banning overrides would be a very bad thing, but tracking and reporting such situations to either/both producer/consumer is a very good thing.
I would prefer a preload scan like the delightful "code-file browser" that collects and informs me about these issues in batch rather than a streaming nag dialog that makes me click as each one files in (reminds me of the Mac-vs-PC Vista commercial....Permission to xxx? shudder).

Regards,
Sam


Sam S. Adams, IBM Distinguished Engineer, IBM Research
Mobile: 919-696-6064, email: [hidden email]
Asst: Kenndra K. Quiles. (732) 926-2292 Fax: (732) 926-2455, email: [hidden email]
<<Hebrews 11:6, Proverbs 3:5-6, Romans 1:16-17, I Corinthians 1:10>>


>
> "Evil" is too strong a word.  Perhaps "unfortunate".   Ideally we
> would not need overrides, but people do not write ideal code.  Given
> the fact that people are constantly publishing packages that are
> imperfect, it is useful for people who use their packages to be able
> to override things in them.  You can argue that we really ought to
> fix the packages, but perhaps we don't know enough to fix it properly.
>
> One of the many ways in which Smalltalk is better than Java is that
> a package can override methods in other packages.
>
> -Ralph Johnson

Hi,

Am 05.05.2010 um 17:40 schrieb Igor Stasenko <[hidden email]>:
> See the difference?

yup. And I fully agree that *this* overriding should be avoided. It's  
nonmodular at best.

The term "overriding" is apparently overloaded, and overloading is an  
entirely different story - this particular example shows why  
overloading is evil. :-)

>
Best,

Michael

On 5 May 2010 19:23, Sam Adams <[hidden email]> wrote:
> +1
>
> Freedom to override anything, anywhere, anytime is essential for Smalltalk.
Sure, as long as you doing this at home.
But don't tell me this is a cool thing, when you authoring a public package.

> It is not evil, just as a DNU hack is not evil, but it does have serious
> consequences once your code leaves your image and enters another. Freedom
> comes with responsibilities and consequences.
> Banning overrides would be a very bad thing, but tracking and reporting such
> situations to either/both producer/consumer is a very good thing.

Its not a bad thing. Either you play under rules, or get banned.
Either you follow the convention, established by community to not
overwrite methods in classes,
which does not belong to your package, and then you can make your
package available for error-free installation into
any community maintained image,
or you don't follow the convention, then you still can offer a users
the way how to download your content,
just not in a form of package, but in a form of an image instead,
where you are free to hack everything and change
anything, and nobody will even think to tell you that this is a bad thing.



--
Best regards,
Igor Stasenko AKA sig.

> Freedom to override anything, anywhere, anytime is essential for
> Smalltalk. It is not evil, just as a DNU hack is not evil, but it does
> have serious consequences once your code leaves your image and enters
> another. Freedom comes with responsibilities and consequences.
> Banning overrides would be a very bad thing, but tracking and reporting
> such situations to either/both producer/consumer is a very good thing.

+1

+1

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