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] Functor debate
Hello, Would it be at all possible that a full-feature [functor] package extend a basic [lang.functor] package? This would allow for re-use. We would have to argue about which features go where of course... Gary -Original Message- From: Arnd Kohrs [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 11:41 AM To: Jakarta Commons Developers List Subject: 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]
[lang] Functor debate [was re: [lang] scope for version 2]
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 You are correct in your evaluation that the names chosen do not allow for other later functions, such as Binary or no-argument forms. They are instead chosen to be simple. My rule of thumb is [lang] simple, other project ([functor] in this case) higher level/more complex. You're never going to convince me that 'BinaryPredicate' is simple in concept even if it is the formal computer science solution. 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. [functor] appears to be adding this kind of functionality, and as such should also add the corresponding collections utilities. 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 . Yes I've taken a look before, and the concepts seem sound. However, it requires you to invest more effort in learning the framework and its intracies - it is more complex. As such I know that I would not choose to use the complex functors. Whereas I find those in [lang] simpler, if less flexible. Everythings a tradeoff ;-) Stephen 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [lang] Functor debate
From: Arnd Kohrs [EMAIL PROTECTED] Stephen == scolebourne [EMAIL PROTECTED] writes: (My short responses are due to time pressures...) Arnd: 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. snip 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. The coherence is that they are basic callback interfaces. The name functor has been used, however this package should never attempt to be a full implementation of functor concepts or to include the work of [functor]. Its about standardising some very common callback interfaces, and providing implementations of those that can be shared. Are they named correctly? Well perhaps Factory could be called Creator, as this would be in line with the create() method. But otherwise I'm happy. 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 I don't dispute that this is the 'correct' or 'right' design for a full functor implementation. However this is very much bigger in concept, and in 'religion', than [lang] could support or would wish to. [lang]s functors do not have this goal - they aim to be simple commonly used callback interfaces. What I am arguing is that you may be reading too much into the word 'functor' in the [lang] context. What you are arguing for is [functor], which is fine if thats what you want to use. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
