[jira] Commented: (TAP5-909) Against PRIVATE modifier on fields

["Robert Zeigler (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TAP5-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788890#action_12788890 ] 

Robert Zeigler commented on TAP5-909:
-------------------------------------

0) Applying getters/setters is NOT a workaround.  It is the java-standard way of providing public access to properties.  The fact that @Property generates getters and setters for you is a convenience provided by tapestry.  

1) Generally, no.  That would eliminate T5's ability to "hot swap" the code when you make changes to page/component/mixin classes.

2) Superclass/subclass was perhaps a bad example.  Generally speaking, Tapestry manages variables by replacing access to them in user-written code with synthetic methods in generated code.  That means tapestry has to find all usages of variable "foo" of class "Bar" and replace it with appropriate synthetic methods... something like _foo() for read access and _foo(value) for write access. Although there may be some very simple cases where the synthetic method replacement isn't necessary, generally it is (consider, for example: @Parameter @Property foo; There's a whole host of code going on to make @Parameter work).   If you allow non-private variables, the scope of classes to search for synthetic method replacement becomes that much larger.  Package protected? Now you have to search every class in the package.  Protected? Search every class in the package.  Subclass compilation will also have to walk the chain of superclasses, as you mentioned.  Public? Watch out!   Basically, by allowing a non-private variable to be controlled by tapestry, you're opening a whole can of worms.  It's just not worth it.  Although if you really feel strongly otherwise, you could try your hand at contributing a patch for this issue.... :)



> 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
>            Assignee: Robert Zeigler
>
> 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.