We will write a parser because we do not want a JSON syntax.
I started and I will continue. 

Hannes I think that igor did a lot for us and that he knows probably more
than you what is to work for the community. Because Igor could be working for 
Google
right now without any problem. So let us appreciate to have guys like him in 
our community.

Stef

> Igor,
> 
> Let me rephrase the context. It is that you started this thread
> yesterday Monday Apr 23, 2012 at 11:34 .You said that you are not
> pleased with storing Smalltalk meta data in JSON format.
> 
> You gave the example
> 
> {
> "category" : "Cypress-Tests",
> "classinstvars" : [
> ],
> "classtraitcomposition" : "{}",
> "classvars" : [
> ],
> "commentStamp" : "",
> "instvars" : [
> ],
> "name" : "CypressPatchTest",
> "pools" : [
> ],
> "super" : "CypressAbstractTest",
> "traitcomposition" : "{}",
> "type" : "normal" }
> 
> The cypress project URL is
> 
> https://github.com/CampSmalltalk/Cypress
> 
> This is Dale Henrichs' work.
> 
> Cypress uses JSON for storing the meta data.
> 
> There is a button called 'Fork' on the git hub project.
> 
> Dale is willing to take arguments if they are based on code.
> For many people JSON is fine.
> 
> HTH :-)
> 
> Hannes
> 
> On 4/24/12, Igor Stasenko <siguc...@gmail.com> wrote:
>> On 24 April 2012 14:17, Herby Vojčík <he...@mailbox.sk> wrote:
>>> 
>>> 
>>> Igor Stasenko wrote:
>>>> 
>>>> On 24 April 2012 11:54, Dale Henrichs<dhenr...@vmware.com>  wrote:
>>>>> 
>>>>> Stef,
>>>>> 
>>>>> There is no Parser class and there is no Compiler class. There is a
>>>>> primitive call that takes method source, class, methodDictionary, etc.
>>>>> and
>>>>> produces a method installed in the methodDictionary.
>>>>> 
>>>> so you can take 1st literal from such method and you done. or you
>>>> cannot access method's literals?
>>>> it of course not as simple as parsing the source, but if you cannot
>>>> avoid compilation..
>>>> 
>>>>> ... JSON is and was a pragmatic choice...
>>>>> 
>>>> well, i did not realized that GemStone have no own parser/compiler
>>>> written in smalltalk.
>>> 
>>> 
>>> Neither does Amber in deploy mode, unless I am mistaken.
>>> 
>>> Why do you ever think there must be a Smalltalk parser in any Smalltalk?
>>> You
>>> get used to it, I understand, but it is by no means a required thing.
>>> Smalltalk is Smalltalk without parser as well.
>>> 
>>> JSON is great choice. Much better than anything proprietary, because of
>>> world-wide interoperability.
>>> 
>> 
>> Sorry, but you seem even more out of the context than me.
>> We're talking about tools for storing and loading smalltalk code..
>> which implies having a working smalltalk
>> parser and compiler toolchain.
>> How else you can load smalltalk source code without having the way to parse
>> it?
>> If you don't parse nor compile it, it is just a bunch of letters.
>> 
>>> Herby
>>> 
>> 
>> 
>> 
>> --
>> Best regards,
>> Igor Stasenko.
>> 
>> 
> 


Reply via email to