Re: Make more fields/methods of service classes protected
Hi Thiago, I didn't want to argue with you, just wanted to explain my opinion (and understand yours). I can accept the decision to stay with private methods althought I do not agree with you reasons ^^ I'll continue to discuss smaller changes (in behaviour) here. Kind regards, Michael. Tapestry internal service implementations and all services (unless stated otherwise, as Autocomplete) were written with the assumption that they won't be subclasses. They're not part of the public API and shouldn't be used directly. Period. Why don't you post here what changes of behavior you want to be done in Tapestry sources and, if we all agree, have it done in the source code itself instead of asking us for something too broad as changing methods and fields visibilities? -- Mit freundlichen Grüßen / Kind regards Michael Wyraz evermind GmbH Schorlemmerstraße 1 04155 Leipzig Tel.: +49 (0)341-25 39 66 - 0 Fax:+49 (0)341-25 39 66 - 1 Funk: +49 (0)177-73 00 00 3 E-Mail: michael.wy...@evermind.de HRB: 21586 Amtsgericht Leipzig Geschäftsführer: Christoph Klemm - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Make more fields/methods of service classes protected
On Tue, 13 May 2014 05:25:22 -0300, Michael Wyraz michael.wy...@evermind.de wrote: Hi Thiago, Hi! I didn't want to argue with you, just wanted to explain my opinion (and understand yours). I can accept the decision to stay with private methods althought I do not agree with you reasons ^^ I'm more than happy to discuss anything related to Tapestry, even the reasons, in which the past and image of Tapestry are a huge factor. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Make more fields/methods of service classes protected
Hi, for extending tapestrys internal service classes it's often required to copy a lot of code because almost everything is private. Why not changing it to protected to allow others to extend those classes? Because it makes keeping backward-compatibility way harder and that's very important for the project. Protected methods are normally not part of the official stable api. So there's no difference for maintaining backward compatibility. I don't see any drawback here Not to mention that protected fields are something to be avoided in OOP. That's true for fields in some cases, right. But IMO does not apply to most methods. Especially in service classes where certain functionality is moved to methods - here one of the most powerful oop concepts is to override those methods to change behaviour. Of course the most advanced way would be to have an abstract basic implementation of each service plus implementions of each aspect of that service. But that would be much overhead in most cases. In addition, you can use advise or overriding for dealing with most problems. Sure, one can use advice to achieve basically the same. But this will cause much more problems: - same backward compatibility issue as if you would override internal methods - but you would not get a compiler message about this. Instead the behaviour would silently fall back to the default. Bad thing! - Much more (and much less readable) complex code for trivial changes. Overriding is only a solution if you have a drop-in replacement for a service. That means in most cases that you have to copy a service and to a change there. Another similar problem are final methods. Last week we created a few custom form field components and we started with extending AbstractField which contains most required stuff. All was fine until we wanted to change the label behaviour: - if a label parameter is bound, use this - otherwise check a custom service - otherwise check the bound parameter for a label annotation - otherwise use defaultLabelProvider But... defaultLabel() is package protected + final. So we cannot: - override the method - test if the parameter is bound (bound is always true when a defaultParam() method exists) So I had to copy the whole AbstractField component to do the simple change. Alternatively I'd have to change/decorate ComponentDefaultProvider but this would change the behaviour in all components, not just those special ones. So how should one solve such problems if so many methods are private (or package protected) and/or final? Kind regards, Michael. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Make more fields/methods of service classes protected
On Mon, 12 May 2014 05:54:31 -0300, Michael Wyraz michael.wy...@evermind.de wrote: Hi, Hi! Protected methods are normally not part of the official stable api. So there's no difference for maintaining backward compatibility. I don't see any drawback here There's a huge difference. If you put anything visible for users (developers), they'll end up using it. If there's someone using it, we just cannot change it without the risk of breaking users' code. From an OOP point of view, protected methods are part of the public API. You're asking from a large change in Tapestry's philosophy. I really doubt other committers would agree, and I don't. I'm just trying to explain why. Not to mention that protected fields are something to be avoided in OOP. That's true for fields in some cases, right. But IMO does not apply to most methods. Especially in service classes where certain functionality is moved to methods - here one of the most powerful oop concepts is to override those methods to change behaviour. Of course the most advanced way would be to have an abstract basic implementation of each service plus implementions of each aspect of that service. But that would be much overhead in most cases. Tapestry internal service implementations were written with the assumption that they won't be subclasses. They're not part of the public API and shouldn't be used directly. Period. In addition, you can use advise or overriding for dealing with most problems. Sure, one can use advice to achieve basically the same. But this will cause much more problems: - same backward compatibility issue as if you would override internal methods You shouldn't override internal methods already. Again, Tapestry service implementations are *not* meant to be subclassed. - but you would not get a compiler message about this. Instead the behaviour would silently fall back to the default. Bad thing! - Much more (and much less readable) complex code for trivial changes. Overriding is only a solution if you have a drop-in replacement for a service. That means in most cases that you have to copy a service and to a change there. Another similar problem are final methods. Tapestry internal service implementations and all services (unless stated otherwise, as Autocomplete) were written with the assumption that they won't be subclasses. They're not part of the public API and shouldn't be used directly. Period. Why don't you post here what changes of behavior you want to be done in Tapestry sources and, if we all agree, have it done in the source code itself instead of asking us for something too broad as changing methods and fields visibilities? -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
Make more fields/methods of service classes protected
Hi, for extending tapestrys internal service classes it's often required to copy a lot of code because almost everything is private. Why not changing it to protected to allow others to extend those classes? Examples: - to temporary fix https://issues.apache.org/jira/browse/TAP5-2219 I had to copy the whole class because XMLTokenStream.openStream() is private. - I'd like to add one more component root that is accessible without prefix (like core). This is a trivial change to org.apache.tapestry5.internal.services.ComponentClassResolverImpl.locate(String, MapString, String) - but I'd have to copy the whole class because the method is private. I had a lot of such situations where I'd like to change minimal behaviour of tapestry's service classes and failed because of private fields/methods. I while ago I was told that private is choosen because the internal classes might change. I think that's a bad reason because if one overrided stuff in internal classes, he has to deal with such changes when the framwork version changes. If one copies the code to do some minimal changes, he'll stuck on the old code when he upgrades tapestry which might cause much more side-effects than overrding just one or two methods. -- Mit freundlichen Grüßen / Kind regards Michael Wyraz evermind GmbH Schorlemmerstraße 1 04155 Leipzig Tel.:+49 (0)341-25 39 66 - 0 callto:+493412539660 Fax:+49 (0)341-25 39 66 - 1 callto:+493412539661 Funk:+49 (0)177-73 00 00 3 callto:+49177733 E-Mail: michael.wy...@evermind.de HRB: 21586 Amtsgericht Leipzig Geschäftsführer: Christoph Klemm
Re: Make more fields/methods of service classes protected
On Wed, 30 Apr 2014 06:43:53 -0300, Michael Wyraz michael.wy...@evermind.de wrote: Hi, Hi! for extending tapestrys internal service classes it's often required to copy a lot of code because almost everything is private. Why not changing it to protected to allow others to extend those classes? Because it makes keeping backward-compatibility way harder and that's very important for the project. Not to mention that protected fields are something to be avoided in OOP. In addition, you can use advise or overriding for dealing with most problems. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
