You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Andrew Swan (JIRA)" <de...@velocity.apache.org> on 2008/01/22 05:06:39 UTC
[jira] Created: (VELOCITY-582) Allow invocation of public methods
in non-public classes
Allow invocation of public methods in non-public classes
--------------------------------------------------------
Key: VELOCITY-582
URL: https://issues.apache.org/jira/browse/VELOCITY-582
Project: Velocity
Issue Type: Improvement
Components: Engine
Affects Versions: 1.5
Environment: Any
Reporter: Andrew Swan
I was tempted to log this as a bug, however according to this comment it's a feature:
https://issues.apache.org/jira/browse/VELOCITY-214?focusedCommentId=12323932#action_12323932
In any case, Velocity's requirement for all called methods to be in public classes forces developers to violate proper OO encapsulation by exposing implementation details. For example, consider this interface:
public interface Foo {
int getFooCount();
}
And a non-public implementation:
class FooImpl implements Foo {
public int getFooCount() {
return 0;
}
}
And a provider of Foo instances (in the same package as FooImpl):
public class FooService {
public Foo getFoo() {
return new FooImpl(); // only this class should know what type of Foo is being created
}
}
This is good OO code as it stands, however Velocity forces us to make FooImpl a public class. Although this allows Velocity to work properly, it also allows all other classes in the application to access the FooImpl class for themselves, creating the risk of excessive coupling and diluting the benefit of using interfaces in the first place.
This wouldn't be so bad in a new project, but in my existing Velocity-based enterprise application of over 3000 classes, I can't be sure which of these can be properly non-public and which have to be made public just for Velocity's sake. In other words, there's no way to work out which ones might be (or might end up being) invoked by a template (particularly given that many of them are properly hidden behind interfaces). This means I'm not at liberty to refactor my code in the interests of proper encapsulation, because I run the risk of breaking a Velocity template. To me this is a big cross against Velocity, and if we weren't already using it heavily, I'd switch to an alternative templating tool. So any priority or importance that can be assigned to this issue would be greatly appreciated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Commented: (VELOCITY-582) Allow invocation of public methods
in non-public classes
Posted by "Nathan Bubna (JIRA)" <de...@velocity.apache.org>.
[ https://issues.apache.org/jira/browse/VELOCITY-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561224#action_12561224 ]
Nathan Bubna commented on VELOCITY-582:
---------------------------------------
No sweat. Just glad you figured it out and that we don't have to fix this. :)
> Allow invocation of public methods in non-public classes
> --------------------------------------------------------
>
> Key: VELOCITY-582
> URL: https://issues.apache.org/jira/browse/VELOCITY-582
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
> Affects Versions: 1.5
> Environment: Any
> Reporter: Andrew Swan
>
> I was tempted to log this as a bug, however according to this comment it's a feature:
> https://issues.apache.org/jira/browse/VELOCITY-214?focusedCommentId=12323932#action_12323932
> In any case, Velocity's requirement for all called methods to be in public classes forces developers to violate proper OO encapsulation by exposing implementation details. For example, consider this interface:
> public interface Foo {
> int getFooCount();
> }
> And a non-public implementation:
> class FooImpl implements Foo {
> public int getFooCount() {
> return 0;
> }
> }
> And a provider of Foo instances (in the same package as FooImpl):
> public class FooService {
> public Foo getFoo() {
> return new FooImpl(); // only this class should know what type of Foo is being created
> }
> }
> This is good OO code as it stands, however Velocity forces us to make FooImpl a public class. Although this allows Velocity to work properly, it also allows all other classes in the application to access the FooImpl class for themselves, creating the risk of excessive coupling and diluting the benefit of using interfaces in the first place.
> This wouldn't be so bad in a new project, but in my existing Velocity-based enterprise application of over 3000 classes, I can't be sure which of these can be properly non-public and which have to be made public just for Velocity's sake. In other words, there's no way to work out which ones might be (or might end up being) invoked by a template (particularly given that many of them are properly hidden behind interfaces). This means I'm not at liberty to refactor my code in the interests of proper encapsulation, because I run the risk of breaking a Velocity template. To me this is a big cross against Velocity, and if we weren't already using it heavily, I'd switch to an alternative templating tool. So any priority or importance that can be assigned to this issue would be greatly appreciated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Closed: (VELOCITY-582) Allow invocation of public methods in
non-public classes
Posted by "Andrew Swan (JIRA)" <de...@velocity.apache.org>.
[ https://issues.apache.org/jira/browse/VELOCITY-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Swan closed VELOCITY-582.
--------------------------------
Resolution: Invalid
Boy is my face red. One of the interfaces in my admittedly complex hierarchy of interfaces wasn't marked as public. The Velocity template now works fine, even under Velocity 1.4.
Sorry for the confusion; closing this issue as "Invalid".
> Allow invocation of public methods in non-public classes
> --------------------------------------------------------
>
> Key: VELOCITY-582
> URL: https://issues.apache.org/jira/browse/VELOCITY-582
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
> Affects Versions: 1.5
> Environment: Any
> Reporter: Andrew Swan
>
> I was tempted to log this as a bug, however according to this comment it's a feature:
> https://issues.apache.org/jira/browse/VELOCITY-214?focusedCommentId=12323932#action_12323932
> In any case, Velocity's requirement for all called methods to be in public classes forces developers to violate proper OO encapsulation by exposing implementation details. For example, consider this interface:
> public interface Foo {
> int getFooCount();
> }
> And a non-public implementation:
> class FooImpl implements Foo {
> public int getFooCount() {
> return 0;
> }
> }
> And a provider of Foo instances (in the same package as FooImpl):
> public class FooService {
> public Foo getFoo() {
> return new FooImpl(); // only this class should know what type of Foo is being created
> }
> }
> This is good OO code as it stands, however Velocity forces us to make FooImpl a public class. Although this allows Velocity to work properly, it also allows all other classes in the application to access the FooImpl class for themselves, creating the risk of excessive coupling and diluting the benefit of using interfaces in the first place.
> This wouldn't be so bad in a new project, but in my existing Velocity-based enterprise application of over 3000 classes, I can't be sure which of these can be properly non-public and which have to be made public just for Velocity's sake. In other words, there's no way to work out which ones might be (or might end up being) invoked by a template (particularly given that many of them are properly hidden behind interfaces). This means I'm not at liberty to refactor my code in the interests of proper encapsulation, because I run the risk of breaking a Velocity template. To me this is a big cross against Velocity, and if we weren't already using it heavily, I'd switch to an alternative templating tool. So any priority or importance that can be assigned to this issue would be greatly appreciated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Commented: (VELOCITY-582) Allow invocation of public methods
in non-public classes
Posted by "Nathan Bubna (JIRA)" <de...@velocity.apache.org>.
[ https://issues.apache.org/jira/browse/VELOCITY-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561218#action_12561218 ]
Nathan Bubna commented on VELOCITY-582:
---------------------------------------
Hmm. Seems to me if the method is declared in a public interface, that should be good enough. In fact, i thought we changed it in 1.5 so that public method declared in public interface or class worked. I guess i was wrong.
I'd definitely be interested in fixing/changing this. If you have a chance to make a patch, i'll be happy to review and commit. It'll probably be at least a week or two before i have a chance to look into making a patch myself.
In the meantime, anyone else remember if we dealt with this already or discussed it?
> Allow invocation of public methods in non-public classes
> --------------------------------------------------------
>
> Key: VELOCITY-582
> URL: https://issues.apache.org/jira/browse/VELOCITY-582
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
> Affects Versions: 1.5
> Environment: Any
> Reporter: Andrew Swan
>
> I was tempted to log this as a bug, however according to this comment it's a feature:
> https://issues.apache.org/jira/browse/VELOCITY-214?focusedCommentId=12323932#action_12323932
> In any case, Velocity's requirement for all called methods to be in public classes forces developers to violate proper OO encapsulation by exposing implementation details. For example, consider this interface:
> public interface Foo {
> int getFooCount();
> }
> And a non-public implementation:
> class FooImpl implements Foo {
> public int getFooCount() {
> return 0;
> }
> }
> And a provider of Foo instances (in the same package as FooImpl):
> public class FooService {
> public Foo getFoo() {
> return new FooImpl(); // only this class should know what type of Foo is being created
> }
> }
> This is good OO code as it stands, however Velocity forces us to make FooImpl a public class. Although this allows Velocity to work properly, it also allows all other classes in the application to access the FooImpl class for themselves, creating the risk of excessive coupling and diluting the benefit of using interfaces in the first place.
> This wouldn't be so bad in a new project, but in my existing Velocity-based enterprise application of over 3000 classes, I can't be sure which of these can be properly non-public and which have to be made public just for Velocity's sake. In other words, there's no way to work out which ones might be (or might end up being) invoked by a template (particularly given that many of them are properly hidden behind interfaces). This means I'm not at liberty to refactor my code in the interests of proper encapsulation, because I run the risk of breaking a Velocity template. To me this is a big cross against Velocity, and if we weren't already using it heavily, I'd switch to an alternative templating tool. So any priority or importance that can be assigned to this issue would be greatly appreciated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org