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.