Are you going to be the end user of this? I wouldn't let users compile whatever Smalltalk expressions they want. You can't scope the globals that can be accessed by the compiler. What I would do is model a hierarchy of "Condition" objects used by "Filter" objects, which are composable, and know how to translate themselves to SQL, Mongo condition, or even Smalltalk expressions to apply the conditions to a collection of objects. The other way is to have a DSL, but that's a longer road if what you plan is simply to apply filters. We've done both in my previous job and worked perfectly. Regards! Esteban A. Maringolo 2014-07-14 12:19 GMT-03:00 Norbert Hartl <norbert@hartl.name>:
I was looking for a solution where I can have a textual grammar for a DSL in order to specify filters on objects. I didn't really search the net because I know a cute little DSL for that already. It is called smalltalk, you might have heard of it.
So what I do is putting the filter spec into the image via an http interface, materialize the filter in image and store it in a database to have them survive image restart. A filter spec could look like this
[ :value | ( self sectionLabelOf: value ) = 'device' ]
I want to know if there is any trouble to expect if I'm using plain block syntax for that task. As the blocks are injected using an http interface there is no environment/context problem. I would have some helper class as a facade to ease the filtering let's call it
FilterHelper (would have a class side method #sectionLabelOf:)
So getting the block code via HTTP I could do
block := Smalltalk compiler evaluate: request contents for: FilterHelper logged: false
And I would serialize it into a database as a string again doing
self store: block sourceNode formattedCode
Are there any possible drawbacks using it this way?
thanks,
Norbert