Skip to main content

Functor-based validator in incubator

6 replies [Last post]
dhall
Offline
Joined: 2006-02-17

As I described last week, I checked a functor based validator to my incubator area. Additionally, I've checked in an alternate implementation of NumberMetaData that uses functor-based validation to compare against minimum and/or maximum values. I intend to put in a couple of tests (in development, I tested this by replacing the standard NumberMetaData and using the existing tests: when I add test cases, it'll primarily be exercises of functionality that I believe is new with functor-based validation)

Dave Hall
http://jga.sf.net
http://jroller.com/page/dhall

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
dhall
Offline
Joined: 2006-02-17

>> It is just a function that can be passed as a parameter - or does it have special characteristics?

missed that one:

In general, its basically a function that can be passed as a parameter, or serialized, or stored in a database, or treated like a POJO in many other situations. In jga, I've extended them slightly by adding support for the Visitor pattern to all functors. This allows for a standardized mechanism for interpreting/translating functors other than simply calling their evalutation method.

Dave Hall
http://jga.sf.net/
http://jroller.com/page/dhall/

charles.armstrong
Offline
Joined: 2006-02-17

Dave,

Thanks for the info - I can see how they would provide
considerable flexibility and power for domain specific
validation logic.

To ask the obvious question. Have you looked at Groovy?

IF:
(1) Functors are a subset of Closures???
(2) Groovy supports Closures properly???

THEN:

Maybe JDNC support for Groovy might be an idea (or
Groovy support for JDNC) - especially as they both have
ease of development as a primary goal.

Charles.

dhall
Offline
Joined: 2006-02-17

>> To ask the obvious question. Have you looked at Groovy?

No, based on the descriptions I've seen of it, it is aiming at a different level of abstraction than I am. (Ironically, last summer at JavaOne, I shared a table in the speakers' room with Strachan for a half hour or so: I was unwinding to some Bach on my headphones after having spoken and he was engaged in a discussion about some language issue or another with someone whom I took to be in his experts group)

It seems that scripting is a whole 'nother beast entirely: I think it would be interesting to try out JDNC stuff with a scripting langauge, if only to ensure that we don't somehow close out some useful combination without a very good reason.

I think what I've been working on doesn't rise to the level of a scripting language (OTOH, maybe the hacker's worksheet I pointed to the the functor filter thread leads me in that direction eventually).

Dave Hall
http://jga.sf.net/
http://jroller.com/page/dhall/

charles.armstrong
Offline
Joined: 2006-02-17

Strachan turns up at Java social events a lot in London. I can never understand a word he is saying.

I thought putting closures in a scripting language was an exercise in pretentiousness until I saw your stuff on functors. I can now see how when using a script to configure stuff, passing in a closure gives you the power to do anything nasty like unusual validation logic.

rgds,
Charles.

charles.armstrong
Offline
Joined: 2006-02-17

This all looks interesting.

Could you give me a one line 'functors for dummies' description?

What is the relationship between functors and closures?

It is just a function that can be passed as a parameter - or
does it have special characteristics?

So what makes a functor a functor?

Thanks,
Charles.

dhall
Offline
Joined: 2006-02-17

Charles:

>> Could you give me a one line 'functors for dummies' description?

Being brief is hard work ;)

A functor is basically an object that encapsulates a function call(back).

(they've been defined in a number of subtly or not-so-subtly different ways, and there may be a number of folks who would dismiss my definition as naively oversimplified, or even missing the point entirely. I think that the distinctions being drawn have more to do with the background of the speaker: those with a more strictly theoretical/mathematical background than mine are the ones that would dismiss my definitions.)

One way to think about them is as a generalization of Comparator -- the idea behind Comparator was that it is possible to define sorting in a wide variety of situations if you allow the user to supply a mechanism to 'compare two objects'. There are a number general purpose algorithms (sorting, merging, filtering, simple transformations, validations, etc) where we can define the template of the algorithm but need the user to provide an implementation detail that makes the algorithm tick.

Naturally, there's more material on the links page of my web site, and some material pertaining to my particular implementation and its history on my blog.

>> What is the relationship between functors and closures?

(as a cavaet, let me note that the only language i've spent any significant time working in that supports 'true' closures is perl (and perl, arguably, doesn't)).

Closures tend to imply a little more capability at the lexical level: when you write a closure, the closure exists in a context that may (depending on the language) include access to some information that is lexically in scope at the point of definition. Java accomplishes (approximates) this by letting you do anonymous classes, though it imposes the restriction that you may only access variables in the enclosing scope that are declared final (and there may be some games being played in the .class files that have security/access implications).

One of the things that I set out to do was to make working with the 'standard' functor set (as defined by C++ STL) easier. To support this, I thought that it would be interesting to be able to parse expressions into compound functors. Doing this lets us get away from defining classes in these common situations: we can define a single implementation at compile time and supply the functor at runtime. Making arbitrarily compound functors easier to write (IMO) makes it more likely that we can standardize more general purpose algorithm implementations.

With the parser available, it may be possible to approximate closures without using anonymous classes. My intention is to wrap the functor parser in an annotation processor that is run at compile time: the annotation processor can arrange that the compound functor is built during compile time. How close we get to approximating closures depends on what information is available during the annotation processing phase.

Dave Hall
http://jga.sf.net/
http://jroller.com/page/dhall/

PS: I also think that the parser would be interesting in handling the jdnc markup: it can parse validation (or filtering) expressions and create fairly arbitrary validators (filters) from expressions in the markup file. I wouldn't suggest that this be the only validator mechanism available: there may be extreme cases where a hard coded validation class is still the way to go, but I do believe that a functor based mechanism can handle the bulk of the workload.

PPS: You asked for 'brief', and that ship has clearly sailed without us. Ramesh and I had a discussion of where some of these ideas may fit last summer in this thread:

http://www.javadesktop.org/forums/thread.jspa?threadID=3450&tstart=75

Message was edited by: dhall

Emoticons after punctuation cause all formatting to be lost