Hi all!
First - I am not fighting nor pushing in any direction. I just find the
subject interesting.
On 05/08/2012 10:59 PM, Stéphane Ducasse wrote:
:) 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.
Of course. What I mean is that depending on how you "parse" a Smalltalk
literal you may or may not be susceptible to a security hole. If you
just blindly use the full Compiler to do the whole thing - then you have
a hole. If you do not, then you don't. Igor showed a neat way to only
use the literal array part of the parser - fine, no hole. But if you
just use full Compiler - not fine.
[SNIP]
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.
But Stephane... please *read* what I write in the article. Let me repeat:
#-> is a message in Smalltalk, not a literal syntax. We all know that.
BUT... there is nothing preventing us from adding support in the
Smalltalk parser to handle this as a *literal* syntax that creates an
Association. Tirade has support for it and a large part of the article
talks about this, but I presume you have not read it.
Now I would like to know the use case for a dictionary syntax or association.
There are TONS of use cases. The whole success behind JSON is IMHO based
on the fact that it has explicit syntax for *both* arrays and
dictionaries (called "objects" in JavaScript). Nested structures of
these two building blocks is a very potent combination. And Smalltalk
literal arrays only give us ONE of them.
May be you mean that you want to have the equivalent of { } but for
dictionary, why not.
Sigh. "Maybe"? Ok, things would be MUCH simpler if you actually read the
article you know. And no, not really, because {} is a *dynamic* array
with expressions in it and I am talking about (primarily) *literal*
dictionaries.
Having a syntax for a syntax is not really exciting.
What?
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'
}
The difference? Well, the first is an imperative Smalltalk program
(fully insecure of course since I presume you would parse and execute it
as full Smalltalk) and the second two are declarative literal syntaxes
that are safe to parse.
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.
Your reasoning is very... confusing. What do you mean "only have
messages" - we *already* have a whole bunch of literal syntax for
creating objects. What makes a Dictionary so special compared to Arrays?
And "not really Smalltalk anymore"... ehm, I give up.
Anyway, my article mainly says that Smalltalk literals go a long way BUT
without the support for Dictionaries they fall short of JSON, and that
is a bit of a shame I think. But still - the article was mainly food for
thought - I am not fighting a battle here, I am just exploring.
Finally and I still did not get a clear answer: why there is a need for
dictionary syntax to store method meta data.
Can you please stop referring to "method meta data" all the time? This
thread is about an article I wrote that you haven't read and it has
nothing to do with that use case. Ok?
regards, Göran
