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