Stef, To me your argument is equivalent to saying "we've got nails why do we need screws"...Where ever you use a screw you should be able to use a nail right?
But screws have slightly different characteristics than nails and when those characteristics are called for you use a screw instead of a nail... right? STON, JSON, Tirade and literal arrays all perform the same basic function, but each have slightly different characteristics that make one better for some tasks and another better for other tasks ... right? Dale ----- Original Message ----- | From: "Stéphane Ducasse" <[email protected]> | To: [email protected] | Sent: Tuesday, May 8, 2012 12:03:18 PM | Subject: Re: [Pharo-project] A comparative article (was Re: [squeak-dev] [ANN] STON - Smalltalk Object Notation) | | | On May 8, 2012, at 8:32 PM, Dale Henrichs wrote: | | > :):):) for the correct definition of "works" I agree :):):) | | sorry but I did not get it funny at all. | But if you laugh even better. So far I do not understand but I'm | probably an idiot understand | why we need dictionary syntax. But again this should be that I'm | totally dull on that topics. | So I will not read mails about this topic anymore. | Too bad may be people could have gained from my idiot views. | | Stef | | > | > Dale | > | > ----- Original Message ----- | > | From: "Stéphane Ducasse" <[email protected]> | > | To: [email protected] | > | Sent: Tuesday, May 8, 2012 10:46:08 AM | > | Subject: Re: [Pharo-project] A comparative article (was Re: | > | [squeak-dev] [ANN] STON - Smalltalk Object Notation) | > | | > | for me I can understand that people want a format to exchange | > | objects | > | and that they want to use STON but | > | I do not understand why we need that to store metadata when a | > | simple | > | array works. Probably we love to | > | load our boat with extra readers and writers. | > | | > | Stef | > | | > | | > | On May 8, 2012, at 2:05 PM, Sven Van Caekenberghe wrote: | > | | > | > (The paper was indeed just updated a couple of days ago). | > | > | > | > On 08 May 2012, at 13:29, Göran Krampe wrote: | > | > | > | >> - In general I believe in 99% of the cases the parsing system | > | >> has | > | >> to know what it is parsing, how the JSON looks and how it | > | >> should | > | >> be mapped onto objects. Making the JSON parser itsy bitsy | > | >> smarter | > | >> with type annotations doesn't help me there, I still need to | > | >> know | > | >> that I want to instantiate a PDFPage and put this Rectangle | > | >> into | > | >> it - but oh, perhaps not as a Rectangle, but perhaps as two | > | >> points sent into a class side instantiation message or | > | >> something. | > | >> | > | >> My point being that the type annotations doesn't "buy me" | > | >> enough. | > | > | > | > (Just for the sake of the argument, I don't want to convince | > | > you) | > | > | > | > STON *does* buy you that: as long as we are talking about | > | > 'domain | > | > level objects' (a vague notion I agree) your Smalltalk object | > | > will | > | > serialize without any extra effort (see the ZnResponse example | > | > in | > | > the paper). You can customize some objects if you want to | > | > (mostly | > | > for readability, sometimes to fix some issue). | > | > | > | > Object implements #toSton: and #fromSton: by iterating over the | > | > instances variables. | > | > | > | > The issues are: Blocks, Classes and the fact that ephemeral | > | > instances are always serialized. | > | > | > | > Sven | > | > | > | > | > | | > | | > | | > | | |
