tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksandar Nikolov (JIRA)" <j...@apache.org>
Subject [jira] Commented: (TAP5-909) Against PRIVATE modifier on fields
Date Tue, 27 Oct 2009 22:56:59 GMT

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

Aleksandar Nikolov commented on TAP5-909:
-----------------------------------------

Hm...

Adding getters/setters is just workaround.

I am not familiar with Tapestry "bytecode-level enhancement", (sorry for my question which
might be too amateur) but : 

1. Can't these "bytecode enhancements" be applied at compile time, not at application startup
time, as for example, obfuscators do?

2. Looking at your example I do not understand why for every single class "A" we must search
for possible subclasses and apply them bytecode enhancement. Isn't it much easy and much faster
just do the opposite - find the superclass "A" for each class "B" and apply for its subclass
(class "B") bytecode enhancement?

I really do not understand why changing field modifiers cause such problems. Would you give
me any start point?

> 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.


Mime
View raw message