FileTree and Cypress status

> On Tue, Apr 10, 2012 at 1:13 PM, stephane ducasse
> <[hidden email]> wrote:
>
> Ok, since you wrote "I do not even understand why we are discussing
> that." I'll make the argument in favour of JSON:
>
> - JSON is a simple, well-defined syntax (see http://json.org/)
>
> - There are many, many parser implementations already out there,
> including basically all Smalltalk dialects.
>
> - We're specifically talking about syntax for storing data in a file,
> not inside the image. Smalltalk tools like "senders" aren't going to
> be able to work with this data anyway, and in fact, we don't want to
> pollute the image with symbols that aren't actually Smalltalk code.
>
> - JSON is really, really common out in the wider world. Part of the
> appeal of putting Smalltalk code on Github is so that it's visible on
> the web, instead of locked away in our images and non-standard
> versioning systems. If we're trying to put our code out there for
> people to see, we should use a syntax that they can already
> understand. S-expressions will only be familiar to Lispers.
>
> The point I'm making here is that Dale and the other folks at STIC
> didn't just pick JSON to avoid writing a parser. You may be correct
> that writing an s-expression parser is easy and perhaps easier than
> using dialect-native JSON parsers. But even if that's true, there's a
> good argument for using JSON anyway. Now, if you want to argue that
> s-expressions are a better fit for the problem, ok, let's hear that
> argument.
>
> Colin

> Stef,
>
> I was thinking about the literal array structure last night and realized that it is not true that:
>
>  "literals array are ... perfectly capable of representing the data"
>
> The JSON format is serialized javascript and includes the following:
>
>  Objects (fieldName fieldValue pairs)
>  Arrays
>  Strings
>  Booleans
>  Numbers
>  UndefinedObject
>
> The JSON parser we are using turns the Objects into Dictionaries and uses the native Smalltalk classes for everything else.
>
> You cannot use literal arrays to represent both dictionaries AND literal arrays in the same structure. In the following example, is the #( 'classPaths' 'definedClasses') an actual literal array or a dictionary with a single ('classPaths' -> 'definedClasses') association?

>
> #(
>  #('name' 'CypressLayout' )
>  #('instvars' #( 'classPaths' 'definedClasses'))
> )
>
> In the FileTree/Cypress project we do need to differentiate between key/value pairs and literal arrays...
>
> Consequently you need to create a literal _Dictionary syntax_ for Smalltalk ... if you create a parser for such a beast ...  that runs on multiple Smalltalk dialects including VW, VAST, GemStone, Amber, etc. then you will have duplicated the functionality that we now have with the 27 method JSON parser and it will be possible to consider including your parser and rewriting all of the places where we are currently generating JSON, the next time we refresh the format which will likely be in a month or so.
>
> If you are serious about writing a "literal dictionary parser" I suggest that you use the JSON syntax as your starting point for your Smalltalk specification[1].

>
> [1] http://www.json.org/
>
> ----- Original Message -----
> | From: "stephane ducasse" <[hidden email]>
> | To: [hidden email]
> | Sent: Wednesday, April 11, 2012 10:37:05 AM
> | Subject: Re: [Metacello] FileTree and Cypress status
> |
> | Colin
> | Thanks I'm so uneducated and idiot. (The funny thing is that I gave
> | javascript lecture back in 99 or 2000 before the hype in fact.
> | We had fun building test framework that when they break show part of
> | the page. Anyway…. may be I should have went to
> | be a guru of javascript instead of crawling in our little microscopic
> | world).
> | Sorry, I do not have the time right now to argue endlessly.
> |
> | We got a lot of questions and thread before and the main point of
> | dale was that it was for security reason (which does not hold
> | because the interpretation of data is the guy that controls what you
> | do with data not the data itself)
> | then the problem was that gemstone cannot parse (because the parser
> | is in the vm) ok.
> | Now if dale wants to use Json perfect. I will do a parser anyway so
> | that there will be no real excuse.
> |
> | My point is:
> | - JSON is unfamiliar or confusing
> | - literals array are less confusing and are perfectly capable of
> | representing the data
> | - I'm worried that if this data ends up in a method literal, the
> | standard Smalltalk tools won't be able to peer inside it
> | - I will write a literalArrayParser in Smalltalk for Smalltalk :)
> | easy no?
> |
> | Now I know some smalltalkers that also do not see the points. So may
> | be we are a group of old narrow sighted people.
> |
> | Stef
> |
> | On Apr 10, 2012, at 10:57 PM, Colin Putney wrote:
> |
> | > On Tue, Apr 10, 2012 at 1:13 PM, stephane ducasse
> | > <[hidden email]> wrote:
> | >
> | > Ok, since you wrote "I do not even understand why we are discussing
> | > that." I'll make the argument in favour of JSON:
> | >
> | > - JSON is a simple, well-defined syntax (see http://json.org/)
> | >
> | > - There are many, many parser implementations already out there,
> | > including basically all Smalltalk dialects.
> | >
> | > - We're specifically talking about syntax for storing data in a
> | > file,
> | > not inside the image. Smalltalk tools like "senders" aren't going
> | > to
> | > be able to work with this data anyway, and in fact, we don't want
> | > to
> | > pollute the image with symbols that aren't actually Smalltalk code.
> | >
> | > - JSON is really, really common out in the wider world. Part of the
> | > appeal of putting Smalltalk code on Github is so that it's visible
> | > on
> | > the web, instead of locked away in our images and non-standard
> | > versioning systems. If we're trying to put our code out there for
> | > people to see, we should use a syntax that they can already
> | > understand. S-expressions will only be familiar to Lispers.
> | >
> | > The point I'm making here is that Dale and the other folks at STIC
> | > didn't just pick JSON to avoid writing a parser. You may be correct
> | > that writing an s-expression parser is easy and perhaps easier than
> | > using dialect-native JSON parsers. But even if that's true, there's
> | > a
> | > good argument for using JSON anyway. Now, if you want to argue that
> | > s-expressions are a better fit for the problem, ok, let's hear that
> | > argument.
> | >
> | > Colin
> |
> |

>
> On Apr 11, 2012, at 8:26 PM, Dale Henrichs wrote:
>
>> Stef,
>>
>> I was thinking about the literal array structure last night and realized
>> that it is not true that:
>>
>>  "literals array are ... perfectly capable of representing the data"
>>
>> The JSON format is serialized javascript and includes the following:
>>
>>  Objects (fieldName fieldValue pairs)
>>  Arrays
>>  Strings
>>  Booleans
>>  Numbers
>>  UndefinedObject
>>
>> The JSON parser we are using turns the Objects into Dictionaries and uses
>> the native Smalltalk classes for everything else.
>>
>> You cannot use literal arrays to represent both dictionaries AND literal
>> arrays in the same structure. In the following example, is the #(
>> 'classPaths' 'definedClasses') an actual literal array or a dictionary
>> with a single ('classPaths' -> 'definedClasses') association?
>
> do you model dictionary?
> I have problem to understand what you want to do in fact.
>
> http://scg.unibe.ch/wiki/projects/fame/mse
> We model complete systems in Moose with such format since years. We used
> CDIF, then XML, then ( ).
>
>
>  (<b>"Sample MSE file"</b>
>    (LIB.Library
>        (librarian
>            (LIB.Person
>                (name 'Adrian Kuhn')))
>        (books
>            (LIB.Book
>                (title 'Design Patterns')
>                (authors (ref: 1) (ref: 2) (ref: 3) (ref: 4)))
>            (LIB.Book
>                (title 'Eclipse: Principles, Patterns, and Plug-Ins')
>                (authors (ref: 1) (ref: 5)))
>            (LIB.Book
>                (title 'Smalltalk Best Practice Patterns')
>                (authors (ref: 5)))))
>    (LIB.Person (id: 1)
>        (name 'Erich Gamma'))
>    (LIB.Person (id: 2)
>        (name 'Richard Helm'))
>    (LIB.Person(id: 3)
>        (name 'Ralph Johnson'))
>    (LIB.Person(id: 4)
>        (name 'John Vlissides'))
>    (LIB.Person(id: 5)
>        (name 'Kent Beck')))
>
>>
>> #(
>>  #('name' 'CypressLayout' )
>>  #('instvars' #( 'classPaths' 'definedClasses'))
>> )
>>
>> In the FileTree/Cypress project we do need to differentiate between
>> key/value pairs and literal arrays...
>>
>> Consequently you need to create a literal _Dictionary syntax_ for
>> Smalltalk ... if you create a parser for such a beast ...  that runs on
>> multiple Smalltalk dialects including VW, VAST, GemStone, Amber, etc. then
>> you will have duplicated the functionality that we now have with the 27
>> method JSON parser and it will be possible to consider including your
>> parser and rewriting all of the places where we are currently generating
>> JSON, the next time we refresh the format which will likely be in a month
>> or so.
>>
>> If you are serious about writing a "literal dictionary parser" I suggest
>> that you use the JSON syntax as your starting point for your Smalltalk
>> specification[1].
>
>
> Use JSON.
> But I do not understand what you are doing.
>
> Stef
>
>
>>
>> [1] http://www.json.org/
>>
>> ----- Original Message -----
>> | From: "stephane ducasse" <[hidden email]>
>> | To: [hidden email]
>> | Sent: Wednesday, April 11, 2012 10:37:05 AM
>> | Subject: Re: [Metacello] FileTree and Cypress status
>> |
>> | Colin
>> | Thanks I'm so uneducated and idiot. (The funny thing is that I gave
>> | javascript lecture back in 99 or 2000 before the hype in fact.
>> | We had fun building test framework that when they break show part of
>> | the page. Anyway…. may be I should have went to
>> | be a guru of javascript instead of crawling in our little microscopic
>> | world).
>> | Sorry, I do not have the time right now to argue endlessly.
>> |
>> | We got a lot of questions and thread before and the main point of
>> | dale was that it was for security reason (which does not hold
>> | because the interpretation of data is the guy that controls what you
>> | do with data not the data itself)
>> | then the problem was that gemstone cannot parse (because the parser
>> | is in the vm) ok.
>> | Now if dale wants to use Json perfect. I will do a parser anyway so
>> | that there will be no real excuse.
>> |
>> | My point is:
>> | - JSON is unfamiliar or confusing
>> | - literals array are less confusing and are perfectly capable of
>> | representing the data
>> | - I'm worried that if this data ends up in a method literal, the
>> | standard Smalltalk tools won't be able to peer inside it
>> | - I will write a literalArrayParser in Smalltalk for Smalltalk :)
>> | easy no?
>> |
>> | Now I know some smalltalkers that also do not see the points. So may
>> | be we are a group of old narrow sighted people.
>> |
>> | Stef
>> |
>> | On Apr 10, 2012, at 10:57 PM, Colin Putney wrote:
>> |
>> | > On Tue, Apr 10, 2012 at 1:13 PM, stephane ducasse
>> | > <[hidden email]> wrote:
>> | >
>> | > Ok, since you wrote "I do not even understand why we are discussing
>> | > that." I'll make the argument in favour of JSON:
>> | >
>> | > - JSON is a simple, well-defined syntax (see http://json.org/)
>> | >
>> | > - There are many, many parser implementations already out there,
>> | > including basically all Smalltalk dialects.
>> | >
>> | > - We're specifically talking about syntax for storing data in a
>> | > file,
>> | > not inside the image. Smalltalk tools like "senders" aren't going
>> | > to
>> | > be able to work with this data anyway, and in fact, we don't want
>> | > to
>> | > pollute the image with symbols that aren't actually Smalltalk code.
>> | >
>> | > - JSON is really, really common out in the wider world. Part of the
>> | > appeal of putting Smalltalk code on Github is so that it's visible
>> | > on
>> | > the web, instead of locked away in our images and non-standard
>> | > versioning systems. If we're trying to put our code out there for
>> | > people to see, we should use a syntax that they can already
>> | > understand. S-expressions will only be familiar to Lispers.
>> | >
>> | > The point I'm making here is that Dale and the other folks at STIC
>> | > didn't just pick JSON to avoid writing a parser. You may be correct
>> | > that writing an s-expression parser is easy and perhaps easier than
>> | > using dialect-native JSON parsers. But even if that's true, there's
>> | > a
>> | > good argument for using JSON anyway. Now, if you want to argue that
>> | > s-expressions are a better fit for the problem, ok, let's hear that
>> | > argument.
>> | >
>> | > Colin
>> |
>> |
>
>

> I agree with Stef that
>
> "literals array are ... perfectly capable of representing the data"
>
> They may be viewed  as s-expressions
>
> http://en.wikipedia.org/wiki/S-expression
> In computing, s-expressions,  (for "symbolic expression") are a
> notation for nested list (tree-structured) data, invented for and
> popularized by the programming language Lisp which uses them for
> source code as well as data.
>
> Stef's example illustrates this.
> BTW what does MSE stand for?

>
> You might use a lot of parenthesis though.
> The http://scg.unibe.ch/wiki/projects/fame/mse is indeed very readable.
>
> JSON might do it with less.
>
> One format may be transformed into the other with some effort.
>
> JSON might be appealing for people coming from other languages whereas
> Smalltalkers might be just fine with literal arrays.
>
> There are limits for literal arrays in methods and this might be an issue.
>
> It might be good to work out an actual example fully in both formats
> and look at them side by side.
>
> --Hannes
>
> On 4/11/12, stephane ducasse <[hidden email]> wrote:
>>
>> On Apr 11, 2012, at 8:26 PM, Dale Henrichs wrote:
>>
>>> Stef,
>>>
>>> I was thinking about the literal array structure last night and realized
>>> that it is not true that:
>>>
>>> "literals array are ... perfectly capable of representing the data"
>>>
>>> The JSON format is serialized javascript and includes the following:
>>>
>>> Objects (fieldName fieldValue pairs)
>>> Arrays
>>> Strings
>>> Booleans
>>> Numbers
>>> UndefinedObject
>>>
>>> The JSON parser we are using turns the Objects into Dictionaries and uses
>>> the native Smalltalk classes for everything else.
>>>
>>> You cannot use literal arrays to represent both dictionaries AND literal
>>> arrays in the same structure. In the following example, is the #(
>>> 'classPaths' 'definedClasses') an actual literal array or a dictionary
>>> with a single ('classPaths' -> 'definedClasses') association?
>>
>> do you model dictionary?
>> I have problem to understand what you want to do in fact.
>>
>> http://scg.unibe.ch/wiki/projects/fame/mse
>> We model complete systems in Moose with such format since years. We used
>> CDIF, then XML, then ( ).
>>
>>
>> (<b>"Sample MSE file"</b>
>>   (LIB.Library
>>       (librarian
>>           (LIB.Person
>>               (name 'Adrian Kuhn')))
>>       (books
>>           (LIB.Book
>>               (title 'Design Patterns')
>>               (authors (ref: 1) (ref: 2) (ref: 3) (ref: 4)))
>>           (LIB.Book
>>               (title 'Eclipse: Principles, Patterns, and Plug-Ins')
>>               (authors (ref: 1) (ref: 5)))
>>           (LIB.Book
>>               (title 'Smalltalk Best Practice Patterns')
>>               (authors (ref: 5)))))
>>   (LIB.Person (id: 1)
>>       (name 'Erich Gamma'))
>>   (LIB.Person (id: 2)
>>       (name 'Richard Helm'))
>>   (LIB.Person(id: 3)
>>       (name 'Ralph Johnson'))
>>   (LIB.Person(id: 4)
>>       (name 'John Vlissides'))
>>   (LIB.Person(id: 5)
>>       (name 'Kent Beck')))
>>
>>>
>>> #(
>>> #('name' 'CypressLayout' )
>>> #('instvars' #( 'classPaths' 'definedClasses'))
>>> )
>>>
>>> In the FileTree/Cypress project we do need to differentiate between
>>> key/value pairs and literal arrays...
>>>
>>> Consequently you need to create a literal _Dictionary syntax_ for
>>> Smalltalk ... if you create a parser for such a beast ...  that runs on
>>> multiple Smalltalk dialects including VW, VAST, GemStone, Amber, etc. then
>>> you will have duplicated the functionality that we now have with the 27
>>> method JSON parser and it will be possible to consider including your
>>> parser and rewriting all of the places where we are currently generating
>>> JSON, the next time we refresh the format which will likely be in a month
>>> or so.
>>>
>>> If you are serious about writing a "literal dictionary parser" I suggest
>>> that you use the JSON syntax as your starting point for your Smalltalk
>>> specification[1].
>>
>>
>> Use JSON.
>> But I do not understand what you are doing.
>>
>> Stef
>>
>>
>>>
>>> [1] http://www.json.org/
>>>
>>> ----- Original Message -----
>>> | From: "stephane ducasse" <[hidden email]>
>>> | To: [hidden email]
>>> | Sent: Wednesday, April 11, 2012 10:37:05 AM
>>> | Subject: Re: [Metacello] FileTree and Cypress status
>>> |
>>> | Colin
>>> | Thanks I'm so uneducated and idiot. (The funny thing is that I gave
>>> | javascript lecture back in 99 or 2000 before the hype in fact.
>>> | We had fun building test framework that when they break show part of
>>> | the page. Anyway…. may be I should have went to
>>> | be a guru of javascript instead of crawling in our little microscopic
>>> | world).
>>> | Sorry, I do not have the time right now to argue endlessly.
>>> |
>>> | We got a lot of questions and thread before and the main point of
>>> | dale was that it was for security reason (which does not hold
>>> | because the interpretation of data is the guy that controls what you
>>> | do with data not the data itself)
>>> | then the problem was that gemstone cannot parse (because the parser
>>> | is in the vm) ok.
>>> | Now if dale wants to use Json perfect. I will do a parser anyway so
>>> | that there will be no real excuse.
>>> |
>>> | My point is:
>>> | - JSON is unfamiliar or confusing
>>> | - literals array are less confusing and are perfectly capable of
>>> | representing the data
>>> | - I'm worried that if this data ends up in a method literal, the
>>> | standard Smalltalk tools won't be able to peer inside it
>>> | - I will write a literalArrayParser in Smalltalk for Smalltalk :)
>>> | easy no?
>>> |
>>> | Now I know some smalltalkers that also do not see the points. So may
>>> | be we are a group of old narrow sighted people.
>>> |
>>> | Stef
>>> |
>>> | On Apr 10, 2012, at 10:57 PM, Colin Putney wrote:
>>> |
>>> | > On Tue, Apr 10, 2012 at 1:13 PM, stephane ducasse
>>> | > <[hidden email]> wrote:
>>> | >
>>> | > Ok, since you wrote "I do not even understand why we are discussing
>>> | > that." I'll make the argument in favour of JSON:
>>> | >
>>> | > - JSON is a simple, well-defined syntax (see http://json.org/)
>>> | >
>>> | > - There are many, many parser implementations already out there,
>>> | > including basically all Smalltalk dialects.
>>> | >
>>> | > - We're specifically talking about syntax for storing data in a
>>> | > file,
>>> | > not inside the image. Smalltalk tools like "senders" aren't going
>>> | > to
>>> | > be able to work with this data anyway, and in fact, we don't want
>>> | > to
>>> | > pollute the image with symbols that aren't actually Smalltalk code.
>>> | >
>>> | > - JSON is really, really common out in the wider world. Part of the
>>> | > appeal of putting Smalltalk code on Github is so that it's visible
>>> | > on
>>> | > the web, instead of locked away in our images and non-standard
>>> | > versioning systems. If we're trying to put our code out there for
>>> | > people to see, we should use a syntax that they can already
>>> | > understand. S-expressions will only be familiar to Lispers.
>>> | >
>>> | > The point I'm making here is that Dale and the other folks at STIC
>>> | > didn't just pick JSON to avoid writing a parser. You may be correct
>>> | > that writing an s-expression parser is easy and perhaps easier than
>>> | > using dialect-native JSON parsers. But even if that's true, there's
>>> | > a
>>> | > good argument for using JSON anyway. Now, if you want to argue that
>>> | > s-expressions are a better fit for the problem, ok, let's hear that
>>> | > argument.
>>> | >
>>> | > Colin
>>> |
>>> |
>>
>>

>
> (
>   ('name' 'CypressLayout' )
>   ('instvars' ( 'classPaths' 'definedClasses'))
>   ('classvars' ( 'Current' 'Default' 'Singleton' ))
>   ('???' ( 'size' 12 ))
> )
>
> What will the parser return for the value of 'instvars', 'classvars', or
> '???'. Array or Dictionarie?
>
>
> ----- Original Message -----
> | From: "H. Hirzel" <[hidden email]>
> | To: [hidden email]
> | Sent: Wednesday, April 11, 2012 1:36:29 PM
> | Subject: Re: [Metacello] FileTree and Cypress status
> |
> | I agree with Stef that
> |
> |  "literals array are ... perfectly capable of representing the data"
> |
> | They may be viewed  as s-expressions
> |
> | http://en.wikipedia.org/wiki/S-expression
> | In computing, s-expressions,  (for "symbolic expression") are a
> | notation for nested list (tree-structured) data, invented for and
> | popularized by the programming language Lisp which uses them for
> | source code as well as data.
> |
> | Stef's example illustrates this.
> | BTW what does MSE stand for?
> |
> | You might use a lot of parenthesis though.
> | The http://scg.unibe.ch/wiki/projects/fame/mse is indeed very
> | readable.
> |
> | JSON might do it with less.
> |
> | One format may be transformed into the other with some effort.
> |
> | JSON might be appealing for people coming from other languages
> | whereas
> | Smalltalkers might be just fine with literal arrays.
> |
> | There are limits for literal arrays in methods and this might be an
> | issue.
> |
> | It might be good to work out an actual example fully in both formats
> | and look at them side by side.
> |
> | --Hannes
> |
> | On 4/11/12, stephane ducasse <[hidden email]> wrote:
> | >
> | > On Apr 11, 2012, at 8:26 PM, Dale Henrichs wrote:
> | >
> | >> Stef,
> | >>
> | >> I was thinking about the literal array structure last night and
> | >> realized
> | >> that it is not true that:
> | >>
> | >>  "literals array are ... perfectly capable of representing the
> | >>  data"
> | >>
> | >> The JSON format is serialized javascript and includes the
> | >> following:
> | >>
> | >> t; | >> suggest
> | >> that you use the JSON syntax as your starting point for your
> | >> Smalltalk
> | >> specification[1].
> | >
> | >
> | > Use JSON.
> | > But I do not understand what you are doing.
> | >
> | > Stef
> | >
> | >
> | >>
> | >> [1] http://www.json.org/
> | >>
> | >> ----- Original Message -----
> | >> | From: "stephane ducasse" <[hidden email]>
> | >> | To: [hidden email]
> | >> | Sent: Wednesday, April 11, 2012 10:37:05 AM
> | >> | Subject: Re: [Metacello] FileTree and Cypress status
> | >> |
> | >> | Colin
> | >> | Thanks I'm so uneducated and idiot. (The funny thing is that I
> | >> | gave
> | >> | javascript lecture back in 99 or 2000 before the hype in fact.
> | >> | We had fun building test framework that when they break show
> | >> | part of
> | >> | the page. Anyway…. may be I should have went to
> | >> | be a guru of javascript instead of crawling in our little
> | >> | microscopic
> | >> | world).
> | >> | Sorry, I do not have the time right now to argue endlessly.
> | >> |
> | >> | We got a lot of questions and thread before and the main point
> | >> | of
> | >> | dale was that it was for security reason (which does not hold
> | >> | because the interpretation of data is the guy that controls what
> | >> | you
> | >> | do with data not the data itself)
> | >> | then the problem was that gemstone cannot parse (because the
> | >> | parser
> | >> | is in the vm) ok.
> | >> | Now if dale wants to use Json perfect. I will do a parser anyway
> | >> | so
> | >> | that there will be no real excuse.
> | >> |
> | >> | My point is:
> | >> | - JSON is unfamiliar or confusing
> | >> | - literals array are less confusing and are perfectly capable
> | >> | of
> | >> | representing the data
> | >> | - I'm worried that if this data ends up in a method literal,
> | >> | the
> | >> | standard Smalltalk tools won't be able to peer inside it
> | >> | - I will write a literalArrayParser in Smalltalk for Smalltalk
> | >> | :)
> | >> | easy no?
> | >> |
> | >> | Now I know some smalltalkers that also do not see the points. So
> | >> | may
> | >> | be we are a group of old narrow sighted people.
> | >> |
> | >> | Stef
> | >> |
> | >> | On Apr 10, 2012, at 10:57 PM, Colin Putney wrote:
> | >> |
> | >> | > On Tue, Apr 10, 2012 at 1:13 PM, stephane ducasse
> | >> | > <[hidden email]> wrote:
> | >> | >
> | >> | > Ok, since you wrote "I do not even understand why we are
> | >> | > discussing
> | >> | > that." I'll make the argument in favour of JSON:
> | >> | >
> | >> | > - JSON is a simple, well-defined syntax (see http://json.org/)
> | >> | >
> | >> | > - There are many, many parser implementations already out
> | >> | > there,
> | >> | > including basically all Smalltalk dialects.
> | >> | >
> | >> | > - We're specifically talking about syntax for storing data in
> | >> | > a
> | >> | > file,
> | >> | > not inside the image. Smalltalk tools like "senders" aren't
> | >> | > going
> | >> | > to
> | >> | > be able to work with this data anyway, and in fact, we don't
> | >> | > want
> | >> | > to
> | >> | > pollute the image with symbols that aren't actually Smalltalk
> | >> | > code.
> | >> | >
> | >> | > - JSON is really, really common out in the wider world. Part
> | >> | > of the
> | >> | > appeal of putting Smalltalk code on Github is so that it's
> | >> | > visible
> | >> | > on
> | >> | > the web, instead of locked away in our images and non-standard
> | >> | > versioning systems. If we're trying to put our code out there
> | >> | > for
> | >> | > people to see, we should use a syntax that they can already
> | >> | > understand. S-expressions will only be familiar to Lispers.
> | >> | >
> | >> | > The point I'm making here is that Dale and the other folks at
> | >> | > STIC
> | >> | > didn't just pick JSON to avoid writing a parser. You may be
> | >> | > correct
> | >> | > that writing an s-expression parser is easy and perhaps easier
> | >> | > than
> | >> | > using dialect-native JSON parsers. But even if that's true,
> | >> | > there's
> | >> | > a
> | >> | > good argument for using JSON anyway. Now, if you want to argue
> | >> | > that
> | >> | > s-expressions are a better fit for the problem, ok, let's hear
> | >> | > that
> | >> | > argument.
> | >> | >
> | >> | > Colin
> | >> |
> | >> |
> | >
> | >
> |
>

> I was thinking about the literal array structure last night and realized that it is not true that:
>
>  "literals array are ... perfectly capable of representing the data"
>
> The JSON format is serialized javascript and includes the following:
>
>  Objects (fieldName fieldValue pairs)
>  Arrays
>  Strings
>  Booleans
>  Numbers
>  UndefinedObject
>
> The JSON parser we are using turns the Objects into Dictionaries and uses the native Smalltalk classes for everything else.

> +1
>
> ----- Original Message -----
> | From: "Colin Putney" <[hidden email]>
> | To: [hidden email]
> | Sent: Wednesday, April 11, 2012 5:44:49 PM
> | Subject: Re: [Metacello] FileTree and Cypress status
> |
> | On Wed, Apr 11, 2012 at 11:26 AM, Dale Henrichs <[hidden email]>
> | wrote:
> |
> | > I was thinking about the literal array structure last night and
> | > realized that it is not true that:
> | >
> | >  "literals array are ... perfectly capable of representing the
> | >  data"
> | >
> | > The JSON format is serialized javascript and includes the
> | > following:
> | >
> | >  Objects (fieldName fieldValue pairs)
> | >  Arrays
> | >  Strings
> | >  Booleans
> | >  Numbers
> | >  UndefinedObject
> | >
> | > The JSON parser we are using turns the Objects into Dictionaries
> | > and uses the native Smalltalk classes for everything else.
> |
> | Here's the thing:
> |
> | Whether the surface syntax is s-expressions or JSON, the parser is
> | just giving you back a simple data structure. The next step is to
> | interpret the data, and turn it into an object in the domain model -
> | an MCClassDefinition maybe, or a Store Package or whatever. The code
> | that does that interpretation can take a dictionary as input, or an
> | array with keys and values alternating in sequence, or an array of
> | two-item arrays or whatever the convention happens to be. Either way,
> | the interpreter has to understand the semantics implicit in the
> | generic data structure, and it doesn't matter much what convention is
> | used.
> |
> | To me, the really weird thing about this debate is that Smalltalkers
> | are hardly ever going to see that syntax anyway. As a comparison, Avi
> | and I chose s-expressions for representing the ancestry information
> | in
> | a mcz file. But that decision had nothing to do with readability, or
> | familiarity, so similarity to Smalltalk syntax or anything like that.
> | It was just about the simplicity of parsing and interpreting  it.
> | When
> | was the last time you cracked open an mcz file and looked at that
> | data
> | in raw form? I've done it, but not in recent years. Most Monticello
> | users have never done it.
> |
> | One of the things that's interesting about this project is that it
> | eliminates one of the weird things that makes Smalltalk feel icky to
> | mainstream programmers - the code isn't stored in text files. The
> | only
> | time people will actually read this stuff is when they browse the
> | code
> | on Github. That's why I favour JSON syntax. For the rest of the
> | world,
> | JSON is the automatic, obvious choice. Smalltalk syntax is gonna be
> | weird for those people, let's not compound it by hitting them with
> | Lisp syntax at the same time.
> |
> | As far as which syntax is more convenient for us, Smalltalk
> | programmers who might use it - who cares? We'll never have to look at
> | it anyway - our tools will do that for us.
> |
> | Colin
> |

> Array?
>
> Did you read my post?
>
> I explicitly asked for the ability to represent a Dictionary of key value
> pairs.
>
> Dale
>
> ----- Original Message -----
> | From: "H. Hirzel" <[hidden email]>
> | To: [hidden email]
> | Sent: Wednesday, April 11, 2012 5:08:48 PM
> | Subject: Re: [Metacello] FileTree and Cypress status
> |
> | Array,
> |
> | what does ??? stand for?
> |
> | --Hannes
> |
> | On 4/12/12, Dale Henrichs <[hidden email]> wrote:
> | >
> | > (
> | >   ('name' 'CypressLayout' )
> | >   ('instvars' ( 'classPaths' 'definedClasses'))
> | >   ('classvars' ( 'Current' 'Default' 'Singleton' ))
> | >   ('???' ( 'size' 12 ))
> | > )
> | >
> | > What will the parser return for the value of 'instvars',
> | > 'classvars', or
> | > '???'. Array or Dictionarie?
> | >
> | >
> | > ----- Original Message -----
> | > | From: "H. Hirzel" <[hidden email]>
> | > | To: [hidden email]
> | > | Sent: Wednesday, April 11, 2012 1:36:29 PM
> | > | Subject: Re: [Metacello] FileTree and Cypress status
> | > |
> | > | I agree with Stef that
> | > |
> | > |  "literals array are ... perfectly capable of representing the
> | > |  data"
> | > |
> | > | They may be viewed  as s-expressions
> | > |
> | > | http://en.wikipedia.org/wiki/S-expression
> | > | In computing, s-expressions,  (for "symbolic expression") are a
> | > | notation for nested list (tree-structured) data, invented for and
> | > | popularized by the programming language Lisp which uses them for
> | > | source code as well as data.
> | > |
> | > | Stef's example illustrates this.
> | > | BTW what does MSE stand for?
> | > |
> | > | You might use a lot of parenthesis though.
> | > | The http://scg.unibe.ch/wiki/projects/fame/mse is indeed very
> | > | readable.
> | > |
> | > | JSON might do it with less.
> | > |
> | > | One format may be transformed into the other with some effort.
> | > |
> | > | JSON might be appealing for people coming from other languages
> | > | whereas
> | > | Smalltalkers might be just fine with literal arrays.
> | > |
> | > | There are limits for literal arrays in methods and this might be
> | > | an
> | > | issue.
> | > |
> | > | It might be good to work out an actual example fully in both
> | > | formats
> | > | and look at them side by side.
> | > |
> | > | --Hannes
> | > |
> | > | On 4/11/12, stephane ducasse <[hidden email]> wrote:
> | > | >
> | > | > On Apr 11, 2012, at 8:26 PM, Dale Henrichs wrote:
> | > | >
> | > | >> Stef,
> | > | >>
> | > | >> I was thinking about the literal array structure last night
> | > | >> and
> | > | >> realized
> | > | >> that it is not true that:
> | > | >>
> | > | >>  "literals array are ... perfectly capable of representing the
> | > | >>  data"
> | > | >>
> | > | >> The JSON format is serialized javascript and includes the
> | > | >> following:
> | > | >>
> | > | >>  Objects (fieldName fieldValue pairs)
> | > | >>  Arrays
> | > | >>  Strings
> | > | >>  Booleans
> | > | >>  Numbers
> | > | >>  UndefinedObject
> | > | >>
> | > | >> The JSON parser we are using turns the Objects into
> | > | >> Dictionaries
> | > | >> and uses
> | > | >> the native Smalltalk classes for everything else.
> | > | >>
> | > | >> You cannot use literal arrays to represent both dictionaries
> | > | >> AND
> | > | >> literal
> | > | >> arrays in the same structure. In the following example, is the
> | > | >> #(
> | > | >> 'classPaths' 'definedClasses') an actual literal array or a
> | > | >> dictionary
> | > | >> with a single ('classPaths' -> 'definedClasses') association?
> | > | >
> | > | > do you model dictionary?
> | > | > I have problem to understand what you want to do in fact.
> | > | >
> | > | > http://scg.unibe.ch/wiki/projects/fame/mse
> | > | > We model complete systems in Moose with such format since
> | > | > years. We
> | > | > used
> | > | > CDIF, then XML, then ( ).
> | > | >
> | > | >
> | > | >  (<b>"Sample MSE file"</b>
> | > | >    (LIB.Library
> | > | >        (librarian
> | > | >            (LIB.Person
> | > | >                (name 'Adrian Kuhn')))
> | > | >        (books
> | > | >            (LIB.Book
> | > | >                (title 'Design Patterns')
> | > | >                (authors (ref: 1) (ref: 2) (ref: 3) (ref: 4)))
> | > | >            (LIB.Book
> | > | >                (title 'Eclipse: Principles, Patterns, and
> | > | >                Plug-Ins')
> | > | >                (authors (ref: 1) (ref: 5)))
> | > | >            (LIB.Book
> | > | >                (title 'Smalltalk Best Practice Patterns')
> | > | >                (authors (ref: 5)))))
> | > | >    (LIB.Person (id: 1)
> | > | >        (name 'Erich Gamma'))
> | > | >    (LIB.Person (id: 2)
> | > | >        (name 'Richard Helm'))
> | > | >    (LIB.Person(id: 3)
> | > | >        (name 'Ralph Johnson'))
> | > | >    (LIB.Person(id: 4)
> | > | >        (name 'John Vlissides'))
> | > | >    (LIB.Person(id: 5)
> | > | >        (name 'Kent Beck')))
> | > | >
> | > | >>
> | > | >> #(
> | > | >>  #('name' 'CypressLayout' )
> | > | >>  #('instvars' #( 'classPaths' 'definedClasses'))
> | > | >> )
> | > | >>
> | > | >> In the FileTree/Cypress project we do need to differentiate
> | > | >> between
> | > | >> key/value pairs and literal arrays...
> | > | >>
> | > | >> Consequently you need to create a literal _Dictionary syntax_
> | > | >> for
> | > | >> Smalltalk ... if you create a parser for such a beast ...
> | > | >>  that
> | > | >> runs on
> | > | >> multiple Smalltalk dialects including VW, VAST, GemStone,
> | > | >> Amber,
> | > | >> etc. then
> | > | >> you will have duplicated the functionality that we now have
> | > | >> with
> | > | >> the 27
> | > | >> method JSON parser and it will be possible to consider
> | > | >> including
> | > | >> your
> | > | >> parser and rewriting all of the places where we are currently
> | > | >> generating
> | > | >> JSON, the next time we refresh the format which will likely be
> | > | >> in
> | > | >> a month
> | > | >> or so.
> | > | >>
> | > | >> If you are serious about writing a "literal dictionary parser"
> | > | >> I
> | > | >> suggest
> | > | >> that you use the JSON syntax as your starting point for your
> | > | >> Smalltalk
> | > | >> specification[1].
> | > | >
> | > | >
> | > | > Use JSON.
> | > | > But I do not understand what you are doing.
> | > | >
> | > | > Stef
> | > | >
> | > | >
> | > | >>
> | > | >> [1] http://www.json.org/
> | > | >>
> | > | >> ----- Original Message -----
> | > | >> | From: "stephane ducasse" <[hidden email]>
> | > | >> | To: [hidden email]
> | > | >> | Sent: Wednesday, April 11, 2012 10:37:05 AM
> | > | >> | Subject: Re: [Metacello] FileTree and Cypress status
> | > | >> |
> | > | >> | Colin
> | > | >> | Thanks I'm so uneducated and idiot. (The funny thing is that
> | > | >> | I
> | > | >> | gave
> | > | >> | javascript lecture back in 99 or 2000 before the hype in
> | > | >> | fact.
> | > | >> | We had fun building test framework that when they break show
> | > | >> | part of
> | > | >> | the page. Anyway…. may be I should have went to
> | > | >> | be a guru of javascript instead of crawling in our little
> | > | >> | microscopic
> | > | >> | world).
> | > | >> | Sorry, I do not have the time right now to argue endlessly.
> | > | >> |
> | > | >> | We got a lot of questions and thread before and the main
> | > | >> | point
> | > | >> | of
> | > | >> | dale was that it was for security reason (which does not
> | > | >> | hold
> | > | >> | because the interpretation of data is the guy that controls
> | > | >> | what
> | > | >> | you
> | > | >> | do with data not the data itself)
> | > | >> | then the problem was that gemstone cannot parse (because the
> | > | >> | parser
> | > | >> | is in the vm) ok.
> | > | >> | Now if dale wants to use Json perfect. I will do a parser
> | > | >> | anyway
> | > | >> | so
> | > | >> | that there will be no real excuse.
> | > | >> |
> | > | >> | My point is:
> | > | >> | - JSON is unfamiliar or confusing
> | > | >> | - literals array are less confusing and are perfectly
> | > | >> | capable
> | > | >> | of
> | > | >> | representing the data
> | > | >> | - I'm worried that if this data ends up in a method
> | > | >> | literal,
> | > | >> | the
> | > | >> | standard Smalltalk tools won't be able to peer inside it
> | > | >> | - I will write a literalArrayParser in Smalltalk for
> | > | >> | Smalltalk
> | > | >> | :)
> | > | >> | easy no?
> | > | >> |
> | > | >> | Now I know some smalltalkers that also do not see the
> | > | >> | points. So
> | > | >> | may
> | > | >> | be we are a group of old narrow sighted people.
> | > | >> |
> | > | >> | Stef
> | > | >> |
> | > | >> | On Apr 10, 2012, at 10:57 PM, Colin Putney wrote:
> | > | >> |
> | > | >> | > On Tue, Apr 10, 2012 at 1:13 PM, stephane ducasse
> | > | >> | > <[hidden email]> wrote:
> | > | >> | >
> | > | >> | > Ok, since you wrote "I do not even understand why we are
> | > | >> | > discussing
> | > | >> | > that." I'll make the argument in favour of JSON:
> | > | >> | >
> | > | >> | > - JSON is a simple, well-defined syntax (see
> | > | >> | > http://json.org/)
> | > | >> | >
> | > | >> | > - There are many, many parser implementations already out
> | > | >> | > there,
> | > | >> | > including basically all Smalltalk dialects.
> | > | >> | >
> | > | >> | > - We're specifically talking about syntax for storing data
> | > | >> | > in
> | > | >> | > a
> | > | >> | > file,
> | > | >> | > not inside the image. Smalltalk tools like "senders"
> | > | >> | > aren't
> | > | >> | > going
> | > | >> | > to
> | > | >> | > be able to work with this data anyway, and in fact, we
> | > | >> | > don't
> | > | >> | > want
> | > | >> | > to
> | > | >> | > pollute the image with symbols that aren't actually
> | > | >> | > Smalltalk
> | > | >> | > code.
> | > | >> | >
> | > | >> | > - JSON is really, really common out in the wider world.
> | > | >> | > Part
> | > | >> | > of the
> | > | >> | > appeal of putting Smalltalk code on Github is so that it's
> | > | >> | > visible
> | > | >> | > on
> | > | >> | > the web, instead of locked away in our images and
> | > | >> | > non-standard
> | > | >> | > versioning systems. If we're trying to put our code out
> | > | >> | > there
> | > | >> | > for
> | > | >> | > people to see, we should use a syntax that they can
> | > | >> | > already
> | > | >> | > understand. S-expressions will only be familiar to
> | > | >> | > Lispers.
> | > | >> | >
> | > | >> | > The point I'm making here is that Dale and the other folks
> | > | >> | > at
> | > | >> | > STIC
> | > | >> | > didn't just pick JSON to avoid writing a parser. You may
> | > | >> | > be
> | > | >> | > correct
> | > | >> | > that writing an s-expression parser is easy and perhaps
> | > | >> | > easier
> | > | >> | > than
> | > | >> | > using dialect-native JSON parsers. But even if that's
> | > | >> | > true,
> | > | >> | > there's
> | > | >> | > a
> | > | >> | > good argument for using JSON anyway. Now, if you want to
> | > | >> | > argue
> | > | >> | > that
> | > | >> | > s-expressions are a better fit for the problem, ok, let's
> | > | >> | > hear
> | > | >> | > that
> | > | >> | > argument.
> | > | >> | >
> | > | >> | > Colin
> | > | >> |
> | > | >> |
> | > | >
> | > | >
> | > |
> | >
> |
>

> On Apr 12, 2012, at 2:52 AM, Dale Henrichs wrote:
>
>> +1
>>
>> ----- Original Message -----
>> | From: "Colin Putney" <[hidden email]>
>> | To: [hidden email]
>> | Sent: Wednesday, April 11, 2012 5:44:49 PM
>> | Subject: Re: [Metacello] FileTree and Cypress status
>> |
>> | On Wed, Apr 11, 2012 at 11:26 AM, Dale Henrichs <[hidden email]>
>> | wrote:
>> |
>> | > I was thinking about the literal array structure last night and
>> | > realized that it is not true that:
>> | >
>> | >  "literals array are ... perfectly capable of representing the
>> | >  data"
>> | >
>> | > The JSON format is serialized javascript and includes the
>> | > following:
>> | >
>> | >  Objects (fieldName fieldValue pairs)
>> | >  Arrays
>> | >  Strings
>> | >  Booleans
>> | >  Numbers
>> | >  UndefinedObject
>> | >
>> | > The JSON parser we are using turns the Objects into Dictionaries
>> | > and uses the native Smalltalk classes for everything else.
>> |
>> | Here's the thing:
>> |
>> | Whether the surface syntax is s-expressions or JSON, the parser is
>> | just giving you back a simple data structure. The next step is to
>> | interpret the data, and turn it into an object in the domain model -
>> | an MCClassDefinition maybe, or a Store Package or whatever. The code
>> | that does that interpretation can take a dictionary as input, or an
>> | array with keys and values alternating in sequence, or an array of
>> | two-item arrays or whatever the convention happens to be. Either way,
>> | the interpreter has to understand the semantics implicit in the
>> | generic data structure, and it doesn't matter much what convention is
>> | used.
>> |
>> | To me, the really weird thing about this debate is that Smalltalkers
>> | are hardly ever going to see that syntax anyway. As a comparison, Avi
>> | and I chose s-expressions for representing the ancestry information
>> | in
>> | a mcz file. But that decision had nothing to do with readability, or
>> | familiarity, so similarity to Smalltalk syntax or anything like that.
>> | It was just about the simplicity of parsing and interpreting  it.
>> | When
>> | was the last time you cracked open an mcz file and looked at that
>> | data
>> | in raw form? I've done it, but not in recent years. Most Monticello
>> | users have never done it.
>> |
>> | One of the things that's interesting about this project is that it
>> | eliminates one of the weird things that makes Smalltalk feel icky to
>> | mainstream programmers - the code isn't stored in text files. The
>> | only
>> | time people will actually read this stuff is when they browse the
>> | code
>> | on Github. That's why I favour JSON syntax. For the rest of the
>> | world,
>> | JSON is the automatic, obvious choice. Smalltalk syntax is gonna be
>> | weird for those people, let's not compound it by hitting them with
>> | Lisp syntax at the same time.
>> |
>> | As far as which syntax is more convenient for us, Smalltalk
>> | programmers who might use it - who cares? We'll never have to look at
>> | it anyway - our tools will do that for us.
>> |
>> | Colin
>> |
>
>

> On 4/12/12, Esteban Lorenzano <[hidden email]> wrote:
>> Hi,
>>
>> I disagree with your argument, Colin.
>> JSON is the "de facto" choice for mainstream programmers *this year*.
> I would say you can add 2010, 2011 and probably at least the next five
> years to come.
> For this time frame JSON is fine.
>
>> A couple of years ago it was XML.
> Interesting observation.  This was the case for about 12 years. Before
> it was SGML.
> Interesting that people do not like XML anymore. XSLT though having a
> nice computational model is not easy to grasp for many. On the
> contrary (X)HTML is a success story.
>
>> And a couple of years next it will be the next hype thing in the pipeline.
>
> But until them JSON will be fine.
>
>> Are we going to follow all those fashion stuff just because mainstream
>> programmers use them?
>
> No, but here we are talking about a data format for dictionaries and arrays.
>
>
> I have a better idea: let's all do Java... mainstream
>> programmers will love that!
>
> That would be going too far.   ..... :-) Or maybe not, many of us
> actually do this.
>
> It is just a small step towards JavaScript.....   :-)
>
>
>> Avoiding sarcasm: Java or .NET programmers adopt such things because of
>> lacks of their languages. We don't have them, so we can thing on things that
>> fits better to our environment.
>
> Yes, but in terms of readability JSON is superior in the eyes of many.
>
>> best,
>> Esteban
>>
>
> Best wishes as well
> Hannes
>
>
>> On Apr 12, 2012, at 2:52 AM, Dale Henrichs wrote:
>>
>>> +1
>>>
>>> ----- Original Message -----
>>> | From: "Colin Putney" <[hidden email]>
>>> | To: [hidden email]
>>> | Sent: Wednesday, April 11, 2012 5:44:49 PM
>>> | Subject: Re: [Metacello] FileTree and Cypress status
>>> |
>>> | On Wed, Apr 11, 2012 at 11:26 AM, Dale Henrichs <[hidden email]>
>>> | wrote:
>>> |
>>> | > I was thinking about the literal array structure last night and
>>> | > realized that it is not true that:
>>> | >
>>> | >  "literals array are ... perfectly capable of representing the
>>> | >  data"
>>> | >
>>> | > The JSON format is serialized javascript and includes the
>>> | > following:
>>> | >
>>> | >  Objects (fieldName fieldValue pairs)
>>> | >  Arrays
>>> | >  Strings
>>> | >  Booleans
>>> | >  Numbers
>>> | >  UndefinedObject
>>> | >
>>> | > The JSON parser we are using turns the Objects into Dictionaries
>>> | > and uses the native Smalltalk classes for everything else.
>>> |
>>> | Here's the thing:
>>> |
>>> | Whether the surface syntax is s-expressions or JSON, the parser is
>>> | just giving you back a simple data structure. The next step is to
>>> | interpret the data, and turn it into an object in the domain model -
>>> | an MCClassDefinition maybe, or a Store Package or whatever. The code
>>> | that does that interpretation can take a dictionary as input, or an
>>> | array with keys and values alternating in sequence, or an array of
>>> | two-item arrays or whatever the convention happens to be. Either way,
>>> | the interpreter has to understand the semantics implicit in the
>>> | generic data structure, and it doesn't matter much what convention is
>>> | used.
>>> |
>>> | To me, the really weird thing about this debate is that Smalltalkers
>>> | are hardly ever going to see that syntax anyway. As a comparison, Avi
>>> | and I chose s-expressions for representing the ancestry information
>>> | in
>>> | a mcz file. But that decision had nothing to do with readability, or
>>> | familiarity, so similarity to Smalltalk syntax or anything like that.
>>> | It was just about the simplicity of parsing and interpreting  it.
>>> | When
>>> | was the last time you cracked open an mcz file and looked at that
>>> | data
>>> | in raw form? I've done it, but not in recent years. Most Monticello
>>> | users have never done it.
>>> |
>>> | One of the things that's interesting about this project is that it
>>> | eliminates one of the weird things that makes Smalltalk feel icky to
>>> | mainstream programmers - the code isn't stored in text files. The
>>> | only
>>> | time people will actually read this stuff is when they browse the
>>> | code
>>> | on Github. That's why I favour JSON syntax. For the rest of the
>>> | world,
>>> | JSON is the automatic, obvious choice. Smalltalk syntax is gonna be
>>> | weird for those people, let's not compound it by hitting them with
>>> | Lisp syntax at the same time.
>>> |
>>> | As far as which syntax is more convenient for us, Smalltalk
>>> | programmers who might use it - who cares? We'll never have to look at
>>> | it anyway - our tools will do that for us.
>>> |
>>> | Colin
>>> |
>>
>>

> Anyway, I'm not arguing anymore, as I do not have the time to prove my points with code and I don't like just jelling (and that's what I'm doing now, he)
>
> best,
> Esteban
>
> On Apr 12, 2012, at 11:13 AM, H. Hirzel wrote:
>
>> On 4/12/12, Esteban Lorenzano <[hidden email]> wrote:
>>> Hi,
>>>
>>> I disagree with your argument, Colin.
>>> JSON is the "de facto" choice for mainstream programmers *this year*.
>> I would say you can add 2010, 2011 and probably at least the next five
>> years to come.
>> For this time frame JSON is fine.
>>
>>> A couple of years ago it was XML.
>> Interesting observation.  This was the case for about 12 years. Before
>> it was SGML.
>> Interesting that people do not like XML anymore. XSLT though having a
>> nice computational model is not easy to grasp for many. On the
>> contrary (X)HTML is a success story.
>>
>>> And a couple of years next it will be the next hype thing in the pipeline.
>>
>> But until them JSON will be fine.
>>
>>> Are we going to follow all those fashion stuff just because mainstream
>>> programmers use them?
>>
>> No, but here we are talking about a data format for dictionaries and arrays.
>>
>>
>> I have a better idea: let's all do Java... mainstream
>>> programmers will love that!
>>
>> That would be going too far.   ..... :-) Or maybe not, many of us
>> actually do this.
>>
>> It is just a small step towards JavaScript.....   :-)
>>
>>
>>> Avoiding sarcasm: Java or .NET programmers adopt such things because of
>>> lacks of their languages. We don't have them, so we can thing on things that
>>> fits better to our environment.
>>
>> Yes, but in terms of readability JSON is superior in the eyes of many.
>>
>>> best,
>>> Esteban
>>>
>>
>> Best wishes as well
>> Hannes
>>
>>
>>> On Apr 12, 2012, at 2:52 AM, Dale Henrichs wrote:
>>>
>>>> +1
>>>>
>>>> ----- Original Message -----
>>>> | From: "Colin Putney" <[hidden email]>
>>>> | To: [hidden email]
>>>> | Sent: Wednesday, April 11, 2012 5:44:49 PM
>>>> | Subject: Re: [Metacello] FileTree and Cypress status
>>>> |
>>>> | On Wed, Apr 11, 2012 at 11:26 AM, Dale Henrichs <[hidden email]>
>>>> | wrote:
>>>> |
>>>> | > I was thinking about the literal array structure last night and
>>>> | > realized that it is not true that:
>>>> | >
>>>> | >  "literals array are ... perfectly capable of representing the
>>>> | >  data"
>>>> | >
>>>> | > The JSON format is serialized javascript and includes the
>>>> | > following:
>>>> | >
>>>> | >  Objects (fieldName fieldValue pairs)
>>>> | >  Arrays
>>>> | >  Strings
>>>> | >  Booleans
>>>> | >  Numbers
>>>> | >  UndefinedObject
>>>> | >
>>>> | > The JSON parser we are using turns the Objects into Dictionaries
>>>> | > and uses the native Smalltalk classes for everything else.
>>>> |
>>>> | Here's the thing:
>>>> |
>>>> | Whether the surface syntax is s-expressions or JSON, the parser is
>>>> | just giving you back a simple data structure. The next step is to
>>>> | interpret the data, and turn it into an object in the domain model -
>>>> | an MCClassDefinition maybe, or a Store Package or whatever. The code
>>>> | that does that interpretation can take a dictionary as input, or an
>>>> | array with keys and values alternating in sequence, or an array of
>>>> | two-item arrays or whatever the convention happens to be. Either way,
>>>> | the interpreter has to understand the semantics implicit in the
>>>> | generic data structure, and it doesn't matter much what convention is
>>>> | used.
>>>> |
>>>> | To me, the really weird thing about this debate is that Smalltalkers
>>>> | are hardly ever going to see that syntax anyway. As a comparison, Avi
>>>> | and I chose s-expressions for representing the ancestry information
>>>> | in
>>>> | a mcz file. But that decision had nothing to do with readability, or
>>>> | familiarity, so similarity to Smalltalk syntax or anything like that.
>>>> | It was just about the simplicity of parsing and interpreting  it.
>>>> | When
>>>> | was the last time you cracked open an mcz file and looked at that
>>>> | data
>>>> | in raw form? I've done it, but not in recent years. Most Monticello
>>>> | users have never done it.
>>>> |
>>>> | One of the things that's interesting about this project is that it
>>>> | eliminates one of the weird things that makes Smalltalk feel icky to
>>>> | mainstream programmers - the code isn't stored in text files. The
>>>> | only
>>>> | time people will actually read this stuff is when they browse the
>>>> | code
>>>> | on Github. That's why I favour JSON syntax. For the rest of the
>>>> | world,
>>>> | JSON is the automatic, obvious choice. Smalltalk syntax is gonna be
>>>> | weird for those people, let's not compound it by hitting them with
>>>> | Lisp syntax at the same time.
>>>> |
>>>> | As far as which syntax is more convenient for us, Smalltalk
>>>> | programmers who might use it - who cares? We'll never have to look at
>>>> | it anyway - our tools will do that for us.
>>>> |
>>>> | Colin
>>>> |
>>>
>>>
>

> On 4/12/12, Esteban Lorenzano <[hidden email]> wrote:
> ......> Anyway, I'm not arguing anymore, as I do not have the time to prove
> my
>> points with code and I don't like just jelling (and that's what I'm doing
>> now, he)
>>
>> best,
>> Esteban
>
> You are right, we should go for examples
>
> As a start here is the one given by Dale
>
>
> LITERAL ARRAY NOTATION
>
> #(
>  #('name' 'CypressLayout' )
>  #('instvars' #( 'classPaths' 'definedClasses'))
>  #('classvars' ( 'Current' 'Default' 'Singleton' ))
> )
>
>
>
> JSON
>
> {
>  "name" : "CypressLayout",
>  "instvars" : ["classPaths",  "definedClasses"],
>   "classvars" : ["Current" "Default" "Singleton"]
> }
>
>
>
> BTW it is nice to copy the JSON code and visualize it in
> http://json.bloople.net/