May 2015 - Pharo-dev - lists.pharo.org

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

Is there an official JSON parser/writer?

by Esteban A. Maringolo

Hi, tl;dr: Question: Which JSON library is the "recommended" one? 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] translateBy: vs translatedBy:

by Ben Coman

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