February 2019 - Pharo-users

Re: [Pharo-users] Interval form: x to: y when x > y - or how to count down...

by Offray Vladimir Luna CÃ¡rdenas

On 22/2/19 16:57, Sven Van Caekenberghe wrote: > >> On 22 Feb 2019, at 22:35, Tim Mackinnon <tim(a)testit.works> wrote: >> >> If itâs always been that way - and things rely on it, sure. >> >> But it doesnât feel like the Smalltalk way to me. >> >> Having to know about adding -1 seems very C, whereas Smalltalk always seems more natural ... and 5 to: 1 seems like you would count down, not be an empty range and do nothing. >> >> But as you say, itâs personal. Iâm still curious though. > I personally would find it cool if > > 10 to: 1 > > counted down, it feels natural. But I must say I haven't thought it through. > > I do known that Interval is a class that leads to lots of discussions and disagreements. > I agree with Tim and Sven: "bigger to: smaller" should count backwards, if we think in the way we used on a day to day expectation. Cheers, Offray

Feb. 23, 2019

Re: [Pharo-users] JSON keys not quoted?

by Ben Coman

Just curiousity... Is an idempotent round trip required/expected ? cheers -ben On Sat, 23 Feb 2019 at 05:24, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Good catch. > > Indeed, JSON keys have to be strings. > > The question is, should the writer convert them for you, or should you > simply not use them ? > > I mean, there are many Pharo constructs that cannot be converted to JSON. > > Some could be output to JSON, but you won't be able to read them back in. > > So, if conversion would happen, the dictionary with integer keys will be > read back with strings keys. > > In STON, keys can be anything, even complex objects, like in Pharo itself. > > What will you do with { (1@2)->100 } asDictionary in JSON ? > > I have to think about this. > > > On 22 Feb 2019, at 21:21, Esteban Maringolo <emaringolo(a)gmail.com> > wrote: > > > > If you convert a Dictionary with numbers as keys it will produce not > > valid JSON [1], since all object keys must be quoted. > > > > E.g. > > NeoJSONWriter toString: (Dictionary with: 1->'foo'). > > or > > (Dictionary with: 1->'foo') asJson > > > > Should the library generate quoted keys? > > > > Seaside's WAJsonCanvas is manual, so it is up to the developer to > > render the object properly, but NeoJSON does it automatically. > > > > In Javascript this will throw a syntax error: > >> JSON.parse('{1: "foo"}') > > > > And this would generate a quoted key when serialized: > >> JSON.stringify({1: "foo"}) > >> {"1": "foo"} > > > > So my question is: should the library quote whatever you put as key in > > order to produce valid JSON syntax? [2] > > > > Regards. > > > > [1] https://jsonlint.com/ > > [2] > https://www.ecma-international.org/publications/standards/Ecma-404.htm > > > > Esteban A. Maringolo > > > > >

Feb. 23, 2019

Re: [Pharo-users] JSON keys not quoted?

by Sven Van Caekenberghe

> On 22 Feb 2019, at 22:52, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > El vie., 22 feb. 2019 a las 18:24, Sven Van Caekenberghe > (<sven(a)stfx.eu>) escribiÃ³: >> >> Good catch. >> >> Indeed, JSON keys have to be strings. >> >> The question is, should the writer convert them for you, or should you simply not use them ? >> >> I mean, there are many Pharo constructs that cannot be converted to JSON. >> >> Some could be output to JSON, but you won't be able to read them back in. >> So, if conversion would happen, the dictionary with integer keys will be read back with strings keys. > > This is the same as with any object, you can serialize any object to a > JSON object ({"foo": "baz"...}), but you can't read it back UNLESS you > know exactly what to convert it to. > > Maybe there should be an "integer" mapping that converts the number in > string representation back to an Integer when deserializing it. > > >> In STON, keys can be anything, even complex objects, like in Pharo itself. > > That's why STON is better. :) > > >> What will you do with { (1@2)->100 } asDictionary in JSON ? > > That is not valid JSON and not even JS. I mean, AFAIU in JS properties > are also strings, even array indices. > > Try to do this: >> JSON.stringify({{x: 1, y: 2}: 100}) > > And it will fail. > > E.g. >> point = {x: 1, y: 2}; >> object = {point: 100} >> object > < {point: 100} > > There the "point" is a literal, not a variable reference. > > But if instead you do >> point = {x: 1, y: 2}; >> object = {}. >> object[point] = 100; >> object > < {[object Object]: 100} > > you get a frankenstein because the key got converted to a string: > >> Object.keys(obj) > < ["[object Object]"] > > The issue here is that the JSON writer creates invalid JSON syntax. > So it's either JSON (valid) or it's something else. OK, that is a very good point. So you if it gave an error that would be good too ? > Not that I'm a fan of this, but I got bitten when submitting a > document to CouchDB which got rejected because of this invalid syntax. > > To make things worse: >> object = {1: 'foo'} >> object[1] > < "foo" >> object["1"] > < "foo" > > WAT! [1] > > >> I have to think about this. > > Food for thought for the weekend. > > > Regards, > > > > [1] https://www.destroyallsoftware.com/talks/wat > > Esteban A. Maringolo

Feb. 22, 2019

Re: [Pharo-users] Interval form: x to: y when x > y - or how to count down...

by Sven Van Caekenberghe

> On 22 Feb 2019, at 22:35, Tim Mackinnon <tim(a)testit.works> wrote: > > If itâs always been that way - and things rely on it, sure. > > But it doesnât feel like the Smalltalk way to me. > > Having to know about adding -1 seems very C, whereas Smalltalk always seems more natural ... and 5 to: 1 seems like you would count down, not be an empty range and do nothing. > > But as you say, itâs personal. Iâm still curious though. I personally would find it cool if 10 to: 1 counted down, it feels natural. But I must say I haven't thought it through. I do known that Interval is a class that leads to lots of discussions and disagreements. > Tim > > Sent from my iPhone > >> On 22 Feb 2019, at 16:13, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: >> >>> On 22/02/2019 15:57, Tim Mackinnon wrote: >>> I've just been caught out with Intervals - why can't you do: >>> 5 to: 1 do: [ :i | Transcript show: i printString] (eg a negative interval)? >>> >>> if you want to iterate down a series of numbers do you really have to do: >>> 5 to: 1 by: -1 do: [â¦ >>> >>> I always assumed that if x > y the step was automatically -1 (but its not). >> >> Expectations are obviously personal, but as far as I am concerned, I'd expect to see the behavior that Pharo implements. If you don't specify by:, you get a default value of 1. That's much simpler than a default value depending on the bounds of the interval. >> >> Konrad. >> >> > >

Feb. 22, 2019

Re: [Pharo-users] JSON keys not quoted?

by Esteban Maringolo

El vie., 22 feb. 2019 a las 18:24, Sven Van Caekenberghe (<sven(a)stfx.eu>) escribiÃ³: > > Good catch. > > Indeed, JSON keys have to be strings. > > The question is, should the writer convert them for you, or should you simply not use them ? > > I mean, there are many Pharo constructs that cannot be converted to JSON. > > Some could be output to JSON, but you won't be able to read them back in. > So, if conversion would happen, the dictionary with integer keys will be read back with strings keys. This is the same as with any object, you can serialize any object to a JSON object ({"foo": "baz"...}), but you can't read it back UNLESS you know exactly what to convert it to. Maybe there should be an "integer" mapping that converts the number in string representation back to an Integer when deserializing it. > In STON, keys can be anything, even complex objects, like in Pharo itself. That's why STON is better. :) > What will you do with { (1@2)->100 } asDictionary in JSON ? That is not valid JSON and not even JS. I mean, AFAIU in JS properties are also strings, even array indices. Try to do this: > JSON.stringify({{x: 1, y: 2}: 100}) And it will fail. E.g. > point = {x: 1, y: 2}; > object = {point: 100} > object < {point: 100} There the "point" is a literal, not a variable reference. But if instead you do > point = {x: 1, y: 2}; > object = {}. > object[point] = 100; > object < {[object Object]: 100} you get a frankenstein because the key got converted to a string: > Object.keys(obj) < ["[object Object]"] The issue here is that the JSON writer creates invalid JSON syntax. So it's either JSON (valid) or it's something else. Not that I'm a fan of this, but I got bitten when submitting a document to CouchDB which got rejected because of this invalid syntax. To make things worse: > object = {1: 'foo'} > object[1] < "foo" > object["1"] < "foo" WAT! [1] > I have to think about this. Food for thought for the weekend. Regards, [1] https://www.destroyallsoftware.com/talks/wat Esteban A. Maringolo

Feb. 22, 2019

Re: [Pharo-users] Interval form: x to: y when x > y - or how to count down...

by Tim Mackinnon

If itâs always been that way - and things rely on it, sure. But it doesnât feel like the Smalltalk way to me. Having to know about adding -1 seems very C, whereas Smalltalk always seems more natural ... and 5 to: 1 seems like you would count down, not be an empty range and do nothing. But as you say, itâs personal. Iâm still curious though. Tim Sent from my iPhone > On 22 Feb 2019, at 16:13, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > >> On 22/02/2019 15:57, Tim Mackinnon wrote: >> I've just been caught out with Intervals - why can't you do: >> 5 to: 1 do: [ :i | Transcript show: i printString] (eg a negative interval)? >> >> if you want to iterate down a series of numbers do you really have to do: >> 5 to: 1 by: -1 do: [â¦ >> >> I always assumed that if x > y the step was automatically -1 (but its not). > > Expectations are obviously personal, but as far as I am concerned, I'd expect to see the behavior that Pharo implements. If you don't specify by:, you get a default value of 1. That's much simpler than a default value depending on the bounds of the interval. > > Konrad. > >

Feb. 22, 2019

Re: [Pharo-users] JSON keys not quoted?

by Sven Van Caekenberghe

Good catch. Indeed, JSON keys have to be strings. The question is, should the writer convert them for you, or should you simply not use them ? I mean, there are many Pharo constructs that cannot be converted to JSON. Some could be output to JSON, but you won't be able to read them back in. So, if conversion would happen, the dictionary with integer keys will be read back with strings keys. In STON, keys can be anything, even complex objects, like in Pharo itself. What will you do with { (1@2)->100 } asDictionary in JSON ? I have to think about this. > On 22 Feb 2019, at 21:21, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > If you convert a Dictionary with numbers as keys it will produce not > valid JSON [1], since all object keys must be quoted. > > E.g. > NeoJSONWriter toString: (Dictionary with: 1->'foo'). > or > (Dictionary with: 1->'foo') asJson > > Should the library generate quoted keys? > > Seaside's WAJsonCanvas is manual, so it is up to the developer to > render the object properly, but NeoJSON does it automatically. > > In Javascript this will throw a syntax error: >> JSON.parse('{1: "foo"}') > > And this would generate a quoted key when serialized: >> JSON.stringify({1: "foo"}) >> {"1": "foo"} > > So my question is: should the library quote whatever you put as key in > order to produce valid JSON syntax? [2] > > Regards. > > [1] https://jsonlint.com/ > [2] https://www.ecma-international.org/publications/standards/Ecma-404.htm > > Esteban A. Maringolo >

Feb. 22, 2019

JSON keys not quoted?

by Esteban Maringolo

If you convert a Dictionary with numbers as keys it will produce not valid JSON [1], since all object keys must be quoted. E.g. NeoJSONWriter toString: (Dictionary with: 1->'foo'). or (Dictionary with: 1->'foo') asJson Should the library generate quoted keys? Seaside's WAJsonCanvas is manual, so it is up to the developer to render the object properly, but NeoJSON does it automatically. In Javascript this will throw a syntax error: > JSON.parse('{1: "foo"}') And this would generate a quoted key when serialized: > JSON.stringify({1: "foo"}) > {"1": "foo"} So my question is: should the library quote whatever you put as key in order to produce valid JSON syntax? [2] Regards. [1] https://jsonlint.com/ [2] https://www.ecma-international.org/publications/standards/Ecma-404.htm Esteban A. Maringolo

Feb. 22, 2019

Re: [Pharo-users] firebase client in pharo?

by Esteban Maringolo

Not that I know, I'm working on a CouchDB client to have something close to what Firebase, or even better, Firestore can provide. There is a thread about it. Esteban A. Maringolo El vie., 22 feb. 2019 a las 15:37, Tudor Girba (<tudor(a)tudorgirba.com>) escribiÃ³: > > Hi, > > Did anyone worked on connecting Pharo with Firebase? > > Cheers, > Doru > > > -- > www.feenk.com > > "Quality cannot be an afterthought." > >

Feb. 22, 2019

firebase client in pharo?

by Tudor Girba

Hi, Did anyone worked on connecting Pharo with Firebase? Cheers, Doru -- www.feenk.com "Quality cannot be an afterthought."

Feb. 22, 2019