1 Reply Latest reply on Dec 20, 2010 6:10 PM by areohbee

    Lr API - classes are not final - why not extend them?

    areohbee Level 6

      I just noticed that it is entirely possible to replace static functions or object methods of Lr API classes, or add additional functionality.


      Thus, one way to fix catalog:{set|get}PropertyForPlugin, is to replace the method with something that works. Likewise for other bug fixes that Adobe is not getting to as fast as one might hope.


      Likewise, one could add a deleteOrRemovePhoto method to the catalog which at the present time, could be configured to simply tag them as deleted, and add them to a collection for the user to delete later. Replacing other catalog methods to ignore photos tagged as "deleted".


      I could go on, but hopefully you get the idea at this point.


      All of this begs the question in my mind:


      Is this a really bad idea, or a really good idea? - I have a feeling its one or the other (as opposed to in-between).


      Wanna fix LOC to automatically handle ampersands correctly on both platforms? - you can. But should you? On the one hand, it makes me nervous to be mucking about with stuff for which you can't see the guts, and is subject to change (and for which Adobe has not indicated support for, or lack thereof...). On the other hand, it may often be the most elegant solution, and one that yields the simplest conversion, once Adobe comes around with their own fixes and additions...


      I already know there are gonna be lots of people saying "God no - never do stuff like that!..." So, I'd like to re-frame the question: Is there any wild-n-crazy plugin authors who think this is a good idea?


      PS - Its possible to make classes final by having a __newindex function in the metatable that throws an error if app tries to modify objects. Adobe has not done that, yet, but they could in the future. Will they?...