[Building Sakai] MT deprecation recommendationsfor 2.7

[Charles Hedrick]

As a programmer, I prefer to use static covers. Avoiding them involves setting up additional mechanisms that adds complexity with no benefit that I can see. The only actual problem I can see is that there's just too many ways to get to services: Spring injection, calling the component manager, and using a static cover. This results in inconsistent coding. If I had my choice I'd remove Spring and use only static covers. In the few cases where we actually want something to be pluggable I'd put a configuration option in sakai.properties. But I guess I'm a Luddite. 

On Mar 20, 2010, at 1:06 PM, csev wrote:

> Anthony,
> 
> I think the fallacy in all of this discussion is that somehow there is a strong feeling in the community that "Static Covers Must Be Removed" - just having a Confluence page that says "Best practice is removing static covers" does not a mandate make.  Does this mean that if I log into the confluence page and edit the text to say "Static covers are best practice" - that the community intent changes?  Perhaps I should do that and then cite my page as "a mandate".
> 
> The very fact that the discussion goes round and round suggests that the community is not in agreement and the different people have different trade-offs.
> 
> Your proposed "compromise" is not a compromise at all - it lets the anti-cover faction "win" over the "anti-anti-cover" faction.
> 
> I think that the real compromise is to do everything that MT folks want to do *except* marking them as deprecated and then making the deprecation decision later after the MT has a lot of experience in "static cover cleanup" - perhaps they will tire of the game after they see how much cleaner static covers are than Spring + Setters.
> 
> All that marking them as deprecated immediately does makes the long-suffering anti-cover folks feel they have a "moral victory" that does not really improve anything at the cost of increasing pain for everyone else who is stuck either investing effort in changing their code or learning to ignore lots of deprecation warnings.
> 
> Probably the thing that bothers me off the most is when the MT comes through my code and removes an elegant single line import of a cover and replaces it with 25 lines of setter, getter, and comments and adds 10 lines of XML in some obscure file - and after they are done and have left with a smug sense of accomplishment - I have to maintain that brittle and ugly code.
> 
> The other thing that such a useless re-factor does is makes it increasingly difficult for folks on earlier versions of Sakai to pull current Sakai code back into those earlier branches.
> 
> But like with all these "patriotic" proposals, conservative "maintain the status quo" arguments to minimize pain and wasted effort always lose against "patriotic pro-glorious-future" arguments and I will just grumble and be forced to follow along. :) 
> 
> /Chuck
> 
> On Mar 20, 2010, at 10:02 AM, Anthony Whyte wrote:
> 
>> The all-or-nothing cast to this discussion is going to lead us nowhere fast.  I put forward a compromise proposal on 17 March and echoed by David Haines on the 19th that offers us incremental, case-by-case approach.  It recognizes that there may be times when a static cover needs to be sacrificed in the interests of providing unit tests that help strengthen the bug fix validation and verification process.
>> 
>> Ensuring that core production code is stable, reliable, maintainable and defect free (to the best of our abilities) trumps, in my view, (inexperienced) developer conveniences or local/contrib implementation decisions.  That said, as Stephen Marquard has pointed out, deprecating and then removing static covers wholesale could well impose extra costs on schools required to refactor static covers out of their local/contrib code.  This needs to be recognized but should not impose an absolute blocker on static cover removal.
>> 
>> So, 
>> 
>> 1.  Deprecate static covers in trunk/2.7.x (this at least provides a Javadoc warning that a cover might in future be removed)
>> 2.  Add further documentation in Confluence regarding Sakai developer best practices with respect to covers.
>> 3.  Address any static cover removal question on a case-by-case basis in Jira and on list (perhaps limited to blocker/critical issues).  
>> 4.  If a static cover removal is justified, do it.
>> 
>> Cheers,
>> 
>> Anth
>> 
>> 
>>> COMPROMISE PROPOSAL (17 March)
>>> I'd like to see static covers eventually removed (so +1) but recognize that the current crowd wisdom appears to consider this desire, well, unwise.  Still, I'd like to suggest a compromise proposal, one that permits the removal of a static cover whenever it impedes the implementation of unit tests written in support of a bug fix.  Extension of 2.x unit test coverage is work that meets a long standing yet largely unrealized goal of the Sakai Community.  Suspending such work because one finds a static cover in the way appears to me unwise.
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> 
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"