Fair enough.
___
Kito D. Mann | twitter: kito99 | Author, JSF in Action
Virtua, Inc. |
http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter:
jsfcentral
+1 203-404-4848 x3
* Listen to the latest headlines in the JSF and Java EE newscast:
http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF+and+Java+EE+Newscast
* Sign up for the JSFCentral newsletter:
http://oi.vresp.com/?fid=ac048d0e17
On Fri, Apr 6, 2012 at 9:45 AM, Edward Burns <edward.burns_at_oracle.com>wrote:
> >>>>> On Tue, 03 Apr 2012 09:49:10 -0700, Blake Sullivan <
> blake.sullivan_at_oracle.com> said:
>
> B> I assumed that the original designers were enforcing the idea that
> B> Renderers are an implementation detail and not required, however I agree
> B> that the distinction isn't especially important--returning null is
> B> plenty fine.
>
> B> The lame part is that simply making getRenderer() public would be an
> B> incompatible change at this point, so we are stuck adding something like
> B> this to UIComponent:
>
> B> public final Renderer reallyGetRenderer()
> B> {
> B> return getRenderer();
> B> }
>
> >>>>> On Tue, 03 Apr 2012 11:02:04 -0700, Blake Sullivan <
> blake.sullivan_at_oracle.com> said:
>
> B> If a subclass overrode getRenderer(), it likely kept the same access
> B> control:
>
> B> protected Renderer getRenderer()
>
> B> If we changed the superclass to public, the above code would no longer
> B> compile because it would be restricting the access of its superclass.
>
> Thanks for making this concrete for us, Blake.
>
> So at this point I'd like to just drop this thread, concluding it's not
> worth the trouble.
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | homepage: | http://ridingthecrest.com/
>