:):):) for the correct definition of "works" I agree :):):) 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 | > | > | | |
