February 2019 - Pharo-users

Re: [Pharo-users] Running test

by Hilaire

Ok, that sounds as a serious problem then. I am surprised the MacOS X PharoLauncher has problem too. The Linux one is working ok.Â For drgeo I think I will make three different packages for each os. Le 13/02/2019 Ã 16:28, Sean P. DeNigris a Ã©critÂ : > HilaireFernandes wrote >> You mean the same libgit plugin error? > Sorry, I meant the bundle is damaged error -- Dr. Geo http://drgeo.eu

Feb. 13, 2019

Re: [Pharo-users] [ANN] P3 version 1.2

by Francisco Ortiz PeÃ±aloza

This is great news. Thanks! On Tue, Feb 12, 2019 at 5:44 PM Tudor Girba <tudor(a)tudorgirba.com> wrote: > Thanks a lot for doing this! > > It is of great help to know that we can reliably work with Postgres. > > Cheers, > Doru > > > > On Feb 12, 2019, at 3:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Hi, > > > > There is a new release of P3, the modern, lean and mean PostgreSQL > client for Pharo. > > > > https://github.com/svenvc/P3 > > > > Version 1.2 contains the following changes: > > > > - P3PreparedStatement is now joined by a polymorphic > P3FormattedStatement working client side on text strings > > - P3PreparedStatement & P3FormattedStatement now share the same double > dispatch mechanism to process argument binding > > - Added convenience methods #listDatabases #listSchemas & > #listTablesInSchema: to P3Client > > - Added convenience methods #firstColumnData & #firstFieldOfFirstRecord > to P3Result > > - Added dynamic ENUM support via #loadEnums in P3Client > > - Add support for the 7 geometric types POINT, CIRCLE, LINE, LSEG, > POLYGON & PATH with corresponding objects P3Point, P3Circle, P3Line, > P3LineSegment, P3Polygon & P3Path > > - Add support for the INTERVAL type with P3Interval object > > - Added P3Client>>#serverVersion accessor > > - Add support for BIT & VARBIT types with P3FixedBitString & P3BitString > objects > > - Add TIMETZ support > > - Organised P3 package with tags > > - More & better documentation & unit tests > > > > https://github.com/svenvc/P3/releases/tag/v1.2 > > > > The quality of open source software is determined by it being alive, > supported and maintained. > > > > The first way to help is to simply use P3 in your projects and report > back about your successes and the issues that you encounter. You can ask > questions on the Pharo mailing lists. > > > > Enjoy, > > > > Sven > > > > -- > > Sven Van Caekenberghe > > Proudly supporting Pharo > > http://pharo.org > > http://association.pharo.org > > http://consortium.pharo.org > > > > > > > > > > > > -- > www.feenk.com > > "What is more important: To be happy, or to make happy?" > > >

Feb. 13, 2019

Re: [Pharo-users] Multiple NeoJSON mappings for the same domain object

by Francisco Ortiz PeÃ±aloza

Hi, sadly there is no documentation about Stargate yet, we did the first release just 20 days ago. Regarding HATEOAS, is an optional feature and we're testing it usefulness right now. Stargate is built on top of Zinc and Teapot and it has the following features: - Content negotiation allows serving different representations of a resource. E.g. "application/json;version=1.0.0" and "application/json;version=1.0.1" serve different representations of a resource. We think this will allow us to grow in easily our APIs. - Optional resource pagination support. - Optional HATEOAS support. - ETag generation. PS: We already took note of https://github.com/zweidenker/JSONSchema and https://github.com/zweidenker/OpenAPI. Both projects look great. On Wed, Feb 13, 2019 at 12:58 PM Norbert Hartl <norbert(a)hartl.name> wrote: > > > > Am 13.02.2019 um 13:53 schrieb Esteban Maringolo <emaringolo(a)gmail.com>: > > > > Not in a hurry at all, I'm defining this part, so I can explore > > different alternatives. > > > > I'll explore the OpenAPI approach with JSONSchema as well. > > > > > > Regards, > > > > ps: What I liked about Stargate is that it manages other aspects of an > > API such as CORS, HATEOAS [1] and resource versioning, but > > JSON-HyperSchema [2] seems to provide a similar approach to HATEOAS, I > > don't know if there something in OpenAPI to have multiple > > representation versions of the same resource (so you preserve the > > route, but make the API back AND forward compatible). > > > Is there any documentation about stargate? Caring about CORS is surely > useful. But I never got why HATEOAS is useful. It adds a lot of complexity > with little use. > > Norbert > > [1] https://en.wikipedia.org/wiki/HATEOAS > > [2] > https://www.ietf.org/archive/id/draft-handrews-json-schema-hyperschema-01.t… > > > > Esteban A. Maringolo > > > >> El miÃ©., 13 feb. 2019 a las 4:45, Norbert Hartl (<norbert(a)hartl.name>) > escribiÃ³: > >> > >> If you are not in a hurry you can use JSON schema. That is also an > external mapper which can validate. And the spec is serializable. You might > miss some functionality but I could try to add that if you donât do. I > would be happy to have more users of the library. > >> > >> If you use it for REST you could also use OpenAPI which I did. It uses > the JSON schema stuff for doing it. > >> > >> Norbert > >> > >>> Am 13.02.2019 um 02:58 schrieb Esteban Maringolo <emaringolo(a)gmail.com > >: > >>> > >>> Meanwhile I found another approach to solve this in the context of a > >>> JSON/REST API. > >>> > >>> E.g. see #addRuleToEncode:to:using: in. > >>> > https://github.com/ba-st/Stargate/blob/release-candidate/source/Stargate-Ex… > >>> > >>> Has a separate mapper for encoding and decoding, depending on the > endpoint: > >>> > >>> Regards, > >>> > >>> Esteban A. Maringolo > >>> > >>> El mar., 12 feb. 2019 a las 19:34, Esteban Maringolo > >>> (<emaringolo(a)gmail.com>) escribiÃ³: > >>>> > >>>> Hi all, Sven, :) > >>>> > >>>> I'm working on a domain model that will have different JSON > >>>> representations for the same domain objects, so depending on the > >>>> context it will return one representation or another. > >>>> > >>>> In the past to solve the multiple representations, what I did was to > >>>> build "helper" methods that added the mappings to the mapper. > >>>> > >>>> So the process was like: > >>>> 1. instantiate the mapper > >>>> 2. call a #neoJsonSimple: mapper > >>>> 3. configure the mapper by calling other mapping defining methods > >>>> 4. convert the object to a JSON string. > >>>> > >>>> If I wanted an "extended" representation, in the step 2 I would call > >>>> #neoJsonExtended: instead. > >>>> > >>>> But I find this "too manual" to scale. > >>>> > >>>> So... is there a better, Â¿canonical?, way to achieve this? > >>>> > >>>> > >>>> Thanks! > >>>> > >>>> > >>>> ps: By now it will be only object -> JSON (so NeoJSONWriter), but in > >>>> the future I might need to instantiate objects back from JSON, so the > >>>> mappings should be for both mappers. > >>>> > >>>> Esteban A. Maringolo > >>> > >> > >> > > > > >

Feb. 13, 2019

Re: [Pharo-users] Multiple NeoJSON mappings for the same domain object

by Norbert Hartl

> Am 13.02.2019 um 13:53 schrieb Esteban Maringolo <emaringolo(a)gmail.com>: > > Not in a hurry at all, I'm defining this part, so I can explore > different alternatives. > > I'll explore the OpenAPI approach with JSONSchema as well. > > > Regards, > > ps: What I liked about Stargate is that it manages other aspects of an > API such as CORS, HATEOAS [1] and resource versioning, but > JSON-HyperSchema [2] seems to provide a similar approach to HATEOAS, I > don't know if there something in OpenAPI to have multiple > representation versions of the same resource (so you preserve the > route, but make the API back AND forward compatible). > Is there any documentation about stargate? Caring about CORS is surely useful. But I never got why HATEOAS is useful. It adds a lot of complexity with little use. Norbert > [1] https://en.wikipedia.org/wiki/HATEOAS > [2] https://www.ietf.org/archive/id/draft-handrews-json-schema-hyperschema-01.t… > > Esteban A. Maringolo > >> El miÃ©., 13 feb. 2019 a las 4:45, Norbert Hartl (<norbert(a)hartl.name>) escribiÃ³: >> >> If you are not in a hurry you can use JSON schema. That is also an external mapper which can validate. And the spec is serializable. You might miss some functionality but I could try to add that if you donât do. I would be happy to have more users of the library. >> >> If you use it for REST you could also use OpenAPI which I did. It uses the JSON schema stuff for doing it. >> >> Norbert >> >>> Am 13.02.2019 um 02:58 schrieb Esteban Maringolo <emaringolo(a)gmail.com>: >>> >>> Meanwhile I found another approach to solve this in the context of a >>> JSON/REST API. >>> >>> E.g. see #addRuleToEncode:to:using: in. >>> https://github.com/ba-st/Stargate/blob/release-candidate/source/Stargate-Ex… >>> >>> Has a separate mapper for encoding and decoding, depending on the endpoint: >>> >>> Regards, >>> >>> Esteban A. Maringolo >>> >>> El mar., 12 feb. 2019 a las 19:34, Esteban Maringolo >>> (<emaringolo(a)gmail.com>) escribiÃ³: >>>> >>>> Hi all, Sven, :) >>>> >>>> I'm working on a domain model that will have different JSON >>>> representations for the same domain objects, so depending on the >>>> context it will return one representation or another. >>>> >>>> In the past to solve the multiple representations, what I did was to >>>> build "helper" methods that added the mappings to the mapper. >>>> >>>> So the process was like: >>>> 1. instantiate the mapper >>>> 2. call a #neoJsonSimple: mapper >>>> 3. configure the mapper by calling other mapping defining methods >>>> 4. convert the object to a JSON string. >>>> >>>> If I wanted an "extended" representation, in the step 2 I would call >>>> #neoJsonExtended: instead. >>>> >>>> But I find this "too manual" to scale. >>>> >>>> So... is there a better, Â¿canonical?, way to achieve this? >>>> >>>> >>>> Thanks! >>>> >>>> >>>> ps: By now it will be only object -> JSON (so NeoJSONWriter), but in >>>> the future I might need to instantiate objects back from JSON, so the >>>> mappings should be for both mappers. >>>> >>>> Esteban A. Maringolo >>> >> >> >

Feb. 13, 2019

Re: [Pharo-users] Running test

by Sean P. DeNigris

HilaireFernandes wrote > You mean the same libgit plugin error? Sorry, I meant the bundle is damaged error ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 13, 2019

Re: [Pharo-users] Traits for class methods?

by Konrad Hinsen

Marcus Denker <marcus.denker(a)inria.fr> writes: > It is amazing how much better this feels now that Traits can define state, tooâ¦ (compared to before where it was just methods). > > https://github.com/khinsen/SingletonTrait/blob/master/SingletonTrait/Single… > > I would even want to have (and use) a Trait like that in the system by default. That's what I thought as well when I saw the 43 implementors of uniqueInstance in Pharo. I'll package this as a pull request for Pharo! Konrad.

Feb. 13, 2019

Re: [Pharo-users] Traits for class methods?

by Herby VojÄÃk

On 13. 2. 2019 14:54, Cyril Ferlicot wrote: > On Wed, Feb 13, 2019 at 2:40 PM Hilaire <hilaire(a)drgeo.eu> wrote: >> >> I am wondering. Does it not make responsabilities less clear, shareed in >> class hierarchy and traits hierarchy, now both in term of behavior but >> also state? >> > > Hi, > > In general I do not choose between inheritance and composition based > on what the language allows. When we had stateless traits, I created > subclasses even if I was not using any state, because it made sense. > > I'm not a big fan of limiting the language on composition because the > choice between composition and inheritance should be conceptual and > not technical. Sorry for the unconstructive and spammy "I like it" post, but: +1! > I read in an article this way to choose between inheritance and composition: > > Â«Inheritance should only be used when: > - Both classes are in the same logical domain > - The subclass is a proper subtype of the superclass > - The superclassâs implementation is necessary or appropriate for the subclass > - The enhancements made by the subclass are primarily additive.Â» > >> Hilaire >> >> -- >> Dr. Geo >> http://drgeo.eu

Feb. 13, 2019

Re: [Pharo-users] Traits for class methods?

by Cyril Ferlicot

On Wed, Feb 13, 2019 at 2:40 PM Hilaire <hilaire(a)drgeo.eu> wrote: > > I am wondering. Does it not make responsabilities less clear, shareed in > class hierarchy and traits hierarchy, now both in term of behavior but > also state? > Hi, In general I do not choose between inheritance and composition based on what the language allows. When we had stateless traits, I created subclasses even if I was not using any state, because it made sense. I'm not a big fan of limiting the language on composition because the choice between composition and inheritance should be conceptual and not technical. I read in an article this way to choose between inheritance and composition: Â«Inheritance should only be used when: - Both classes are in the same logical domain - The subclass is a proper subtype of the superclass - The superclassâs implementation is necessary or appropriate for the subclass - The enhancements made by the subclass are primarily additive.Â» > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > > -- Cyril Ferlicot https://ferlicot.fr

Feb. 13, 2019

Re: [Pharo-users] Traits for class methods?

by Hilaire

I am wondering. Does it not make responsabilities less clear, shareed in class hierarchy and traits hierarchy, now both in term of behavior but also state? Hilaire Le 13/02/2019 Ã 13:02, Marcus Denker a Ã©critÂ : > It is amazing how much better this feels now that Traits can define state, tooâ¦ (compared to before where it was just methods). > > https://github.com/khinsen/SingletonTrait/blob/master/SingletonTrait/Single… > > I would even want to have (and use) a Trait like that in the system by default. > > Marcus -- Dr. Geo http://drgeo.eu

Feb. 13, 2019

Re: [Pharo-users] Multiple NeoJSON mappings for the same domain object

by Esteban Maringolo

Yes, there is a lot going on. We're still missing a "featured stack" (at least one) that integrates all the parts of a "common" application need. "Necessity is the mother of invention" :) Regards, Esteban A. Maringolo El miÃ©., 13 feb. 2019 a las 5:33, Sven Van Caekenberghe (<sven(a)stfx.eu>) escribiÃ³: > > Wow, first time I heard about https://github.com/ba-st/Stargate - seems like a great project. > > So much is happening in and around Pharo, it is really impossible to follow everything. > > > On 13 Feb 2019, at 02:58, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > > > Meanwhile I found another approach to solve this in the context of a > > JSON/REST API. > > > > E.g. see #addRuleToEncode:to:using: in. > > https://github.com/ba-st/Stargate/blob/release-candidate/source/Stargate-Ex… > > > > Has a separate mapper for encoding and decoding, depending on the endpoint: > > > > Regards, > > > > Esteban A. Maringolo > > > > El mar., 12 feb. 2019 a las 19:34, Esteban Maringolo > > (<emaringolo(a)gmail.com>) escribiÃ³: > >> > >> Hi all, Sven, :) > >> > >> I'm working on a domain model that will have different JSON > >> representations for the same domain objects, so depending on the > >> context it will return one representation or another. > >> > >> In the past to solve the multiple representations, what I did was to > >> build "helper" methods that added the mappings to the mapper. > >> > >> So the process was like: > >> 1. instantiate the mapper > >> 2. call a #neoJsonSimple: mapper > >> 3. configure the mapper by calling other mapping defining methods > >> 4. convert the object to a JSON string. > >> > >> If I wanted an "extended" representation, in the step 2 I would call > >> #neoJsonExtended: instead. > >> > >> But I find this "too manual" to scale. > >> > >> So... is there a better, Â¿canonical?, way to achieve this? > >> > >> > >> Thanks! > >> > >> > >> ps: By now it will be only object -> JSON (so NeoJSONWriter), but in > >> the future I might need to instantiate objects back from JSON, so the > >> mappings should be for both mappers. > >> > >> Esteban A. Maringolo > > > >

Feb. 13, 2019