Hi Jörg,

I like the simplicity annotations can provide.
As Matt has pointed out Annotations do not define types, which makes it
hard to let the compiler do the validation of the code.
We could implement a custom annotation post processor. But that would
require additional setup for users.

Benedikt


2013/2/13 Matt Benson <gudnabr...@gmail.com>

> Hi Jorg,
>   We had at some point talked about whether these could be done with a
> simple annotation.  I had hoped for something that could be expressed in
> terms enforceable by the compiler.
>
> Matt
>
>
> On Wed, Feb 13, 2013 at 10:22 AM, Jörg Schaible <
> joerg.schai...@scalaris.com
> > wrote:
>
> > Hi,
> >
> > Matt Benson wrote:
> >
> > > TBH, I can't recall what the argument was against "Functor" either; I
> > > think it had something to do with potentially confusing users of other
> > > libraries?
> > >
> > > Functor
> > > |_NullaryFunctor
> > > |_UnaryFunctor
> > > |_BinaryFunctor
> > >
> > > *is* the current state.  :)  Now, when I woke up this morning I did so
> > > with another concept floating around in my brain (it may be crazy, or
> not
> > > work):
> > >
> > > interface Arity {
> > > }
> > >
> > > interface Argumented<A extends Arity> {
> > > }
> > >
> > > interface Unary<A> extends Arity {
> > > }
> > >
> > > interface UnaryFunction<A, T> extends Argumented<Unary<A>> {
> > > }
> > >
> > > Bear in mind the goal is to be able to inspect the type of a functor to
> > > determine its arity (momentarily disregarding the fact that this goal
> is
> > > seeming less worth the trouble all the while :P ).  This approach would
> > > make that a bit more complex, but still seemingly doable.
> > >
> > > Thoughts?
> >
> > @Arity(0)
> > interface NullaryFunctor {
> > }
> >
> > @Arity(1)
> > interface UnaryFunctor {
> > }
> >
> > @Arity(2)
> > interface BinaryFunctor {
> > }
> >
> > Crazy enough? ;-)
> >
> > Do those interfaces need an ancestor?
> >
> > - Jörg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>



-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Reply via email to