tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin Sampaleanu <colin...@exis.com>
Subject Re: [DISCUSS] Backward compatibility
Date Thu, 14 Aug 2003 13:23:11 GMT
Using or not using I on interfaces is somewhat of a personal preference 
for most people. Certainly I've waffled back and forth on this topic a 
couple of times.

It's nice that you can see an interface is an interface just because the 
I is there. On the other hand, if you follow the (generally accepted as 
good) practice of always trying to program against interfaces except for 
simple value objects, then pretty soon most objects you use are 
interfaces (or their references anyways), and the I is not really doing 
anything for you any longer, and in certain respects getting in the way, 
since the client of that object shouldn't necessarilly care that he's 
dealing with a class or interface. If for example you refactor a class 
into an interface and an impl. class, then all the code that previously 
used the class would have to be changed.     So I think what's really 
more important, is try to program against interfaces where it makes 
sense, and use factories to create/get the objects, so that most code 
using the class in question is oblivious to the object creatioon issue, 
and probably not use the I on interface names, to make changing a class 
to an inteface/class pair easier, if needed at some point in the process...



Harish Krishnaswamy wrote:

> 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
>>>



Mime
View raw message