Hi Benedikt, > - we should try to get some more structure into the project. For example we > could create packages for Bean*, Class* and Argument* Interfaces and > classes.
uhm, why you think it should be helpful? ATM only interfaces and BeanUtils class are public - which are the smaller amount of code, and the only APIs exposed to end-users. If we start layering and layering at a certain point we have to make public some implementation, wich is what I'm trying to avoid. Keep in miind that the purpose is making BeanUtils expressive with fluent APIs, and not providing a set of small tools to be reused. > - it would be helpful, if you could give a very short overview over the > general architecture you have in mind. I have read through the source code, > but I'm not quite sure if I get the overall design idea. Also, if there are > implementations that you think are missing, please just let me know what you > have in mind, so I can create a patch. Have a look at current BeanUtils in the proper components, there are a lot of features there that would be good to port - have a look at DynaBean for example, I'll write another email on how I would like those APIs would look alike. Looking forward to hear more from you, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 26, 2012 at 10:56 AM, Benedikt Ritter <b...@systemoutprintln.de> wrote: > Am 26.01.2012 10:28, schrieb Simone Tripodi: >> >> Hi Benedikt! >> > > Hi Simo > > >> don't get crazy with Assertions.* methods, they are just internal >> shortcuts! >> > > okay, I'll just finish my general refactoring and ignore the very special > cases. > > >> OTOH I would focus the attention on public methods to invoke methods >> via reflection, that would be really more useful. >> > > consider it done ;-) > > There are two additional things that I have in mind: > - we should try to get some more structure into the project. For example we > could create packages for Bean*, Class* and Argument* Interfaces and > classes. > - it would be helpful, if you could give a very short overview over the > general architecture you have in mind. I have read through the source code, > but I'm not quite sure if I get the overall design idea. Also, if there are > implementations that you think are missing, please just let me know what you > have in mind, so I can create a patch. > >> Thanks for your efforts! > > > no problem, atm it is a lot of fun for me, and I'm learning a lot. > > >> -Simo >> >> http://people.apache.org/~simonetripodi/ >> http://simonetripodi.livejournal.com/ >> http://twitter.com/simonetripodi >> http://www.99soft.org/ >> >> >> >> On Wed, Jan 25, 2012 at 9:53 PM, Benedikt Ritter >> <b...@systemoutprintln.de> wrote: >>> >>> Hi, >>> >>> I'm refactoring AssertionsTest to match the discussed best practices. I >>> wrote a test method for checkArgument(boolean Argument, String >>> errorTemplate, Object.. errorArgs): >>> >>> @Test( expected = NullPointerException.class ) >>> public void checkArgumentFalseStringNull() >>> { >>> checkArgument( false, ERROR_MSG, (Object[]) null ); >>> } >>> >>> The javadoc for checkArgument is: >>> @throws NullPointerException if the check fails and either {@code >>> errorMessageTemplate} or {@code errorMessageArgs} is null (don't let >>> this happen) >>> >>> but when I execute the test, it fails because I'm getting an >>> IllegalStateException (instead of the expected NPE). Although this is >>> expected if false is passed in, it violates the contract described in the >>> javadoc. I'm not sure what to do now. I could either change the >>> implementation of checkArgument to throw the correct exception if >>> errorArgs >>> is null or change the javadoc (remove the second part of the throws >>> declaration). >>> I would prefer the latter. But then one thing has to be paid attention >>> to: >>> If we call checkArgument(false, ERROR_MSG) and ERROR_MSG contains any >>> placeholders ("%s") and there are no errorArgs given, a >>> java.util.MissingArgumentFormatException will be thrown. So we would have >>> to >>> deal with that. >>> >>> Any thoughts? >>> >>> All the best >>> Benedikt >>> >>> PS: this also applies to checkState(boolean state, String errorTemplate, >>> Object... errorArgs) >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
