Le 14/12/09 19:32, Hartmut Goebel a écrit :
>> This representation is of course more verbose (and more difficult to
>> read for a human) that the current implementation but provides a
>> solution that is easier to parse for non-python software. This would
>> allow to interact easily with the Tryton server in any language
>> (currently any external program need to understand strings like:
>> "company' in context and '=' or '!=' ", "context.get('company')",
>> etc).
>>
>
>> On Dec 14, 4:15 pm, Cédric Krier<[email protected]> wrote:
>>
> I'm not quite sure what exactly you are proposing. Are you proposing to
> change the domain specific language as the user/programmer writes it or
> as it is passed to the client?
>
> If you are proposing to change the language as passed to the client, I'
> with you. We should be language independent here.
>
> I vote against changing the language as the user/programmer writes it in
> such a way as you both propose for some reason: Programmers have to
> learn yet another language, we gain no benefit here and the current
> language is easily parsed in python.
>
>
>>> [{'__class__': 'eval', 'v': "['parent', '=', False]"}]
>>> {'company': {'__class__': 'eval', 'v': "company or False"}}
>>> {'__class__': 'eval', 'v': "[16, currency_digits]"}
>>> {'__class__': 'eval', 'v': "len(lines) and True or False"}
>>>
> This is terrible unreadable! We should not expose this to the user nor
> to the programmer. It looks ugly and is redundant.
>
> bch schrieb:
>
>
>> Another solution is to use a list representation of those strings
>> (inspired by Scheme syntax), example here: http://dpaste.org/ZJey/
>>
> Maybe we could extend your idea towards some function-oriented style.
> This should allow a very simple implementation on almost every language
> suporting some kind of 'evel()'. In Python this could be implemented
> quite easily like in the example: http://dpaste.org/kIZy/
>
> IMHO this a a bit more readable than bch proposal since it tights the
> arguments towards function.
>
>
Nice improvement. I forgot to say that with my version, because there is
no need of eval anymore, there is no more risk of code injection (even
if the current eval usage has been secured).
--
Bertrand Chenal
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 474 207 906
Email: [email protected]
Website: http://www.b2ck.com/
--
[email protected] mailing list
