[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: succinctness = power
> If we actually ran some kind of automatic pattern-recognizer to
> automatically extract macros/functions from our code, I think it might
> sometimes violate (a): it might find patterns that are factorable, but
> the line it draws around this commonality might not actually reflect a
> "meaningful" concept.
I suspect a tool like that might still be quite useful, even if it only
identified possible patterns.
Somewhat along those lines, you mentioned something related to the anonymous
inner class issue which reminded me of one of the micro-patterns I use to
detect possible refactoring opportunities:
> "event" and "prn" had to be declared "final", and the "return null" is
> because we don't happen to need to return anything to the caller in
> this case.
I have no problem with declaring as many variables "final" as possible.
When I find myself trying to mutate a final variable, it's often a good
micro-level indication that a separate method may be needed, or some other
restructuring, based on the functional justification that mutation should be
avoided whenever possible. That might sound strange or arbitrary to anyone
who hasn't done it (or isn't familiar with pure functional programming), but
I find it interesting how this micro-level indicator so often flags very
valid higher-level design issues.
I have the feeling that there are quite a few other ways in which functional
concepts could be applied almost automatically to imperative code. I
suppose that's exactly what some compilers do, especially e.g. in the case