- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Is there an official JSON parser/writer?

by Norbert Hartl

> Am 26.05.2015 um 22:13 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > >> On 26 May 2015, at 21:54, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> >>> Am 26.05.2015 um 21:42 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> >>>> On 26 May 2015, at 19:24, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>>> >>>> It could be dead simple as specifying the class if the different JSON >>>> libraries shared a common to/from API selectors, but they don't. >>> >>> Yes, it would be very good if there was such a thing as a common API for any reader/writer of any format (JSON, CSV, XML, STON, FUEL, ...). >>> >>> For a reader that is pretty easy, I think. Any reader object should understand >>> >>> #readFrom: <stream> (binary or character ReadStream as appropriate) >>> >>> And maybe also >>> >>> #readFromString: <string> >>> #readFromBytes: <bytearray> >>> >>> For the writer, I am not so sure. Maybe >>> >>> #nextPut: <object> toStream: <stream> (binary or character ReadStream as appropriate) >>> >>> And maybe also >>> >>> #toString: <object> >>> #toBytes: <object> >>> >>> Note that the reader and writer objects could be different. >>> >>> But like I said, I am not so sure about the API. We could try to define a Trait for this. >>> >> I'd like to have #readFrom:as: . Some of the mappers instantiate common classes that should be overwritable. Of course this does not apply for e.g. fuel. >> >> Norbert > > Hmm, that would become quickly much more complex than I intended it to be. More complex configuration should be done up front when you configure the reader or writer object, I think. > > The idea is to find a usage common API. > Agreed somehow :) Norbert

May 26, 2015

Re: [Pharo-dev] Is there an official JSON parser/writer?

by Sven Van Caekenberghe

> On 26 May 2015, at 21:54, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> Am 26.05.2015 um 21:42 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> >>> On 26 May 2015, at 19:24, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>> >>> It could be dead simple as specifying the class if the different JSON >>> libraries shared a common to/from API selectors, but they don't. >> >> Yes, it would be very good if there was such a thing as a common API for any reader/writer of any format (JSON, CSV, XML, STON, FUEL, ...). >> >> For a reader that is pretty easy, I think. Any reader object should understand >> >> #readFrom: <stream> (binary or character ReadStream as appropriate) >> >> And maybe also >> >> #readFromString: <string> >> #readFromBytes: <bytearray> >> >> For the writer, I am not so sure. Maybe >> >> #nextPut: <object> toStream: <stream> (binary or character ReadStream as appropriate) >> >> And maybe also >> >> #toString: <object> >> #toBytes: <object> >> >> Note that the reader and writer objects could be different. >> >> But like I said, I am not so sure about the API. We could try to define a Trait for this. >> > I'd like to have #readFrom:as: . Some of the mappers instantiate common classes that should be overwritable. Of course this does not apply for e.g. fuel. > > Norbert Hmm, that would become quickly much more complex than I intended it to be. More complex configuration should be done up front when you configure the reader or writer object, I think. The idea is to find a usage common API.

May 26, 2015

Re: [Pharo-dev] Is there an official JSON parser/writer?

by Norbert Hartl

> Am 26.05.2015 um 21:42 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > >> On 26 May 2015, at 19:24, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >> It could be dead simple as specifying the class if the different JSON >> libraries shared a common to/from API selectors, but they don't. > > Yes, it would be very good if there was such a thing as a common API for any reader/writer of any format (JSON, CSV, XML, STON, FUEL, ...). > > For a reader that is pretty easy, I think. Any reader object should understand > > #readFrom: <stream> (binary or character ReadStream as appropriate) > > And maybe also > > #readFromString: <string> > #readFromBytes: <bytearray> > > For the writer, I am not so sure. Maybe > > #nextPut: <object> toStream: <stream> (binary or character ReadStream as appropriate) > > And maybe also > > #toString: <object> > #toBytes: <object> > > Note that the reader and writer objects could be different. > > But like I said, I am not so sure about the API. We could try to define a Trait for this. > I'd like to have #readFrom:as: . Some of the mappers instantiate common classes that should be overwritable. Of course this does not apply for e.g. fuel. Norbert

May 26, 2015

Re: [Pharo-dev] Is there an official JSON parser/writer?

by Sven Van Caekenberghe

> On 26 May 2015, at 19:24, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > It could be dead simple as specifying the class if the different JSON > libraries shared a common to/from API selectors, but they don't. Yes, it would be very good if there was such a thing as a common API for any reader/writer of any format (JSON, CSV, XML, STON, FUEL, ...). For a reader that is pretty easy, I think. Any reader object should understand #readFrom: <stream> (binary or character ReadStream as appropriate) And maybe also #readFromString: <string> #readFromBytes: <bytearray> For the writer, I am not so sure. Maybe #nextPut: <object> toStream: <stream> (binary or character ReadStream as appropriate) And maybe also #toString: <object> #toBytes: <object> Note that the reader and writer objects could be different. But like I said, I am not so sure about the API. We could try to define a Trait for this. Sven

May 26, 2015

Re: [Pharo-dev] Is there an official JSON parser/writer?

by Esteban A. Maringolo

2015-05-26 16:15 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > On 26/05/15 18:40, Esteban A. Maringolo wrote: >> >> I'm modifying the PostgresV2 package to support JSON datatype but >> instead of using the JSON package from PharoExtras I'm trying to use >> NeoJSON. > Is there a specific reason not to move to PostgresV3? I'd love to do so. But where is it? It is not in SmalltalkHub certainly. It would also require to adapt/implement GLORP's adaptor for PostgresV3. Or is it a plug-in replacement? Please provide me with pointers, now is when :) Esteban A. Maringolo

May 26, 2015

Re: [Pharo-dev] Is there an official JSON parser/writer?

by Stephan Eggermont

On 26/05/15 18:40, Esteban A. Maringolo wrote: > I'm modifying the PostgresV2 package to support JSON datatype but > instead of using the JSON package from PharoExtras I'm trying to use > NeoJSON. Is there a specific reason not to move to PostgresV3? Stephan

May 26, 2015

Re: [Pharo-dev] Is there an official JSON parser/writer?

by Esteban A. Maringolo

2015-05-26 14:14 GMT-03:00 Guillermo Polito <guillermopolito(a)gmail.com>: > And even if STON is integrated, PostgresV2 configuration should include a > dependency against it (because in the not so remote future we will need > explicit dependency information to build images). The '2.4-baseline' of ConfigurationOfPostgresV2 currently has a dependency to a JSON package (~PharoExtras/JSON). Current implementation is pretty static. I'm trying to work out a refactoring so you can configure which parser to use when dealing with JSON datatype in PostgreSQL. The "batteries included, but swappable" approach (@Docker dixit). It could be dead simple as specifying the class if the different JSON libraries shared a common to/from API selectors, but they don't. Regards! Esteban A. Maringolo

May 26, 2015

Re: [Pharo-dev] translateBy: vs translatedBy:

by Peter UhnÃ¡k

That's not all, many methods return new rectangles via Point's API, namely Point>>{#corner: #extent: #rectangle:} I don't know if I can perform static analysis of the code (are there tools for that in Pharo?) to see which methods exactly return Rectangle rectMethods := #(#corner: #extent: #rectangle:). (Point methods select: [ :m | rectMethods includes: m selector ] thenCollect: [ :m | m senders ]) flattened select: [ :s | s className = #Rectangle ]. "an Array( Rectangle>>#areasOutside: Rectangle>>#withSideOrCorner:setToPoint:minExtent:limit: Rectangle>>#withBottom: Rectangle>>#bottom: Rectangle>>#areasOverlapingOutside: Rectangle>>#floor Rectangle>>#allAreasOutsideList:startingAt:do: Rectangle>>#scaledAndCenteredIn: Rectangle>>#squishedWithin: Rectangle>>#ceiling Rectangle>>#withHeight: Rectangle>>#rectanglesAt:height: Rectangle>>#scaleFrom:to: Rectangle>>#withLeft: Rectangle>>#left: Rectangle>>#withTop: Rectangle>>#right: Rectangle>>#top: Rectangle>>#innerCorners Rectangle>>#interpolateTo:at: Rectangle>>#withWidth: Rectangle>>#quickMergePoint: Rectangle>>#withRight: Rectangle>>#rotateBy:centerAt: Rectangle>>#withSideOrCorner:setToPoint:minExtent:limit: Rectangle>>#flipBy:centerAt:) " This list is maybe a bit excessive (sometimes it returns self, sometimes new rectangle -- e.g. floor). On Tue, May 26, 2015 at 6:14 PM, Ben Coman <btc(a)openinworld.com> wrote: > On Tue, May 26, 2015 at 9:38 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> I vote for renaming to Rectangle>>translatedBy:, because it returns a > new > >> translated rectangle instance. > > > > > > -1 > > There is no benefit in renaming a single method, apart from creating more > > confusion. > > I wouldn't say "no benefit". Consistent conventions are beneficial. > It could be useful to bring these into line with the general "-ed" > convention of returning a new object. I don't see how this would > create confusion, though it might create work. Whether its worth the > work is a slightly different question. > > > If anything, the whole Rectangle API would have to be changed, as there > is > > plethora of similar methods (expandBy:, extendBy:, merge:, etc.) > > For a better feel of the work involved... > > Rectangle methods select: [ :m | m sourceCode includesSubstring: '^ > Rectangle ' ]. > Rectangle>>#intersect: > Rectangle>>#quickMerge: > Rectangle>>#encompass: > Rectangle>>#intersect:ifNone: > > Rectangle methods select: [ :m | m sourceCode includesSubstring: > '^Rectangle ' ]. > Rectangle>>#intersect: > Rectangle>>#translateBy: > Rectangle>>#scaleBy: > Rectangle>>#merge: > Rectangle>>#compressTo: > Rectangle>>#expandTo: > Rectangle>>#roundTo: > Rectangle>>#truncateTo: > > The following already follow the convention... > Rectangle>>#compressed > Rectangle>>#expanded > Rectangle>>#rounded > Rectangle>>#truncated > > > Pretty much all Rectangle messages are immutable and create new > Rectangle, > > thus I feel it is unnecessary to state it explicitly. > > > > In VW there is plenty of methods (e.g. left:) that mutates it, thus > unlike > > Pharo a clear distinction is required. > > Still, it is reasonable to consider the impact of inconsistent > conventions on the rest of the system outside of Rectangle. > > cheers -ben > >

May 26, 2015

Re: [Pharo-dev] Is there an official JSON parser/writer?

by Guillermo Polito

And even if STON is integrated, PostgresV2 configuration should include a dependency against it (because in the not so remote future we will need explicit dependency information to build images). El mar., 26 de may. de 2015 a la(s) 6:55 p. m., Esteban Lorenzano < estebanlm(a)gmail.com> escribiÃ³: > On 26 May 2015, at 18:40, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > Hi, > > tl;dr: Question: Which JSON library is the "recommended" one? > > > STON will be integrated in Pharo 5. > https://github.com/svenvc/ston/blob/master/ston-paper.md > > and of course JSON is a subset of STON :) > > Esteban > > > > Long: > I'm modifying the PostgresV2 package to support JSON datatype but > instead of using the JSON package from PharoExtras I'm trying to use > NeoJSON. > > The problem is no JSON parser is bundled by default, so adding the > dependency to either class is arbitrary. > > > Regards! > > Esteban A. Maringolo > >

May 26, 2015

Re: [Pharo-dev] Is there an official JSON parser/writer?

by Esteban Lorenzano

> On 26 May 2015, at 18:40, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > Hi, > > tl;dr: Question: Which JSON library is the "recommended" one? STON will be integrated in Pharo 5. https://github.com/svenvc/ston/blob/master/ston-paper.md <https://github.com/svenvc/ston/blob/master/ston-paper.md> and of course JSON is a subset of STON :) Esteban > > > Long: > I'm modifying the PostgresV2 package to support JSON datatype but > instead of using the JSON package from PharoExtras I'm trying to use > NeoJSON. > > The problem is no JSON parser is bundled by default, so adding the > dependency to either class is arbitrary. > > > Regards! > > Esteban A. Maringolo >

May 26, 2015