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
>
[hidden email]
>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev--
www.tudorgirba.com
"No matter how many recipes we know, we still value a chef."
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Locked
