12 Aug
2010
12 Aug
'10
5:44 p.m.
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.
Cheers,
Doru
--
www.tudorgirba.com
"What we can governs what we wish."
12 Aug
12 Aug
5:58 p.m.
+1
Alexandre
On 12 Aug 2010, at 11: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.
Cheers,
Doru
--
www.tudorgirba.com
"What we can governs what we wish."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
6:03 p.m.
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
13 Aug
13 Aug
5:28 p.m.
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:
--
www.tudorgirba.com
"No matter how many recipes we know, we still value a chef."
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5253
days inactive
5254
days old
3 comments
3 participants
participants (3)
-
Alexandre Bergel -
Simon Denier -
Tudor Girba