On 5/9/12, Göran Krampe <[email protected]> wrote: > 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? I agree but the discussion started out from the question how to do meta data exchange. Dale H. uses JSON for that at the moment.
I do recommend to everybody to actually _read_ the article http://goran.krampe.se/2012/05/08/literal-arrays-vs-json-vs-ston-vs-tirade/. In the context of meta data exchange I agree with Stephane D. that literal arrays (something like s-expressions) can do the job; however the syntax is not well defined across dialects and as Dale points out with the nails and screws comparison it might not be all that user friendly. In terms of general data exchange I value this discussion of JSON, STON and Tirade. It is very useful for my work. So we actually have two use cases 1) exchange of meta data 2) exchange of general data with literal objects. This leads to the discussion: How are object literals done in Smalltalk? --Hannes > regards, Göran > >
