tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harish Krishnaswamy <hkrishnasw...@comcast.net>
Subject Re: [DISCUSS] Backward compatibility
Date Thu, 14 Aug 2003 14:20:52 GMT
No argument there, you just converted me!

-Harish

Howard M. Lewis Ship wrote:

>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
>>>
>>>
>>> 
>>>
>>>      
>>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>  
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message