You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Robert Zeigler (JIRA)" <ji...@apache.org> on 2009/10/27 18:04:59 UTC
[jira] Commented: (TAP5-909) Against PRIVATE modifier on fields
[ https://issues.apache.org/jira/browse/TAP5-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770572#action_12770572 ]
Robert Zeigler commented on TAP5-909:
-------------------------------------
Tapestry does a whole ton of bytecode-level enhancements on page & component classes. The benefit of the requirement is that it makes this process much more efficient. Consider scenarios like:
Class A {
@Property
protected User user;
}
Class B extends A {
super.user....
}
where class B can now be /anywhere/. It could be in your components directory, or it could be in a 3rd party drop-in module. Do you /really/ want Tapestry to have to perform byte-code enhancement on every single page and every single component in every single library included in your app, right at startup? To support non-private fields would effectively require that. I'll take the heavy "burden" of implementing my own getters/setters any day over decreasing T5's startup time. One of the major complaints about T4 was it's slow startup time... I'd rather we not head back down that road.
> Against PRIVATE modifier on fields
> ----------------------------------
>
> Key: TAP5-909
> URL: https://issues.apache.org/jira/browse/TAP5-909
> Project: Tapestry 5
> Issue Type: Wish
> Components: tapestry-core
> Affects Versions: 5.0.18
> Reporter: Aleksandar Nikolov
>
> In Tapestry classes every instance variable MUST be declared private!?!
> Why this requirements exists?
> I agree that it is a good practice to hide and encapsulate the data, but in some cases, especially in extending classes (including your own), this becomes a problem. In subclasses these variables can be accessed ONLY through getter/setters. This is like giving pocket-money to your son using bank account...
> I will give you an example: Imagine you want to access a variable declared in superclass like this:
> @Property
> private User user;
> Must create getter and setter which @Property already does in background!
> I think that this requirement makes difficult using OO techniques like inheritance and should be removed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.