In this sense I agree with you, Igor, and I actually had your position in the discussion on the 11th and 12 April on the metacello list (I made a small example as you, and I added XML as a third option)
As I am not going to implement neither JSON, nor XML nor a Smalltalk solution I have to say that anything is fine for me. However the discussion is about Cypress and the project is moving on. See https://github.com/CampSmalltalk/Cypress/wiki --Hannes =========================================================== For ease of Reference here the full email of Dale from April 12th, 2012 See my emphasis with +++++++++++++++++ =========================================================== Guys, Guys, Guys... this is my last post on this topic ... I have not read any of the overnight posts ... I am not interested in talking about what format the property files should use. I made the decision (weeks ago) and no amount of arguing on this list will change the current implementation and the only thing that will change a future implementation is CODE. I have stated that whatever format you want to invent it should include a "literal dictionary format", because the existing code is expecting to work with Dictionaries. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I have also stated that any code produced be portable to all of the dialects participating in the project. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ If you meet these two requirements, it is likely that the project maintainers will just fold it in ... if it takes too much work to use your format, then you'll have to do it yourself. 1) FileTree/Cypress is using JSON 2) the current implementation is functioning just fine 3) FileTree/Cypress is designed to be flexible in terms of format, at some future date, you will be free to fork the projects and introduce your own favorite format and you are free to make the changes that are necessary in the source code for all of the dialects or use your own custom package structure on just your own projects. We are all programmers. We all understand that the data can be represented in an infinite number of formats. We all understand that it is just a small matter of writing code to implement readers and writers for this infinite number of formats. We all understand that the data is much more important than the disk format .... We should all understand that there is no right answer to the format question ... every conceivable format will work (with the appropriate amount of supporting software) ... We all have an opinion and I understand that each of you has your own opinion about what the format should be and I understand that the folks who are continuing to argue over this are not happy with my decision... That's just too bad. If you are interested in being able to use git and github and are excited at the prospect of being able to not only share code across dialects, but to collaborate on cross dialect projects, then stop worrying about the format of the file and put your energy into writing code in support of this goal (see point 3 and read it 5 times in a row). If you are arguing on these points, you are showing that you have passion ... I don't fault you for having strong opinions ... I just ask you to channel your energy into writing code on this issue or focussing on some of the harder problems that do exist... I do not intend to read any responses to this mail as far as I am concerned I am moving on to some of the much more important issues that need attention ... Dale On 4/24/12, Igor Stasenko <[email protected]> wrote: > you know, it is like C and their makefiles.. > in C world they cannot express the project metadata using C syntax.. > that's why they using this weird > makefiles (and many other .project formats) to glue things together.. > But hey, we can express things in smalltalk. So, why adding extra tool > to the toolchain? > > My point is not about whether it is better to use JSON over another > format. My point is that we can use smalltalk all the way down. > Because it means less dependencies and simpler tool chain (you need to > have only smalltalk parser to handle everything stored in your files, > and no extra stuff). > Because tomorrow, other guy could say: hey i love xml and i want to > store this in xml.. and provide same arguments: > it is used worldwide, and can be used for interoperability with other > languages... and so on, so on. > And he will be totally right, except from the fact that we don't need it. > > My argument is purely pragmatic: it is better having just one parser > to parse all data than two or more. > More formats, more syntax(es) means more things to worry about, and > maintain. > > > On 24 April 2012 13:02, Igor Stasenko <[email protected]> wrote: >> On 24 April 2012 12:53, Stéphane Ducasse <[email protected]> >> wrote: >>>> Hi Igor, >>>> >>>> It is pretty clear that JSON is slowly replacing even XML elsewhere and >>>> if I for instance have to chose between XML and JSON, I'd certainly >>>> choose later. Our chunk format is, well, ours only. VW is using XML, >>>> others are using anything else. >>> >>> In a really really bad way. Because the tags are used in a non sense way. >>> You still have to parse method to get the selector :) So VW is far from >>> an example. And we are not talking about the method format, just method >>> metadata. >>> >>>> Something as neutral and as simple as >>>> JSON-based format can therefore become a bridge even between us. >>>> >>>> JSON is now becoming defacto standard for any interoperability scenario >>>> in cloud world, so IMO Dale did a right decision to choose it. We will >>>> be much closer to other words with Smalltalk that way >>> >>> Not at all. Do you really think that somebody will be interested by >>> Smalltalk just because >>> metadata of methods are stored in JSON :) >>> Come on. >> >> yeah. lets store our metadata in SQL syntax.. so we are closer to SQL >> databases.. >> LOL :) >> >>> >>>> and even more by >>>> using GitHub for code repository. >>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. > > > > -- > Best regards, > Igor Stasenko. > >
