From toby.corkindale at strategicdata.com.au Thu Jun 2 21:49:19 2016 From: toby.corkindale at strategicdata.com.au (Toby Corkindale) Date: Fri, 03 Jun 2016 14:49:19 +1000 Subject: [Melbourne-pm] When your variables can't keep their types.. Message-ID: <7532265.dSc6v3k81z@adonai> Guess the output... #!/usr/bin/env perl use 5.12.0; use warnings; use JSON::XS qw(encode_json); my $port = 1234; my $j1 = encode_json({ port => $port }); my $foo = "$port"; my $j2 = encode_json({ port => $port }); say $j1; say $j2; if ($j1 ne $j2) { die "WTF Perl?!"; } From mathew.blair.robertson at gmail.com Fri Jun 3 01:36:25 2016 From: mathew.blair.robertson at gmail.com (Mathew Robertson) Date: Fri, 3 Jun 2016 18:36:25 +1000 Subject: [Melbourne-pm] When your variables can't keep their types.. In-Reply-To: <7532265.dSc6v3k81z@adonai> References: <7532265.dSc6v3k81z@adonai> Message-ID: $port is a number, $foo is a string. $port hasn't be coerced into a string On 3 June 2016 at 14:49, Toby Corkindale < toby.corkindale at strategicdata.com.au> wrote: > Guess the output... > > > #!/usr/bin/env perl > use 5.12.0; > use warnings; > use JSON::XS qw(encode_json); > > my $port = 1234; > > my $j1 = encode_json({ port => $port }); > my $foo = "$port"; > my $j2 = encode_json({ port => $port }); > > say $j1; > say $j2; > > if ($j1 ne $j2) { > die "WTF Perl?!"; > } > > _______________________________________________ > Melbourne-pm mailing list > Melbourne-pm at pm.org > http://mail.pm.org/mailman/listinfo/melbourne-pm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjenkins at rjj.id.au Fri Jun 3 03:45:06 2016 From: rjenkins at rjj.id.au (Russell Jenkins) Date: Fri, 3 Jun 2016 20:45:06 +1000 Subject: [Melbourne-pm] When your variables can't keep their types.. In-Reply-To: References: <7532265.dSc6v3k81z@adonai> Message-ID: <7635c321-4fde-bc1f-6d4c-f33c04574bfa@rjj.id.au> On 3/06/2016 6:36 PM, Mathew Robertson wrote: > $port is a number, $foo is a string. > > $port hasn't be coerced into a string No spoilers, but you may want to double check the internal representation with Devel::Peek. Cheers, Russell. From toby.corkindale at strategicdata.com.au Sun Jun 5 17:29:51 2016 From: toby.corkindale at strategicdata.com.au (Toby Corkindale) Date: Mon, 06 Jun 2016 10:29:51 +1000 Subject: [Melbourne-pm] When your variables can't keep their types.. In-Reply-To: References: <7532265.dSc6v3k81z@adonai> Message-ID: <3935274.mHWEELVdh5@adonai> Thanks for the replies all, but perhaps my point was missed. It's not about JSON treating strings and integers differently. Note that I did not assign anything to $port between the two calls to encode_json(), yet $port changes. Despite their name ("variables"), in normal programming languages, variables only change when they're assigned to. hence the exclamation at the end of the example -- "WTF Perl?!" On Saturday, 4 June 2016 6:19:23 PM AEST Alex Balhatchet wrote: > Hi Toby, > > If you convert 1234 from Perl to JSON you get 1234, if you convert "1234" > from Perl to JSON you get "1234" - this is good, the conversion keeps its > types perfectly. > > On Friday, 3 June 2016, Toby Corkindale > wrote: > > Guess the output... > > > > > > #!/usr/bin/env perl > > use 5.12.0; > > use warnings; > > use JSON::XS qw(encode_json); > > > > my $port = 1234; > > > > my $j1 = encode_json({ port => $port }); > > my $foo = "$port"; > > my $j2 = encode_json({ port => $port }); > > > > say $j1; > > say $j2; > > > > if ($j1 ne $j2) { > > > > die "WTF Perl?!"; > > > > } From andrew at sericyb.com.au Sun Jun 5 17:33:46 2016 From: andrew at sericyb.com.au (Andrew Pam) Date: Mon, 6 Jun 2016 10:33:46 +1000 Subject: [Melbourne-pm] When your variables can't keep their types.. In-Reply-To: <3935274.mHWEELVdh5@adonai> References: <7532265.dSc6v3k81z@adonai> <3935274.mHWEELVdh5@adonai> Message-ID: <5754C4EA.20406@sericyb.com.au> On 06/06/16 10:29, Toby Corkindale wrote: > Thanks for the replies all, but perhaps my point was missed. > It's not about JSON treating strings and integers differently. > > Note that I did not assign anything to $port between the two calls to > encode_json(), yet $port changes. > > Despite their name ("variables"), in normal programming languages, variables > only change when they're assigned to. > > hence the exclamation at the end of the example -- "WTF Perl?!" Did you get my emails about the way Perl handles SV (Scalar Value) objects internally, documented in the perlguts manpage? It doesn't seem to have made it to the list. It can get more WTF than that, because SVs can have IVs (integer values) and PVs (pointer values, usually strings) that needn't be related at all if you assign them manually - for example, $x can be both 1 and '2' at the same time. Don't do that. :) Stringifying an SV creates the PV. Cheers, Andrew From simon at unisolve.com.au Sun Jun 5 17:35:12 2016 From: simon at unisolve.com.au (Simon Taylor) Date: Mon, 6 Jun 2016 10:35:12 +1000 Subject: [Melbourne-pm] When your variables can't keep their types.. In-Reply-To: <3935274.mHWEELVdh5@adonai> References: <7532265.dSc6v3k81z@adonai> <3935274.mHWEELVdh5@adonai> Message-ID: <93d674e9-c87c-cb0d-7400-93a047201229@unisolve.com.au> On 6/06/2016 10:29 AM, Toby Corkindale wrote: > Thanks for the replies all, but perhaps my point was missed. > It's not about JSON treating strings and integers differently. > > Note that I did not assign anything to $port between the two calls to > encode_json(), yet $port changes. > > Despite their name ("variables"), in normal programming languages, variables > only change when they're assigned to. > > hence the exclamation at the end of the example -- "WTF Perl?!" I agree. I didn't run your sample to see if it behaved the same way here, but it is very counter-intuitive behavior. Cheers, Simon > > On Saturday, 4 June 2016 6:19:23 PM AEST Alex Balhatchet wrote: >> Hi Toby, >> >> If you convert 1234 from Perl to JSON you get 1234, if you convert "1234" >> from Perl to JSON you get "1234" - this is good, the conversion keeps its >> types perfectly. >> >> On Friday, 3 June 2016, Toby Corkindale >> wrote: >>> Guess the output... >>> >>> >>> #!/usr/bin/env perl >>> use 5.12.0; >>> use warnings; >>> use JSON::XS qw(encode_json); >>> >>> my $port = 1234; >>> >>> my $j1 = encode_json({ port => $port }); >>> my $foo = "$port"; >>> my $j2 = encode_json({ port => $port }); >>> >>> say $j1; >>> say $j2; >>> >>> if ($j1 ne $j2) { >>> >>> die "WTF Perl?!"; >>> >>> } > _______________________________________________ > Melbourne-pm mailing list > Melbourne-pm at pm.org > http://mail.pm.org/mailman/listinfo/melbourne-pm From andrew at sericyb.com.au Sun Jun 5 17:39:25 2016 From: andrew at sericyb.com.au (Andrew Pam) Date: Mon, 6 Jun 2016 10:39:25 +1000 Subject: [Melbourne-pm] When your variables can't keep their types.. In-Reply-To: <93d674e9-c87c-cb0d-7400-93a047201229@unisolve.com.au> References: <7532265.dSc6v3k81z@adonai> <3935274.mHWEELVdh5@adonai> <93d674e9-c87c-cb0d-7400-93a047201229@unisolve.com.au> Message-ID: <5754C63D.9040409@sericyb.com.au> On 06/06/16 10:35, Simon Taylor wrote: > I didn't run your sample to see if it behaved the same way here, but > it is very counter-intuitive behavior. One word: caching. Once you stringify, why repeat the work? It makes sense once you understand the design decision. Cheers, Andrew From alfiej at fastmail.fm Sun Jun 5 17:42:17 2016 From: alfiej at fastmail.fm (Alfie John) Date: Mon, 06 Jun 2016 10:42:17 +1000 Subject: [Melbourne-pm] When your variables can't keep their types.. In-Reply-To: <3935274.mHWEELVdh5@adonai> References: <7532265.dSc6v3k81z@adonai> <3935274.mHWEELVdh5@adonai> Message-ID: <1465173737.2740196.628725977.735D0110@webmail.messagingengine.com> On Mon, Jun 6, 2016, at 10:29 AM, Toby Corkindale wrote: > Thanks for the replies all, but perhaps my point was missed. > It's not about JSON treating strings and integers differently. > > Note that I did not assign anything to $port between the two calls to > encode_json(), yet $port changes. > > Despite their name ("variables"), in normal programming languages, > variables > only change when they're assigned to. > > hence the exclamation at the end of the example -- "WTF Perl?!" :( In future, if you want to be more explicit in types there's: http://search.cpan.org/dist/JSON-Typist/lib/JSON/Typist.pm Alfie From simon at unisolve.com.au Sun Jun 5 17:55:19 2016 From: simon at unisolve.com.au (Simon Taylor) Date: Mon, 6 Jun 2016 10:55:19 +1000 Subject: [Melbourne-pm] When your variables can't keep their types.. In-Reply-To: <5754C63D.9040409@sericyb.com.au> References: <7532265.dSc6v3k81z@adonai> <3935274.mHWEELVdh5@adonai> <93d674e9-c87c-cb0d-7400-93a047201229@unisolve.com.au> <5754C63D.9040409@sericyb.com.au> Message-ID: <706eafe9-c9b5-2127-3b61-7c539f2d99d2@unisolve.com.au> Hello Andrew, On 6/06/2016 10:39 AM, Andrew Pam wrote: > On 06/06/16 10:35, Simon Taylor wrote: >> I didn't run your sample to see if it behaved the same way here, but >> it is very counter-intuitive behavior. > > One word: caching. > > Once you stringify, why repeat the work? It makes sense once you > understand the design decision. My 10c? This kind of spooky action at a distance makes no sense. my $foo = "$port"; The casual user has the right to expect that the stringification going on here will not affect $port We're used to it, but it doesn't make it good or sensible in my view... it just makes it something we're used to. Cheers, Simon From andrew at sericyb.com.au Sun Jun 5 18:30:51 2016 From: andrew at sericyb.com.au (Andrew Pam) Date: Mon, 6 Jun 2016 11:30:51 +1000 Subject: [Melbourne-pm] When your variables can't keep their types.. In-Reply-To: <706eafe9-c9b5-2127-3b61-7c539f2d99d2@unisolve.com.au> References: <7532265.dSc6v3k81z@adonai> <3935274.mHWEELVdh5@adonai> <93d674e9-c87c-cb0d-7400-93a047201229@unisolve.com.au> <5754C63D.9040409@sericyb.com.au> <706eafe9-c9b5-2127-3b61-7c539f2d99d2@unisolve.com.au> Message-ID: <5754D24B.2080102@sericyb.com.au> On 06/06/16 10:55, Simon Taylor wrote: > The casual user has the right to expect that the stringification going > on here will not affect $port > > We're used to it, but it doesn't make it good or sensible in my > view... it just makes it something we're used to. It's a classic mismatch of models. In Perl, variables aren't really supposed to be strongly typed, so there are bound to be problems when you try to use them in a strongly typed way - which is where the excellent suggestion of JSON::Typist makes sense. JavaScript has similar issues! Cheers, Andrew From mathew.blair.robertson at gmail.com Sun Jun 5 23:51:24 2016 From: mathew.blair.robertson at gmail.com (Mathew Robertson) Date: Mon, 6 Jun 2016 16:51:24 +1000 Subject: [Melbourne-pm] When your variables can't keep their types.. In-Reply-To: <5754C63D.9040409@sericyb.com.au> References: <7532265.dSc6v3k81z@adonai> <3935274.mHWEELVdh5@adonai> <93d674e9-c87c-cb0d-7400-93a047201229@unisolve.com.au> <5754C63D.9040409@sericyb.com.au> Message-ID: Caching doesn't make much sense. The perlop defines how a value it is used - it shouldn't matter how it is stored, which (with a few seconds of thought) probably be as a binary blob.... it is the attribute/tags that define whether it is a pointer, string as per today Obviously comparing a 32bit number vs another 32bit number, will be thousands of cycles faster for an int than a char*.... but given that Perl isn't the fastest language, so I wouldn't expect that to be a dominating difference. ... unless "use integer" is in effect. On 6 June 2016 at 10:39, Andrew Pam wrote: > On 06/06/16 10:35, Simon Taylor wrote: > >> I didn't run your sample to see if it behaved the same way here, but it >> is very counter-intuitive behavior. >> > > One word: caching. > > Once you stringify, why repeat the work? It makes sense once you > understand the design decision. > > Cheers, > Andrew > > _______________________________________________ > Melbourne-pm mailing list > Melbourne-pm at pm.org > http://mail.pm.org/mailman/listinfo/melbourne-pm > -------------- next part -------------- An HTML attachment was scrubbed... URL: