Storing block closure code
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
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
Am 14.07.2014 um 17:44 schrieb Esteban A. Maringolo <emaringolo@gmail.com>:
Are you going to be the end user of this?
Yes, it is pure internal functionality.
I wouldn't let users compile whatever Smalltalk expressions they want. You can't scope the globals that can be accessed by the compiler.
Of course not. Sorry, I wasn't specific enough.
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.
I want a simple solution with powerful capabilities and therefor smalltalk is the perfect match IMHO. Norbert
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
Ben, It's not just Global references that you have to worry about ... `self environment` is an easy way to get direct access to `Smalltalk` ... you can use `self superclass superclass subclasses...` to navigate to just about any class in the system ...and this is only with a couple minutes of thought:) .... to be truly safe you have to work a bit harder and construct a sandbox that is a subset of the standard environment ... Dale On Mon, Jul 14, 2014 at 11:05 AM, Ben Coman <btc@openinworld.com> wrote:
Esteban A. Maringolo wrote:
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.
CompilationContext had instance variable /environment/ that contains a SystemDictionary(lots of globals). I wonder how effective it would be, or how horribly it would break things, to change that for a limited list. cheers -ben
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> <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
Ok, I think that's what you get if you forget a tiny little detail and that is enough so everything is discussed just not what you wanted to know :) My concern is not security. I know pretty well it would be a stupid to let anyone inject smalltalk code via http interface. If I were about security I would do the same as Esteban: Defining a allowed set of operations and make classes for them. My point is that it is purely internal what I like to use. And I think I would like it not to be restricted in the kind of queries I do. Hence the idea of using smalltalk. I'm only interested in the drawbacks that blocks might have. As they are created from string to only thing they might depend on context-wise would be self (if I decide to use a helper). My question was if there is anything besides that could make the use of blocks and serializing/materializing troublesome. thanks, norbert Am 14.07.2014 um 21:05 schrieb Dale Henrichs <dale.henrichs@gemtalksystems.com>:
Ben,
It's not just Global references that you have to worry about ... `self environment` is an easy way to get direct access to `Smalltalk` ... you can use `self superclass superclass subclasses...` to navigate to just about any class in the system ...and this is only with a couple minutes of thought:) .... to be truly safe you have to work a bit harder and construct a sandbox that is a subset of the standard environment ...
Dale
On Mon, Jul 14, 2014 at 11:05 AM, Ben Coman <btc@openinworld.com> wrote: Esteban A. Maringolo wrote:
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.
CompilationContext had instance variable /environment/ that contains a SystemDictionary(lots of globals). I wonder how effective it would be, or how horribly it would break things, to change that for a limited list. cheers -ben
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
Hi, I am using latest Pharo 3.0 + vm. I have a method width with width ^ 115 * self ratio. in my understanding it returns a Number. When I try to create a method negatedWidth ^ - (self width). the UI tells me that only Numbers may be negated. I am not able to save the method. Am I on a wrong path or should that work and if how can I avoid the UI error message? Regards Max
You can only put the minus sign ("-") before a literal number. Ej -12, - 4.4, -2/3, etc. But not in front of any other "non number" object (from the parser point of view): Ej: - #() size "only numbers may be negated" What you want to do can be performed sending the message #negated to the object returned by #width. So #negatedWidth would be: negatedWidth: ^self width negated Regards! Esteban A. Maringolo 2014-07-15 19:16 GMT-03:00 Verkoster Info <info@derverkoster.de>:
Hi,
I am using latest Pharo 3.0 + vm.
I have a method width with width
^ 115 * self ratio. in my understanding it returns a Number.
When I try to create a method negatedWidth
^ - (self width).
the UI tells me that only Numbers may be negated. I am not able to save the method. Am I on a wrong path or should that work and if how can I avoid the UI error message?
Regards
Max
Max, Am 16.07.2014 um 00:16 schrieb Verkoster Info <info@derVerkoster.de>:
Hi,
I am using latest Pharo 3.0 + vm.
I have a method width with width
^ 115 * self ratio. in my understanding it returns a Number.
When I try to create a method negatedWidth
^ - (self width).
the UI tells me that only Numbers may be negated. I am not able to save the method. Am I on a wrong path or should that work and if how can I avoid the UI error message?
It is all objects and you need to send a message to them in order to have a result. So a prefixed - (minus sign) won't work. But this is a very good demonstration what I have often encountered while learning smalltalk. The most obvious choice is the right one. The solution is already in the method name. You can write it negatedWidth ^ self width negated :) You see. It is easy and it makes completely sense now, no? Norbert
Hi Max, Pharo doesn't have syntax for prefix operator like "-". The parser does accepts a "-" before literal numbers but it's not possible for arbitrary expressions. However you have the message #negated . negatedWidth ^ self width negated Cheers, Camille On 16 juil. 2014, at 00:16, Verkoster Info <info@derVerkoster.de> wrote:
Hi,
I am using latest Pharo 3.0 + vm.
I have a method width with width
^ 115 * self ratio. in my understanding it returns a Number.
When I try to create a method negatedWidth
^ - (self width).
the UI tells me that only Numbers may be negated. I am not able to save the method. Am I on a wrong path or should that work and if how can I avoid the UI error message?
Regards
Max
I've been overtaken :) Isn't that an active mailing list ? On 16 juil. 2014, at 00:53, Camille Teruel <camille.teruel@gmail.com> wrote:
Hi Max,
Pharo doesn't have syntax for prefix operator like "-". The parser does accepts a "-" before literal numbers but it's not possible for arbitrary expressions. However you have the message #negated .
negatedWidth ^ self width negated
Cheers, Camille
On 16 juil. 2014, at 00:16, Verkoster Info <info@derVerkoster.de> wrote:
Hi,
I am using latest Pharo 3.0 + vm.
I have a method width with width
^ 115 * self ratio. in my understanding it returns a Number.
When I try to create a method negatedWidth
^ - (self width).
the UI tells me that only Numbers may be negated. I am not able to save the method. Am I on a wrong path or should that work and if how can I avoid the UI error message?
Regards
Max
It definitely is, thanks for all your answers⦠Regards Max Am 16.07.2014 um 00:56 schrieb Camille Teruel <camille.teruel@gmail.com>:
I've been overtaken :) Isn't that an active mailing list ?
On 16 juil. 2014, at 00:53, Camille Teruel <camille.teruel@gmail.com> wrote:
Hi Max, Pharo doesn't have syntax for prefix operator like "-". The parser does accepts a "-" before literal numbers but it's not possible for arbitrary expressions.
However you have the message #negated .
negatedWidth ^ self width negated
Cheers, Camille
On 16 juil. 2014, at 00:16, Verkoster Info <info@derVerkoster.de> wrote: Hi,
I am using latest Pharo 3.0 + vm.
I have a method width with width
^ 115 * self ratio. in my understanding it returns a Number.
When I try to create a method negatedWidth
^ - (self width).
the UI tells me that only Numbers may be negated. I am not able to save the method. Am I on a wrong path or should that work and if how can I avoid the UI error message?
Regards
Max
That's where the Inspector comes in: To debug, it is good to insert a self width inspect so that the inspector opens up and reveals what exactly the width is. OK, it is a number; then open the browser and look at the number's methods; or in the finder, try 2 . -2 in the examples... Pharo is excellent at debugging, that is why I choosed it for my Ontology project, the browser shows welle what is a number, what kind of numbers there are, and why a complex number is not a number... Alain On Wed, Jul 16, 2014 at 2:59 AM, Verkoster Info <info@derverkoster.de> wrote:
It definitely is,
thanks for all your answersâ¦
Regards
Max
Am 16.07.2014 um 00:56 schrieb Camille Teruel <camille.teruel@gmail.com>:
I've been overtaken :) Isn't that an active mailing list ?
On 16 juil. 2014, at 00:53, Camille Teruel <camille.teruel@gmail.com> wrote:
Hi Max,
Pharo doesn't have syntax for prefix operator like "-". The parser does accepts a "-" before literal numbers but it's not possible for arbitrary expressions. However you have the message #negated .
negatedWidth ^ self width negated
Cheers, Camille
On 16 juil. 2014, at 00:16, Verkoster Info <info@derVerkoster.de> wrote:
Hi,
I am using latest Pharo 3.0 + vm.
I have a method width with width
^ 115 * self ratio. in my understanding it returns a Number.
When I try to create a method negatedWidth
^ - (self width).
the UI tells me that only Numbers may be negated. I am not able to save the method. Am I on a wrong path or should that work and if how can I avoid the UI error message?
Regards
Max
The misunderstanding her is based in the error message of the ui. when you write ^ - self width. and save, the UI writes this text into the code: ^ only numbers may be negated ->- self width. More helpful would have been something like: âonly literals may be negated with - use <object> negated insteadâ. I was irritated and on the wrong track because I was absolutely sure that self width is a number. Regards Max Am 16.07.2014 um 10:44 schrieb Alain Busser <alain.busser@gmail.com>:
That's where the Inspector comes in:
To debug, it is good to insert a self width inspect so that the inspector opens up and reveals what exactly the width is. OK, it is a number; then open the browser and look at the number's methods; or in the finder, try 2 . -2 in the examples...
Pharo is excellent at debugging, that is why I choosed it for my Ontology project, the browser shows welle what is a number, what kind of numbers there are, and why a complex number is not a number...
Alain
On Wed, Jul 16, 2014 at 2:59 AM, Verkoster Info <info@derverkoster.de> wrote: It definitely is,
thanks for all your answersâ¦
Regards
Max
Am 16.07.2014 um 00:56 schrieb Camille Teruel <camille.teruel@gmail.com>:
I've been overtaken :) Isn't that an active mailing list ?
On 16 juil. 2014, at 00:53, Camille Teruel <camille.teruel@gmail.com> wrote:
Hi Max,
Pharo doesn't have syntax for prefix operator like "-". The parser does accepts a "-" before literal numbers but it's not possible for arbitrary expressions. However you have the message #negated .
negatedWidth ^ self width negated
Cheers, Camille
On 16 juil. 2014, at 00:16, Verkoster Info <info@derVerkoster.de> wrote:
Hi,
I am using latest Pharo 3.0 + vm.
I have a method width with width
^ 115 * self ratio. in my understanding it returns a Number.
When I try to create a method negatedWidth
^ - (self width).
the UI tells me that only Numbers may be negated. I am not able to save the method. Am I on a wrong path or should that work and if how can I avoid the UI error message?
Regards
Max
Am 16.07.2014 um 11:12 schrieb Max Bareis <info@derverkoster.de>:
The misunderstanding her is based in the error message of the ui. when you write ^ - self width. and save, the UI writes this text into the code: ^ only numbers may be negated ->- self width.
More helpful would have been something like: âonly literals may be negated with - use <object> negated insteadâ.
Then it needs to be "only number literalsâ¦"
I was irritated and on the wrong track because I was absolutely sure that self width is a number.
There is a difference between an object and the way you can instantiate it. The minus sign relates to the fact that smalltalk has syntax for numbers and the minus sign is part of that syntax enabling you to instantiate negated numbers. As soon as the object is created you can only send messages. Norbert
Am 16.07.2014 um 10:44 schrieb Alain Busser <alain.busser@gmail.com>:
That's where the Inspector comes in:
To debug, it is good to insert a self width inspect so that the inspector opens up and reveals what exactly the width is. OK, it is a number; then open the browser and look at the number's methods; or in the finder, try 2 . -2 in the examples...
Pharo is excellent at debugging, that is why I choosed it for my Ontology project, the browser shows welle what is a number, what kind of numbers there are, and why a complex number is not a number...
Alain
On Wed, Jul 16, 2014 at 2:59 AM, Verkoster Info <info@derverkoster.de> wrote: It definitely is,
thanks for all your answersâ¦
Regards
Max
Am 16.07.2014 um 00:56 schrieb Camille Teruel <camille.teruel@gmail.com>:
I've been overtaken :) Isn't that an active mailing list ?
On 16 juil. 2014, at 00:53, Camille Teruel <camille.teruel@gmail.com> wrote:
Hi Max,
Pharo doesn't have syntax for prefix operator like "-". The parser does accepts a "-" before literal numbers but it's not possible for arbitrary expressions. However you have the message #negated .
negatedWidth ^ self width negated
Cheers, Camille
On 16 juil. 2014, at 00:16, Verkoster Info <info@derVerkoster.de> wrote:
Hi,
I am using latest Pharo 3.0 + vm.
I have a method width with width
^ 115 * self ratio. in my understanding it returns a Number.
When I try to create a method negatedWidth
^ - (self width).
the UI tells me that only Numbers may be negated. I am not able to save the method. Am I on a wrong path or should that work and if how can I avoid the UI error message?
Regards
Max
Then the browser had helped you, as you would have found that the "-" is a method for subtraction only. But it takes more time to look inside this browser... The reward is that you find gold nuggets here and there; for example, when I saw that there were a "asRomanLitteral" for the integers, I was astonished and pleased at the same time. On Wed, Jul 16, 2014 at 1:12 PM, Max Bareis <info@derverkoster.de> wrote:
The misunderstanding her is based in the error message of the ui. when you write ^ - self width. and save, the UI writes this text into the code: ^ only numbers may be negated ->- self width.
More helpful would have been something like: âonly literals may be negated with - use <object> negated insteadâ.
I was irritated and on the wrong track because I was absolutely sure that self width is a number.
Regards
Max
Am 16.07.2014 um 10:44 schrieb Alain Busser <alain.busser@gmail.com>:
That's where the Inspector comes in:
To debug, it is good to insert a self width inspect so that the inspector opens up and reveals what exactly the width is. OK, it is a number; then open the browser and look at the number's methods; or in the finder, try 2 . -2 in the examples...
Pharo is excellent at debugging, that is why I choosed it for my Ontology project, the browser shows welle what is a number, what kind of numbers there are, and why a complex number is not a number...
Alain
On Wed, Jul 16, 2014 at 2:59 AM, Verkoster Info <info@derverkoster.de> wrote:
It definitely is,
thanks for all your answersâ¦
Regards
Max
Am 16.07.2014 um 00:56 schrieb Camille Teruel <camille.teruel@gmail.com
:
I've been overtaken :) Isn't that an active mailing list ?
On 16 juil. 2014, at 00:53, Camille Teruel <camille.teruel@gmail.com> wrote:
Hi Max,
Pharo doesn't have syntax for prefix operator like "-". The parser does accepts a "-" before literal numbers but it's not possible for arbitrary expressions. However you have the message #negated .
negatedWidth ^ self width negated
Cheers, Camille
On 16 juil. 2014, at 00:16, Verkoster Info <info@derVerkoster.de> wrote:
Hi,
I am using latest Pharo 3.0 + vm.
I have a method width with width
^ 115 * self ratio. in my understanding it returns a Number.
When I try to create a method negatedWidth
^ - (self width).
the UI tells me that only Numbers may be negated. I am not able to save the method. Am I on a wrong path or should that work and if how can I avoid the UI error message?
Regards
Max
On 16 juil. 2014, at 11:12, Max Bareis <info@derverkoster.de> wrote:
The misunderstanding her is based in the error message of the ui. when you write ^ - self width. and save, the UI writes this text into the code: ^ only numbers may be negated ->- self width.
More helpful would have been something like: âonly literals may be negated with - use <object> negated insteadâ. I was irritated and on the wrong track because I was absolutely sure that self width is a number.
You are right, the error message should be better. I opened a bug entry and submitted a slice with the new error message: "The '-' prefix works only for literal numbers (use #negated instead)". https://pharo.fogbugz.com/f/cases/13568/Better-error-message-when-using-pref...
Regards
Max
Am 16.07.2014 um 10:44 schrieb Alain Busser <alain.busser@gmail.com>:
That's where the Inspector comes in:
To debug, it is good to insert a self width inspect so that the inspector opens up and reveals what exactly the width is. OK, it is a number; then open the browser and look at the number's methods; or in the finder, try 2 . -2 in the examples...
Pharo is excellent at debugging, that is why I choosed it for my Ontology project, the browser shows welle what is a number, what kind of numbers there are, and why a complex number is not a number...
Alain
On Wed, Jul 16, 2014 at 2:59 AM, Verkoster Info <info@derverkoster.de> wrote: It definitely is,
thanks for all your answersâ¦
Regards
Max
Am 16.07.2014 um 00:56 schrieb Camille Teruel <camille.teruel@gmail.com>:
I've been overtaken :) Isn't that an active mailing list ?
On 16 juil. 2014, at 00:53, Camille Teruel <camille.teruel@gmail.com> wrote:
Hi Max,
Pharo doesn't have syntax for prefix operator like "-". The parser does accepts a "-" before literal numbers but it's not possible for arbitrary expressions. However you have the message #negated .
negatedWidth ^ self width negated
Cheers, Camille
On 16 juil. 2014, at 00:16, Verkoster Info <info@derVerkoster.de> wrote:
Hi,
I am using latest Pharo 3.0 + vm.
I have a method width with width
^ 115 * self ratio. in my understanding it returns a Number.
When I try to create a method negatedWidth
^ - (self width).
the UI tells me that only Numbers may be negated. I am not able to save the method. Am I on a wrong path or should that work and if how can I avoid the UI error message?
Regards
Max
If you are allowing arbitrary Smalltalk to be shipped in via HTTP, then I would worry about some wiseguy writing malicious code in the block ... Dale On Mon, Jul 14, 2014 at 8:19 AM, Norbert Hartl <norbert@hartl.name> wrote:
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
If *you* are the wiseguy, then Smalltalk is a pretty powerful internal DSL:) Dale On Mon, Jul 14, 2014 at 9:09 AM, Dale Henrichs < dale.henrichs@gemtalksystems.com> wrote:
If you are allowing arbitrary Smalltalk to be shipped in via HTTP, then I would worry about some wiseguy writing malicious code in the block ...
Dale
On Mon, Jul 14, 2014 at 8:19 AM, Norbert Hartl <norbert@hartl.name> wrote:
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
participants (8)
-
Alain Busser -
Ben Coman -
Camille Teruel -
Dale Henrichs -
Esteban A. Maringolo -
Max Bareis -
Norbert Hartl -
Verkoster Info