>>>
>>
>> :) there is no security problem just that gemstone does not have a parser.
>> Because parsing cannot be a security hole
>> this is blind data interpretation that is a problem. This is why Github got
>> problems and I imagine that the code was probably passed in JSON or similar
>> format.
>
> Mmm, well, if you rely on full Compiler to parse literals, it is a security
> problem. But if you use the technique Igor showed to only parse array
> literals - then yes, that's safe, I agree. I forgot about his post.
Parsing and compiling + execution are three different actions.
Parsing: stream -> tokens* but you know it.
>>> - There is no support for Associations as literals which means there is no
>>> good support in literals to express Dictionaries/key-value-pairs (like JSON
>>> has). Tirade has that in the form of literal Associations. I think we
>>> should add something in this area to Pharo/Smalltalk in general, but for
>>> more thoughts on that, please see article.
>>
>> Ok let me try to understand what I do not get.
>>
>> Do you mean that we cannot distinguish between
>> #((a 13) 'a' 'b' 1 )
>>
>> and
>> #(a -> 13 'a' 'b' 1 )
>>
>> why
>> #(Dictionary (a 13) (b 15)) or #(Dictionary ((a 13) (b 15)))
>>
>> is not the same as
>> #(Dictionary a-> 13 b ->15)
>>
>> Now the problem is that a -> 13 is not created at parse time. So I do not
>> get why
>
> I presume you are describing various conventions/tricks to represent a
> Dictionary in a literal array, right?
>
> My point is that it would be nice if we actually had proper syntax for
> Associations (and or Dictionaries).
OK I see. But what I want to say is that then this is not a literal array
anymore.
Literal means that you only need a parser and no execution to get the
information. Parse time.
Now I would like to know the use case for a dictionary syntax or association.
May be you mean that you want to have the equivalent of { } but for
dictionary, why not.
Having a syntax for a syntax is not really exciting. Now I think that the key
problem is dealing with reference between
elements. for that STON can be better because why stopping at dictionary? But
then the next question if we go down this
road is why don't we add this syntax to smalltalk so that we can create
literals objects like in Javascript.
I mean without message send because this is exactly that no?
What is the difference between
Dictionary new add: #flop put: 33 ;yourself
and
{|% flop : 33 %|}
or Person {
name : 'stef'
}
then this is not really Smalltalk anymore and we cannot say that we only have
messages and the parser and ….
have to be changed…. This is why I asked what is the use case.
Finally and I still did not get a clear answer: why there is a need for
dictionary syntax to store method meta data.
Ok if you need a ***syntax*** then this is another requirement.
Stef
