tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hls...@comcast.net>
Subject RE: [DISCUSS] Backward compatibility
Date Thu, 14 Aug 2003 13:22:29 GMT
It's an evolution of my personal style, which is why it is not a priority for Tapestry, especially
considering the havoc it would cause.

Basically, code should not care whether a type is a class or an interface.  Not distinguishing
between the two simplifies refactoring signficiantly.  HiveMind is all about refactoring code
into
services represented by interfaces, so this is a hot issue for me.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry



> -----Original Message-----
> From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net] 
> Sent: Thursday, August 14, 2003 9:00 AM
> To: Tapestry development
> Subject: Re: [DISCUSS] Backward compatibility
> 
> 
> I am curious as to what prompts the need to strip off the "I" from 
> interfaces. I like to tell apart the interfaces by just 
> looking at the 
> name, though I am certain there is a good reason and would 
> like to know.
> 
> -Harish
> 
> Geoff Longman wrote:
> 
> >>- disallowing old DTDs automatically means that the accumulated 
> >>components
> >>    
> >>
> >CANNOT be used with new Tapestry versions without manual 
> modifications.
> >
> >Y'know I really should think before I open my big yap. Tapestry does 
> >not automaticly disallow old DTDs. 3.0 will still allow the 
> use of the 
> >1.3 version of the DTD. There was a point in the past when 
> all the old 
> >versions were still allowed. (I think that was before 2.4?). 
> Originally 
> >Spindle supported all the old versions of the DTD. But then it was 
> >decided that 1 version back was ok.
> >
> >  
> >
> >>- making incompatible changes to existing components automatically 
> >>means
> >>    
> >>
> >that code working in one version WILL NOT necessarily work 
> correctly in 
> >another.
> >  
> >
> >
> >Sure. But how can one avoid having the framework become a 
> massive ball 
> >of spagetti code in order to support all the old versions? 
> It'll turn 
> >into an M$ product!
> >
> >  
> >
> >>None of this is acceptable.
> >>
> >>We have libraries (not apps) comprising several hundred 
> thousand lines 
> >>of
> >>    
> >>
> >code related to Tapestry and a huge number of components. 
> The transfer 
> >to each new version of Tapestry has been a complete and utter pain, 
> >often taking several days work of the entire company and 
> causing bugs 
> >that we find only later. While this was somewhat okay for the early 
> >Tapestry versions in the view of the larger picture, I think we MUST 
> >now draw the line where this will stop.
> >
> >
> >I think what you are saying is that the days of massive 
> changes to the 
> >framework should come to an end soon. I don't disagree. In 
> fact I have 
> >the same problem right now as we port our app to 3.0. 
> Luckily we only 
> >have about 100 of the soon to be 300+ pages completed before porting!
> >
> >
> >  
> >
> >>This is NOT a made up problem. It is deadly serious. At the 
> very least 
> >>we
> >>    
> >>
> >must have a backward compatibility section of the 
> contributor's guide 
> >(I can help with this if necessary) and adher strictly to it. The 
> >people using the framework are reaching a critical mass and 
> changes in 
> >the names of the interfaces or the objects' behaviour like what 
> >happened in 2.2 (and to some extent in 2.3) would simply not be 
> >tolerated by Tapestry's users.
> >  
> >
> >
> >Then you'll hate Howards latest idea to drop the "I" from all the 
> >interface names. I think the gunslinger days of Tapestry are 
> coming to 
> >an end. Future changes will need to be scrutinized more 
> closely by us 
> >and backwards compatibility needs to become the #1 factor for debate.
> >
> >  
> >
> >>At the same time, there is a demand for some changes and 
> that must be
> >>    
> >>
> >handled in some way (e.g. by completely denying such changes 
> or having 
> >a mechanism to do them). Consider the example I gave -- form 
> listener 
> >invocations. The overwhelming desire was to change the default 
> >behaviour of the listeners to delayed invocation. How do we handle 
> >this? Do we
> >  
> >
> >>- not make this change
> >>- add a second listener binding for those listeners
> >>- do the change using the mechanism that I suggested
> >>- screw everything and do the change anyway.
> >>
> >>Obviously, the second choice is the easy way out in this 
> case, but it 
> >>will
> >>    
> >>
> >not always be possible. What would our standard approach be?
> >  
> >
> >
> >In that particular case why not add a (optional) policy parameter to 
> >the Form component? let the default be the current behaviour. The 
> >policy would apply to all the listeners in the form. Of 
> course then all 
> >the listeners in the form would follow one scheme or the other.
> >
> >Is it really important that the behaviour be settable for 
> each listener 
> >in the form? If so add the policy parameter to the form 
> components with 
> >listeners.  The form would have to mediate. I guess that 
> means another 
> >hidden field.
> >
> >I still think that building permanent backwards 
> compatibility into the 
> >code would be a nightmare. Would be nice if the framework allowed 
> >libraries to use an older version of tapestry. Something like a 
> >containment model. Then you could have libraries using  
> older versions 
> >of Tapestry to interoperate with newer versions. To use the latest 
> >features you would still have to port, but you would not lose the 
> >functionality of existing libraries if you didn't want to 
> port. Or, you 
> >could defer porting until you really needed to.
> >
> >That brings visions of classloaders and such which is getting into 
> >areas I'm not the best authority on. But its an idea.
> >
> >Geoff
> >
> >
> >  
> >
> >>-mb
> >>
> >>Geoff Longman <glongman@intelligentworks.com> wrote:
> >>-1
> >>
> >>On the surface it kinda makes sense. But I imagine there 
> would come a
> >>    
> >>
> >point
> >  
> >
> >>where configuration overhead would become a burdon.
> >>
> >>What really prompts the -1 from me is that once people can mix and 
> >>match
> >>    
> >>
> >the
> >  
> >
> >>behaviour of things, the next step will be mixing and matching DTD
> >>    
> >>
> >versions.
> >  
> >
> >>Say a library using the 1.3 DTD in an app using the 3.0 DTD. YIKES!
> >>
> >>Geoff
> >>----- Original Message -----
> >>From: "Mind Bridge"
> >>To:
> >>Sent: Wednesday, August 13, 2003 10:42 AM
> >>Subject: [DISCUSS] Backward compatibility
> >>
> >>
> >>    
> >>
> >>>Hi,
> >>>
> >>>We have been discussing periodically backward-incompatible changes 
> >>>that
> >>>      
> >>>
> >>will make the framework more powerful. Needless to say, 
> these changes 
> >>are great in the long term, but they do have a cost with respect to 
> >>the developers who are using older versions and want to switch to a 
> >>new one. This problem is bound to become more and more important as 
> >>the number of people using Tapestry increases. I would like 
> to suggest 
> >>an approach that should 'untie' our hands to make some backward 
> >>incompatible changes in general. Here is a good example: 
> the change in 
> >>the form listener behaviour (invoke immediately or delay) 
> discussed a 
> >>while ago.
> >>    
> >>
> >>>The idea is the following: have a standard component 
> property called
> >>>      
> >>>
> >>'org.apache.tapestry.version-compatibility'. The value of 
> the property 
> >>should be a number. It will represent the version which the code 
> >>targets.
> >>    
> >>
> >>>When components introduce backward-incompatible changes in their
> >>>      
> >>>
> >>behaviour, they can check this property to decide how to 
> behave. For 
> >>example, the code that invokes the form listeners can check whether 
> >>the version is <= 3.0 and invoke them immediately, or if it 
> is >= 3.1 
> >>(for
> >>example) it can perform delayed invocation unless specified 
> otherwise. The
> >>result of the check can be stored in the component at load 
> time, so it
> >>    
> >>
> >will
> >  
> >
> >>have no other bearing on performance.
> >>    
> >>
> >>>The following order can be used to search for the property value:
> >>>
> >>>component/page (this will be the enclosing component/page in cases 
> >>>like
> >>>      
> >>>
> >>the above)
> >>    
> >>
> >>>namespace
> >>>application
> >>>... the rest of the standard property search order
> >>>
> >>>This will allow, for example, a library and its components to have
> >>>      
> >>>
> >>3.0-specific code, while the rest of the application is 
> designed for 
> >>3.3
> >>    
> >>
> >or
> >  
> >
> >>sth like that.
> >>    
> >>
> >>>Clearly, this would not help in all cases, but it will definitely 
> >>>make
> >>>      
> >>>
> >>some incompatible changes much easier to make.
> >>    
> >>
> >>>Does this make sense?
> >>>
> >>>Best regards,
> >>>-mb
> >>>
> >>>
> >>>      
> >>>
> >>------------------------------------------------------------
> ---------
> >>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: 
> tapestry-dev-help@jakarta.apache.org
> >>
> >>    
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
> >  
> >
> 


Mime
View raw message