[Building Sakai] MT deprecation recommendationsfor 2.7

[Mark Norton]

Anthony Whyte wrote:
> I do find it hard to accept the claim that replacing a cover with 
> setter injection leaves one with inelegant, brittle and ugly code. 
> Plus, it's incorrect to say that dependency injection requires the 
> addition of a get method. It doesn't. But code aesthetics is a deeply 
> personal matter so I hesitate to dismiss the assertion as a rhetorical 
> flourish rooted in hyperbole.
While I wouldn't go quite as far as Chuck's rhetoric here, using Spring 
injection inherently relies on side-effects for proper execution of 
code.  Class data is initialized "auto-magically" when the object is 
constructed.  Unless the code is carefully commented (which, I might 
note, the Sakai community has never been all that good at), there is 
nothing in the source code that indicates how a class parameter is 
initialized, because it is specified in a separate XML file.  Unless one 
is knowledgeable of Spring, it can be very difficult to read the code 
and figure out how it works because things happen outside the scope of 
the course file to make it work.
> We should focus on concrete illustrations of the issue.  I earlier cited SAK-12077 (http://jira.sakaiproject.org/browse/SAK-12077) as an example of what it takes to replace static covers with setter injection.  
Not a very good reference, Anthony.  The complete description reads, 
"Remove use of static covers in Service implementations".  Perhaps I'm 
missing something, but it doesn't describe the difficulty of replacing a 
cover with Spring injection.  I'd like to read the description.  Is it 
in another place?

=======================

Another issue I'd like to address is the concept of "Best Practices".  
The reference to "Best Practices for Kernel Code", 
http://confluence.sakaiproject.org/display/SAKDEV/Best+Practices+for+Kernel+code 
defines proposed  recommendations for  kernel code.  Early in the 
document, it mentions "This defines the best practices and standards for 
code being added to the Sakai kernel. This should include suggested best 
practices as well as required standards."  Looking closely, we find that 
"No use of static covers" is indeed included in the minimum requirements 
(read, standards) section.

So here is the thing.  When did the Sakai community consider and decide 
to adopt this (or any other document related to coding practices) as 
standard requirements for Sakai code?  Having led the Sakai Requirements 
Committee for a couple of years, I can state clearly that we never did, 
but not for lack of trying.  My conclusion at that time was that the 
Sakai community wasn't ready  to accept requirements like that.  Now 
there is the implicate that we did indeed agree but that's  just a 
recollection that we discussed it and did NOT come to any consensus at 
the time - even on the basic issue of should we have standards or not.

Personally, I think a case could be made that statics covers are a 
REQUIREMENT of the Sakai architecture.  After all, they've been there 
since the very start of the Sakai code base.  Clearly they were included 
for a reason, but that reason seems to be lost (another casualty of 
inadequate documentation).  Now it may be that the original reasons for 
having covers may not hold any more, but I'm reluctant to arbitrarily 
deprecate them without understanding why they are there in the first 
place.  I have my opinion, which includes ease of use, clarity, and 
clarity.  Others have reasons why they should be eliminated.

Meritocracy suggests that those who write the code get to make the 
decisions.  In general, I agree with that principle, but I also think 
that the MT has a responsibility to the Sakai community to maintain and 
evolve K1 according to the requirements of the community.  Until those 
requirements are clearly established and accepted by the community, 
changes such as deprecating a major feature of the architecture is 
capricious.

That said, best practices as suggestions or recommendations are quite 
reasonable.  By all means eliminate the use of static covers in the 
kernel code if you think that Spring injection is superior, but I call 
on the MT to retain support for static covers of kernel service managers 
for the use of code outside of it (largely Sakai tools).  Deprecating or 
removing static covers is a fundamental change to the Sakai architecture 
and does  NOT have a  wide spread mandate from the community at large.

Respectfully,
Mark Norton