Re: [testutils] Is there any commons area for generic test code?
Alex Karasulu wrote: Back on topic, I'm fine with guidelines. But I only have general ones at the moment: o I want to minimize dependencies avoiding them whenever possible. o Keep things simple. o This should not be an area for dumping project test code. o Keep the amount of specificity low: meaning this is not where you keep your test cases for testing an LDAP server or a cryptography library etcetera. It should be for generic test utilities in addition to junit used for writing unit tests, beta tests, and stress tests o Commons-test should be here for making your domain specific TestCases all that much easier to write while avoiding the duplication of common testing and setup code. Alex Hi Everyone, contrary to as someone pointed out on this thread I think this subject is very exciting. For my development projects I have also founded a package of extensions for JUnit testing: The following areas were important so far: - Assertions for common issues: instanceof, thrown exceptions, array element equality etc. - Threading: validate error free execution and termination of threads. - Futures: constraints Future objects. - Beans: validate property accessors and property change events. - DataObject: validate implementation of equals, hashCode and serialization. - Logging: add log interface to TestCase - Watchdog: terminate test after maximum execution time. Some extensions are static and others integrate with the JUnit framework, ie. inherit from TestCase in order to maximize automation. The intention of the extensions was to permit to write JUnit test-cases quickly without duplication and simple access to the features also for the not-so-seasoned JUnit users. So these extensions are all accessible through one TestCase class: BellsAndWhistlesTestCase. This is all to say that I encourage the effort to found the sandbox project. I will try to contribute from these if suitable once the test project materializes. For these extensions dependencies on Logging, BeanUtils and even Functors have been introduced. I do not see the need to avoid dependency in a test-utils project. Test-utils are used during the development and are usually not part of the developed product. I would not put the minimization of dependencies too high on the agenda, as the testing has a different scope. For the name, IMO 'testutils' is a better choice than 'test' as it provides for less ambiguity. Maybe even the focus on UnitTesting should be highlighted: 'unittestutils'. Cheers, Arnd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Functor] [patch] IsInstanceOf
Dear All,
I have started using the sandbox functors for my projects. It seems
that parts of the code may still need some streamlining.
I gave a shot at IsInstanceOf.
Please receive attached a patch which changes IsInstanceOf from a
UnaryPredicate to a BinaryPredicate (as the binary operator instanceof )
I tried to structure it in the same way as the Predicate IsElementOf.
In this way the code becomes more compact and more coherent in addition
of providing all three kinds of Predicates.
Unfortunately, the changes are not backward compatible since it has
become now a BinaryPredicate, which I hope it not of show-stopper
importance at this stage of project.
Can the maintainers please consider the application of this patch.
I plan to regularly contribute to this projects in the future and I
really hope that this project is not doomed, which the lack of exchange
on its behalf may suggest.
Cheers,
Arnd.
Index: src/java/org/apache/commons/functor/core/IsInstanceOf.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/functor/src/java/org/apache/commons/functor/core/IsInstanceOf.java,v
retrieving revision 1.2
diff -u -r1.2 IsInstanceOf.java
--- src/java/org/apache/commons/functor/core/IsInstanceOf.java 28 Feb 2004 03:35:24
- 1.2
+++ src/java/org/apache/commons/functor/core/IsInstanceOf.java 28 Apr 2004 19:11:20
-
@@ -15,9 +15,13 @@
*/
package org.apache.commons.functor.core;
-import java.io.Serializable;
-
+import org.apache.commons.functor.BinaryPredicate;
+import org.apache.commons.functor.Predicate;
import org.apache.commons.functor.UnaryPredicate;
+import org.apache.commons.functor.adapter.BoundPredicate;
+import org.apache.commons.functor.adapter.RightBoundPredicate;
+
+import java.io.Serializable;
/**
* [EMAIL PROTECTED] #test Tests}
@@ -28,47 +32,55 @@
* @version $Revision: 1.2 $ $Date: 2004/02/28 03:35:24 $
* @author Rodney Waldhoff
*/
-public final class IsInstanceOf implements UnaryPredicate, Serializable {
+public final class IsInstanceOf implements BinaryPredicate, Serializable {
-// constructor
-//
-public IsInstanceOf(Class klass) {
-this.klass = klass;
+/** Public constructor not needed, since one instance should always suffice. */
+private IsInstanceOf() {
}
-// predicate interface
-//
-public boolean test(Object obj) {
-return klass.isInstance(obj);
+/** Tests if an object is an instance of the type given.
+ * @param instance The candidate of which the type is under question.
+ * @param klass The class.
+ */
+public boolean test(Object instance, Object klass) {
+return ((Class)klass).isInstance(instance);
}
-
-public boolean equals(Object that) {
-if(that instanceof IsInstanceOf) {
-return equals((IsInstanceOf)that);
-} else {
-return false;
-}
+
+public String toString() {
+return IsInstanceOf;
+}
+
+/** The singleton instance. */
+private static final IsInstanceOf INSTANCE = new IsInstanceOf();
+
+/** Returns the IsInstanceOf instance. */
+public static BinaryPredicate instance(){
+return INSTANCE;
}
-public boolean equals(IsInstanceOf that) {
-return (null != that (null == this.klass ? null == that.klass :
this.klass.equals(that.klass)));
+/** Returns an UnaryPredicate which tests if an argument is of the specified
class. */
+public static UnaryPredicate instance(Class klass){
+return new RightBoundPredicate(instance(),klass);
}
-public int hashCode() {
-int hash = IsInstanceOf.hashCode();
-if(null != klass) {
-hash ^= klass.hashCode();
-}
-return hash;
+/** Returns a Predicate which tests if a specified argument is of the specified
class. */
+public static Predicate instance(Object instance, Class klass){
+return new BoundPredicate(instance(klass),instance);
}
-public String toString() {
-return IsInstanceOf + klass + ;
+/**
+ * @see java.lang.Object#hashCode()
+ */
+public boolean equals(Object that) {
+return that instanceof IsInstanceOf;
}
-// attributes
-//
-private Class klass;
-
+
+/**
+ * @see java.lang.Object#hashCode()
+ */
+public int hashCode() {
+return IsInstanceOf.hashCode();
+}
}
Index: src/test/org/apache/commons/functor/core/TestIsInstanceOf.java
===
RCS file:
Re: [functor] some thoughts
Rodney == Rodney Waldhoff [EMAIL PROTECTED] writes: Arnd - functors are very often defined (in my experience) as anonymous Arnd inner classes, therefore it would be nice if the to be Arnd implemented methodname is as short as possible for not Arnd compromising the readability of the code. I would suggest Arnd eval() instead evaluate(), is() instead of test() and Arnd run() is already short. Rodney The letters uate are a rather small part of what makes Rodney defining blocks as anonymous inner classes in java Rodney syntactically awkward, but there may be something to your Rodney argument there. While I have an opinion, any isomorphic Rodney representation of these interfaces is pretty much OK with Rodney me. Now that you write it, it is as well obvious to me that eval is in fact an abbreviation and does not exist as an english word (at least outside of the tech (err ... that is 'technology' ;-) community). In general I do not like abbreviated words as identifier names. My reasoning is that it obfuscates the programmers intention and may imply futile documentation. I don't think that eval() obfuscates evaluate(), but this is obviously just my opinion since eval() does appear awkward to you as a replacement for evaluate(). Arnd - IMHO Predicate.test() is (in a world of JUnit testers) a bit Arnd misleading, since test has overloaded semantics. I like Arnd is(). Rodney I'm also a little troubled by Predicate.test, but more so by Rodney Predicate.is. My thinking was that in most cases, the Rodney method-name for the functor is a verb that can be applied to Rodney the functor. I.e., you run a Procedure or evaluate a Rodney Function, but you don't is a Predicate. (And similiarly, Rodney you could look at those verbs as applying to the arguments Rodney of those functors.) My preference would have been for Rodney Predicate.assert, but that's out for obvious reasons, or Rodney Predicate.evaluate, but I think we want to keep the Function Rodney and Predicate signatures different. Your arguments are coherent for the current method names and I tend to agree. In principle all functors are Functions. Predicates are functions which have boolean results. Procedures are Functions which have VOID results. So these three concept may all be evaluated. But for Procedures we know already that the result is not interesting therefore they the associated action may be run which does not imply a result (as evaluate does). Furthermore Predicate is a Function which if evaluated produces a boolean result. Using evaluate as an action would not imply the contraint result type. However is does imply that the outcome is boolean. So from this 'result' angle is may not be such a bad choice. Rodney Recently it occurred to me (following the language Backus Rodney uses in Can Programming Be Liberated from the von Neumann Rodney Style? Rodney http://www.stanford.edu/class/cs242/readings/backus.pdf, Rodney and is sometimes used in mathematical circles) that it might Rodney be reasonable to say you apply a Function (i.e., Rodney Function.apply), which would free up evaluate for the Rodney Predicate method. I could agree on apply (if it leads to eliminating test). However apply, does in my limited english language understanding not imply a result and a result is somehow what is interesting when using a Function. Cheers, Arnd. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Functor debate
Stephen == Stephen Colebourne [EMAIL PROTECTED] writes: 1. Functor Types - Function: Functor which has a result - Predicate: Functor which has a boolean result - Procedure: Functor which has no result 2. Number of Arguments - *Unary*Functor: one argument functor - *Binary*Functor: two argument functor - Functor: (Null-ary) no argument functor Stephen I don't dispute that this is the 'correct' or 'right' Stephen design for a full functor implementation. However this is Stephen very much bigger in concept, and in 'religion', than [lang] Stephen could support or would wish to. [lang]s functors do not Stephen have this goal - they aim to be simple commonly used Stephen callback interfaces. If the bigger concept 'functor' does compromise the narrower 'callback' scope of the current [lang].functor package then the package should be renamed to more explicitly state its scope. [lang].callback would in my opinion much more appropriate. The package name [lang].functor is not only misleading about its scope but will certainly lead to confusions with the 'heavier' concept functor. So if the renamings, which I suggested earlier, are not acceptable (which I agree on since the scope of the package is to standardize commonly used callback interfaces (and not more)), then it is a good idea to rename the package to a better name. I suggest that [Lang].functor is renamed to [Lang].callback. What do you think? Cheers, Arnd. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] scope for version 2
Henri == Henri Yandell [EMAIL PROTECTED] writes: Henri Been a while since the last one of these, so I expect a few Henri bits to be missing. Feel free to chime in on things I've Henri missed: Henri Next release will be Lang 2.0. Henri Lang 2.0 scope: Henri org.apache.commons.lang.functor.* HenriThere is obviously a clash with Collections here, which HenriLang seeks to Henri resolve. Also there is a clash with Rodney's [Functor] Henri package. From what I understand, despite the similar naming, Henri [Functor] goes a lot further into the concepts than .functor Henri does, with .functor being a simpler setup etc. I'm going on Henri hearsay though, not having looked at the code yet. Dear All, my opinion on lang.functor probably comes too late to have any impact on the course of the release of Lang. But still feel the urge to express my feeling that something goes into the wrong direction with lang.functor. In my opinion lang.functor should not enter 2.0 in the current state: The major issue which I have is the naming of the interfaces. While names like UnaryFunction or BinaryProcedure may sound a bit esoteric for the unaccustomed ear, these names do however expose the real nature of the interface or their implementations. - Executor is the interface for something which is executed not as the name suggests something that executes. If renamed to UnaryProcedure, I would be able to grasp the nature of this interface and its associated Utils class without refering to the javadoc. - While the notion of Factory is widely known and the nature of this interface is well exposed by the class name, one may wonder why a creational pattern like Factory is found in generic functor package. The name Factory suggests that this interface should only be used in Factory contexts. IMHO, Function (in the context its of Unary and Binary counterparts.) is more general and allows for the same purposes originally intended. The user programmer may then class WidgetFactory implements Function or class WidgetFactory implements UnaryFunction if the Widget creation should be parameterized with one argument. How would we proceed in the future if the names are not changed and we would like to introduce parameterized Factories? UnaryFactory? - Predicate is fine as a name. - Transformer does imply an argument. But does it imply as well that there is a result? Furthermore, the name somehow suggests that it is to be used to 'transform' objects, which is in my experience never the case: The argment object is usually left unchanged while a result is calculated as function of the argument object. Wouldn't UnaryFunction not be a more indicative name for this interface? I believe that the names where chosen with the intent to gradually remove the counterparts in Collections. However, currently there is no dependence of Collections on Lang.functor, so renaming the interfaces would not do any harm. Of course I aggree that the migration of Collections to lang.functor would be quite smooth. However, in the longterm Collections will have to live with the same naming problems as I have described above. I suggest to do the following renamings in for Lang 2.0: - Executor-- UnaryProcedure - Executor.execute(..)-- UnaryProcedure.run(..) - Factory -- Function - Factory.create() -- Function.apply() - Transformer -- UnaryFunction - Transformer.transform() -- UnaryFunction.apply(..) - rename all the Utils classes accordingly - possibly complement with missing interfaces: - Procedure - UnaryPredicate - possibly add BinaryPredicate, BinaryProcedure, BinaryFunction Then in the future the functor component (currently in Sandbox) may grow up as a place for more advanced functor stuff (also to complement collections) based on the interfaces provided in lang.functor. Of course, these proposals look like major changes right before a release. And performing major changes right before a release is very risky and should be avoided. However, while the changes seem major, they are only renaming refactorings which could be implemented quickly without changing any algorithms or functionality. If the lang.functor is not improved now before the Lang2.0 it may never be improved and collections will always rely on questionably named interfaces and probably Collections will never live up to its opportunities. Cheers, Arnd. PS: Please have a look at commons-sandbox-functor. Further, if you have some time at hand to get inspired about functors read http://c2.com/cgi/wiki?BlocksInJava . PPS: Please excuse if I have tripped over some jakarta rules and regulations. I have only been following jakarta commons for a several months and may not be well accustomed to jakarta release interaction protocols. PPP: I would of course volounteer to implement the suggested changes myself, I they were generally aggreed upon.
Re: [lang] Functor debate
Stephen == scolebourne [EMAIL PROTECTED] writes: from: Arnd Kohrs [EMAIL PROTECTED] I suggest to do the following renamings in for Lang 2.0: - Executor -- UnaryProcedure - Executor.execute(..) -- UnaryProcedure.run(..) - Factory -- Function - Factory.create() -- Function.apply() - Transformer -- UnaryFunction - Transformer.transform() -- UnaryFunction.apply(..) - rename all the Utils classes accordingly - possibly complement with missing interfaces: - Procedure - UnaryPredicate - possibly add BinaryPredicate, BinaryProcedure, BinaryFunction Stephen You are correct in your evaluation that the names chosen do Stephen not allow for other later functions, such as Binary or Stephen no-argument forms. They are instead chosen to be simple. I don't agree that the current names chosen in lang.functor are simple, and provided arguments for it in my first post (which you dit not respond to). I do not make this up: When I read about a lang.functor package to be included in 2.0, I checked it out, and was as confused when I browsed over the class names, as people would be about the other functors when first encountering. I needed to look-up for example Factory and then mapped it in my mind to no-arg function. Factory by itself does not sufficiently explain its nature. To put it differently, I suggest a renaming refactoring because the current naming is not indicative enough nor coherent. Stephen My rule of thumb is [lang] simple, other project ([functor] Stephen in this case) higher level/more complex. You're never going Stephen to convince me that 'BinaryPredicate' is simple in concept Stephen even if it is the formal computer science solution. IMHO it does not serve a rational evaluation of my proposal to choose 'BinaryPredicate' as an example - which I did not suggest to be added to lang.functor (only as a possibility). The addiction of binary functors to lang is not important now. - and which does not have a lang.functor counterpart in the current lang.functor package: Obviously it is not as simple as a NON-existing concept. PS: Please have a look at commons-sandbox-functor. Further, if you have some time at hand to get inspired about functors read http://c2.com/cgi/wiki?BlocksInJava . Stephen Yes I've taken a look before, and the concepts seem Stephen sound. However, it requires you to invest more effort in Stephen learning the framework and its intracies - it is more Stephen complex. As such I know that I would not choose to use the Stephen complex functors. Whereas I find those in [lang] simpler, Stephen if less flexible. Everythings a tradeoff ;-) I find it easier to adopt a conceptual framwork which has a coherent naming convention. There is not coherence in Executor, Transformer, Factory and Predicate although the coexitence of in the same package would suggest so. All which needs to be understood if these functors where renamed following the naming which are customary in functor libraries and which I referred to, is founded on two orthogonal concepts: 1. Functor Types - Function: Functor which has a result - Predicate: Functor which has a boolean result - Procedure: Functor which has no result 2. Number of Arguments - *Unary*Functor: one argument functor - *Binary*Functor: two argument functor - Functor: (Null-ary) no argument functor Once these two axises are understood there is no need to provide extra explanation for instances of Functor interfaces in this space. This is not the case for, Factory, Transformer and Executor. Example BinaryPredicate: is a Functor with a boolean result which has two arguments. It is not necessary to understand possible extensions of this concept, e.g. internal iterators or functor composition. At least not more as if one wanted to use Transformer. For Lang2.0 I would only go as far as limiting functors to Null-ary and Unary functor interfaces, as there currently seems to be no need for Binary functors. I see the lang.functor as a light-weight place for standardizing interfaces of functors. Then other components may provide internal iterators or related interfaces based on lang.functors such as Collections. And functor utility components may provide the compositions and default implementations using the same functor interfaces which are defined in Lang. If lang cannot provide a functor package which may be used as a standard or if this is out of the lang scope, the incoherent current approach to functors may discourage the evolving and adoption of a functor component with a broader scope. Therefore, without modifications, I would opt for dropping functor from lang, and leave the rudimentary functor stuff in collections, as the lang package does not aim for a broader scope. Please take no offense in my argumentation. I know that a lot of people have strong feelings about functors and I
Re: [beanutils][digester] about time for a release?
robert == robert burrell donkin [EMAIL PROTECTED] writes: robert there is one more matter that i think should be robert considered. we've had several requests to make robert MethodUtils.getMatchingAccessibleMethod(). you know my robert opinions on the current MethodUtils API but i don't really robert think that adding this method will make things worse than robert they are already. should this be made public? Yes please. There is no point of hiding getMatchingAccessibleMethod() while invokeMethod() is public. so I am all +1. Cheers, Arnd -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Beanutils] MethodUtils: private getMatchingAccessibleMethod()
Robert == robert burrell donkin [EMAIL PROTECTED] writes: Robert On Thursday, December 19, 2002, at 05:53 PM, Arnd Kohrs Arnd is there any particular reason why Arnd MethodUtils.getMatchingAccessibleMethod(...) should have Arnd private access? Robert yes - but it's a long story (and a little bit political) :) I guess the reason is that it would be too hard to document its behavior exactly ;-). However, since I can use MethodUtils.invokeMethod(...), I have implicitly access to it. My use of it would be the validation of arguments for the creation of a closure which evaluates to a call to MethodUtils.invokeMethod(...). So that if a closure is constructed without throwing an IllegalArgumentException, it is valid and may be executed without anticipating a NoSuchMethodException. Robert if you want it public, why not roll your own version from Robert the source? Overhead of duplication! I don't understand why a method which invokes a loosely specified method is public, but a method which just tells me if a loosely specified method exists needs to be private? May be my reasoning has some merit, and MethodUtils.getMatchingAccessibleMethod() can be changed to public. If this is not possible then maybe invokeMethod(...) should be deprecated. Cheers, Arnd. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
