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 <norb...@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 > >
