Howard Lewis Ship wrote > > HiveMind, the predecessor to Tapestry IoC, had private services & > visibility. In my opinion, it caused more problems than it was worth. > > What I'm hearing is a basic lack of trust between one developer and > another within your team. One possible solution there is to work on > that, or better documentation about how your services are meant to be > used. >
Although I don't know what problems you are talking about I am sure you have a good reason not to have private services. I like what I've seen about Tapestry so far so I trust you on that one. However, I don't think this is a question of lack of trust. Or if you want, yes, I don't trust my team, but I don't trust ME either! After all, many features of languages and frameworks are there because programming is difficult and error prone so we have to prevent us from making mistakes. Thiago H de Paula Figueiredo wrote > > Tapestry itself has many services that aren't supposed > to be used outside it. In other words, private services. The solution? Put > them under org.apache.tapestry5.internal and have a big warning in the > documentation about not using them. > When building out systems, why not declaring all classes, methods and properties as public and put a big warning in the documentation about which ones to use and which not to use? I don't agree with that. I'm not saying it would be better to hide those Tapestry services because I don't know the consequences. Until I know why, I must trust Howard when he says it is better this way. But I still think private services make sense. Thank you all for your comments! -- View this message in context: http://tapestry.1045711.n5.nabble.com/How-to-define-a-private-service-a-service-only-for-another-service-tp5597443p5602960.html Sent from the Tapestry - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
