In general I am also against monkeypatching, but especially for products
that don't have releases quite as often I think it has its valid use cases.
Especially in the enterprise environment, where a client wants a fix
now, its not an option to say "well, we've submitted this patch for the
next Firefox/Thunderbird/Lightning release, but you're going to have to
wait until its available". The client will want a fix asap, so
monkeypatching until the next release is available is the only option.
If that is blocked then forking the Product is the next option and that
is even more ugly than monkeypatching.
If this is restricted, I don't think it should be done generally, but
kept on a per-module basis. This way each product can decide which
modules need to be kept free from hacks.
Philipp
On 10/8/13 5:06 PM, Bobby Holley wrote:
In general, I'm pretty against this kind of monkey-patching if it's made
available to out-of-tree consumers. We should learn our lesson from XPCOM
and recognize what a royal PITA it can be when extensions start to depend
on implementation details. Allowing something to be modified/overridden by
embeddors should be an explicit decision, rather than the other-way around.
bholley
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
