The Skeptical Methodologist

Software, Rants and Management

Forth and ‘fluent’ programming

I was reading a rant from a Forther about how Java didn’t invent the idea of stringing method calls together to create what looks like a mini-DSL.  I’ve seen this technique before to fake named arguments to a C++ constructor.  First you break object creation from the object itself, ala the factory object pattern.  Then add methods to your factory object as per every single argument you’d like to name.  Overload the equals operator on the receiving object and voila:

tree g =;

But seeing it spelled out in the Forth conversation makes me wonder.  Are their applications of this to testing of object oriented systems?  If we treat all objects as simply local stacks(which, basically, they are) then we can divide up state changing methods into stack pushing methods, and utilize stack computing to automated testing for these types of methods.

Obviously, the usual functional-style method that lacks side effects is still the way to go to keep testing and design easy.  But obviously this can’t always happen, at least easily.  But if you ALWAYS stick to all side-effects methods as strictly returning the object itself, then I do wonder if stack based thinking won’t help you in your design and testing strategy.

What about methods who have side effects AND return values?  Well, if we break it apart upon the lines above, perhaps it is these methods that are to be avoided?  In a way, methods that return values without side effects are similar to ‘getters’, except in a more mature sense(since they are actually doing some domain calculation).  And methods that mutate an underlying object (who’s entire existance can simply be thought of as a local stack) should strictly return the underlying object to allow chaining.  Can you think of a method that MUST do both? (Barring cross-cutting cases such as cacheing, which should ‘invisibly’ change object state anyway).

Since a stack (if I remember my computer theory correct) can be modeled using a state machine (or is it that some state machines require stacks?) I imagine that some static analysis could easily extrapolate functions that strictly mutated the underlying object into an easy to see diagram, and again, derive the above mentioned test scenarios.

I’ll think further on this.


June 16, 2008 - Posted by | Uncategorized

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: