Overrides. Evil. Need to do something with it.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Overrides. Evil. Need to do something with it.

Igor Stasenko
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.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Overrides. Evil. Need to do something with it.

Simon Denier-3

On 5 mai 2010, at 15:41, Igor Stasenko wrote:

> 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.



I think that the MC loader should ALWAYS warn user when an extension attempts an override, and let him choose (especially as the system does not allow to revert an override for now). Unfortunately the feature has been broken for long. Damien C proposed a solution a long time ago but it didn't work for me. Perhaps the bug is more subtle.


--
 Simon




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Overrides. Evil. Need to do something with it.

Igor Stasenko
In reply to this post by Igor Stasenko
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.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project