Hi Eliot,
On 11/26/2013 7:15 PM, Eliot Miranda wrote:
Hi Florin,
I actually liked overrides a lot - I should have emphasized that
(especially that there are seemingly so many things that I don't
like :) - must be the age).
It was, from my point of view, the one saving grace for Store (as
compared to Envy, which was otherwise fantastic (and it had atomic
loading).
I am sorry, I did not really understand your alternative approach
from that message. What I had in mind was, on one hand, to remove
any restrictions for what an override can do (I don't remember
exactly, but I think there were some unnecessary restrictions), on
the other hand, specify in the override itself what it expects the
overidee to be. These override expectations should be in the form of
source code (method formatted source, class structure...), not
versions or some such.
The fact that the override specifies its expectations not only makes
it likely that it will work when they are met, but also implies that
they were tested in that configuration by their developer. The
expectations for each override should be a collection, not a single
source, since this would allow to load multiple packages that
override the same things. One of the expectations would be the base
variation, another would be after a known other package overrode
it...
Cheers,
Florin