If you can do method parameter annotations, then please just ignore this post...

Parameter annotations are a very useful construct. An example is the JAX-RS(Java + REST) spec that allows you to map parts/pieces of an incoming HTTP request to specific method parameters:

@Path("/customers")
public class Customer {

   @GET
   @Path("{id}")
   @Produces("application/xml")
   public Document get(@PathParam("id") String id) {
     ...
   }
}

Another useful purpose of parameter annotations is in workflow frameworks that allow you to pull in specific information from the workspace to invoke a particular action:

@Action
public void doit(@In("somethingInWorkspace") int value) {...}

I was quite amazed (and happy) to discover that Fan can reflect the names of parameters, so your first example is no longer a use case. Arguably, parameter reflection could even be used to handle the second case, if the name of the parameter reflected the value to retrieve from the workspace.

I think I agree with John. Parameter annotations can feel like Java falling over the edge. They can be useful (as you've shown) but the power comes at quite a readability price. (I dread to think of all the new places annotations might be able to be defined in Java 7).

Part of Fan's beauty is keeping it simple, and I think that applies here.

I've definitely wanted to attach meta-data to method parameters in my past. For example if auto-generating a UI to invoke annotated methods, then you might want something like this:

@userCommand 
Void setTemperature(@min=65; @max=80; @unit=Unit("fahrenheit") Decimal temp)

But I'm not sure I'm ready to take that plunge until it seems really needed. Because facets are so free form and because you can reflect named parameters, it is pretty easy to achieve this today by just annotating the method:

@userCommand
@paramFacets=[
  "temp": ["min":65, "max":80, "unit": Unit("fahrenheit")] 
]
Void setTemperature(Decimal temp)

Although examples like this are good reasons why I'm interesting in Tom's approach to unify maps/symbols/facets.

Erm, why Decimal temp? Surely we should have Temperature as a class to handle these interactions? Or using a similar design with java.util.concurrent.TimeUnit?

@Brian,

Void setTemperature(@min=65 Decimal temp)

Thanks for this example. I totally forgot about the usecase of using param annotations for validation and defining constraints.

@userCommand
@paramFacets=[
  "temp": ["min":65, "max":80, "unit": Unit("fahrenheit")] 
]
Void setTemperature(Decimal temp) 

Your workaround is an interesting one, but hurts readability, is more verbose, and also suffers from possible typo errors that you won't pick up until runtime (not matching parameter names in your metadata).

Parameter annotations was the only thing I really missed from Java, other than that, I'm pretty amazed by the language. Hope you guys gain traction.

@JodaStephen,

Good annotation design usually mitigates verbosity.

BTW, I've heard all these readability arguments before over and over again in Java land. The thing is, metadata has to go somewhere and 80% of the time it makes more sense to have it within your code rather than in an external place especially when applying the annotation affects the behavior of the code. Even in the left over 20% case, many engineers (in my experience 50%) would still want all metadata defined in one place. Well, enough of my rant :)

Not every unit type can fit in the core language. That's my opinion. (I'm actually more biased towards taking out the time type, but it is a very common need, so I haven't recommended it.)

As for the temperature example here, it reminds me of my feature (called roles) in June for unifying type alias, constraints, and extension methods. I'm not sure it's worth it's weight, but as long as we're on the subject, here's how it would work:

@min=65
@max=80
@unit=Unit.fahrenheit // A word like this should be statically typed for sure.
role CommonTemp: Decimal {
  // Extension methods if any go here.
  // They don't look like static methods, but that's what they effectively are.
  // A slight variation on C# extension methods.
}

Again, roles are aliases. An object doesn't dynamically know its role. (It's erased.) But the static slots, such as fields or params do know the role they are expecting, so you could use AOP or whatnot to weave in validations.

Not every unit type can fit in the core language.

I don't believe in using the type system for units of measurement. My career is in control systems, so I'm quite immersed in the issue - the only practical solution is tagging numeric data with meta-data (such as facets). I guess you could call that a "role" like Tom suggested - but isn't part of the type system.

My plan for Fan is to have a standard Unit API and database based on oBIX. oBIX will also likely be the primary built-in XML serialization format for Fan objects.