Hi,
This is a message that I've been intending to write for some time :). I agree that there can be situations where you override something by mistake, but in Pharo you actually have to be quite unlucky to do it by mistake (I mean you have to create explicitly a category that starts with a * :)). Most often it happens because it is just easier for the given context.
The case in point is in MooseDemoReport which overrides REPConcernSpecification>>open. However, it could be that I am loading an obsolete package, because it looks like MooseComputedConcerns also define similar classes as the other package :)
Cheers, Doru
On 12 Aug 2010, at 18:03, Simon Denier wrote:
On 12 août 2010, at 17:44, Tudor Girba wrote:
Hi,
Please try to avoid overrides in your packages. It makes integration impossible.
Overrides can be useful when you do not have access to the base code. But, in the case of Moose you do have access. Please, raise the point and discuss about it if you are unsure of the change. You will be surprised how often it is actually easy to change the base code, or it is easy to find another solution.
Do not use overrides just because it's comfortable because in the slightly longer run they harm more than they help.
What is the case at hand? I believe that most overrides happen by mistake. Unfortunately the MC mechanism to detect override is still broken. We should fix that.
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"No matter how many recipes we know, we still value a chef."