Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #14448 > unrolled thread

$-sign in form input names?

Back to article view | Back to comp.lang.php

Contents

  $-sign in form input names? sonnichjensen@gmail.com - 2014-11-03 07:23 -0800
    Re: $-sign in form input names? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-11-03 15:54 +0000
    Re: $-sign in form input names? Denis McMahon <denismfmcmahon@gmail.com> - 2014-11-04 01:02 +0000
      Re: $-sign in form input names? "J.O. Aho" <user@example.net> - 2014-11-04 06:55 +0100
        Re: $-sign in form input names? "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-04 10:17 +0100
          Re: $-sign in form input names? Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-04 09:23 -0500
            Re: $-sign in form input names? gordonb.2w35u@burditt.org (Gordon Burditt) - 2014-11-04 09:35 -0600
              Re: $-sign in form input names? Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-04 10:37 -0500
            Re: $-sign in form input names? "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-04 21:42 +0100
              Re: $-sign in form input names? Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-04 17:01 -0500
                Re: $-sign in form input names? "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-04 23:46 +0100
                  Re: $-sign in form input names? Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-04 21:19 -0500
          Re: $-sign in form input names? Matthew Carter <m@ahungry.com> - 2014-11-04 09:31 -0500

#14448 — $-sign in form input names?

Hi

I am working on an existing system, and they have an interesting way of operating inputs:

form_name$value_name

Why the $? What is it good for?

They want a way to post data automatically from another system, but I cannot handle the $. Some other values such as / would be replaces by %xx but that does not work with $ 

What is so special about this?

[toc] | [next] | [standalone]

#14449

sonnichjensen@gmail.com writes:

> I am working on an existing system, and they have an interesting way
> of operating inputs:
>
> form_name$value_name
>
> Why the $? What is it good for?

It's just a separator.

> They want a way to post data automatically from another system, but I
> cannot handle the $.

Why can't you handle it?  It should appear in $_GET or $_POST just like
any other form control name.

> Some other values such as / would be replaces by
> %xx but that does not work with $

The URL encoding should not matter.  I think you should post a link to a
page that shows this problem, because you might well be doing something
rather odd.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#14452

On Mon, 03 Nov 2014 07:23:45 -0800, sonnichjensen wrote:

> They want a way to post data automatically from another system, but I
> cannot handle the $.

Of course you can handle the $, it's just a character in a string.

So what you have is a post or get array with fields, and you specify them 
as:

$_GET['form_name$field_name']
$_POST['form_name$field_name']

Note - use the single quoted string form to prevent $field_name 
triggering an attempt at variable substitution in the field name string, 
which may be the issue that's causing you difficulty if you're using:

$_GET["form_name$field_name"]
$_POST["form_name$field_name"]

See http://php.net/manual/en/language.types.string.php

esp:

"Note: Unlike the double-quoted and heredoc syntaxes, variables and 
escape sequences for special characters will not be expanded when they 
occur in single quoted strings."

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#14453

On 04/11/14 02:02, Denis McMahon wrote:

> See http://php.net/manual/en/language.types.string.php
>
> esp:
>
> "Note: Unlike the double-quoted and heredoc syntaxes, variables and
> escape sequences for special characters will not be expanded when they
> occur in single quoted strings."

I would add that you should always use single quotes by default and only 
use double quotes when you need to to use variables/methods inside a string.

As the double quotes will make the string to be parsed every time, which 
causes some slight overhead.

-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#14454

J.O. Aho wrote:

> As the double quotes will make the string to be parsed every time, which
> causes some slight overhead.

But see
<http://nikic.github.io/2012/01/09/Disproving-the-Single-Quotes-Performance-Myth.html>.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#14456

On 11/4/2014 4:17 AM, Christoph M. Becker wrote:
> J.O. Aho wrote:
> 
>> As the double quotes will make the string to be parsed every time, which
>> causes some slight overhead.
> 
> But see
> <http://nikic.github.io/2012/01/09/Disproving-the-Single-Quotes-Performance-Myth.html>.
> 

That's one person's opinion - and his test is full of holes.  For
instance - a timing loop like he shows is worthless in a multitasking
system.  Too many other things are going on; even a timer interrupt
during the loop can change timings.  You need to have a clean machine
(NOTHING else - including network, etc.) running to start.  No
paging/swapping.  Even then such tests are suspect because you can't
stop everything.  Running on a single tasking system such as MS-DOS
would be better, but still not necessarily accurate.

It's also only valid for one version of PHP - the one he's using.
Different versions can operate differently.

His whole argument is based on his statement: "I hold the opinion that
microoptimization like that is just pointless.".  Good programming
practice is not microoptimization!

And the killer is this statement: "Now some may argue: PHP is an
interpreted language, so compile time actually also happens at runtime.
My response to that would normally be: Use APC."  That MAY be find if
you're running your own server.  But most people aren't, and APC is not
available to him.

I could go on, but the bottom line is - he is obviously biased, and his
arguments are full of holes.  I agree with J.O. - single quotes are
better unless you need to parse the strings.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14460

> That's one person's opinion - and his test is full of holes.  For
> instance - a timing loop like he shows is worthless in a multitasking
> system.  Too many other things are going on; even a timer interrupt
> during the loop can change timings.  You need to have a clean machine
> (NOTHING else - including network, etc.) running to start.  No
> paging/swapping.  Even then such tests are suspect because you can't
> stop everything.  Running on a single tasking system such as MS-DOS
> would be better, but still not necessarily accurate.

There are workarounds to this.  Run the test long enough that the
timer interrupts and other short disturbances will even out for
both test cases.  For example, run the test for *A FULL YEAR* for
each case under test.

> It's also only valid for one version of PHP - the one he's using.
> Different versions can operate differently.
> 
> His whole argument is based on his statement: "I hold the opinion that
> microoptimization like that is just pointless.".  Good programming
> practice is not microoptimization!

I hold the opinion that even if the use of single quotes turns out
to be megapessimization, you should *still* use them.

I'm going to argue that you should use single quotes for strings
that do not need string expansion even if the use of single quotes
makes the overall time to process the whole web page 100% *SLOWER*.
That's rather difficult, as presumably you actually *DO* something
with the string, such as outputting it to the web page, which will
take a lot longer than even badly written string parsing.

It's a security and maintenance issue.  A string containing a British
pound symbol won't cause any problem with string expansion.  Port
it to a USA environment, making a mass substitution of the British
pound symbol to '$', and now string expansion may mess up your
string.  If you don't have warnings turned on about the use of
undefined variables, this is a difficult error to spot.  And it
might happen to hit a defined variable.  Or PHP might add some
other substitution previously unknown.

> I could go on, but the bottom line is - he is obviously biased, and his
> arguments are full of holes.  I agree with J.O. - single quotes are
> better unless you need to parse the strings.
even if single quotes are measurably and significantly slower.

[toc] | [prev] | [next] | [standalone]

#14461

On 11/4/2014 10:35 AM, Gordon Burditt wrote:
>> That's one person's opinion - and his test is full of holes.  For
>> instance - a timing loop like he shows is worthless in a multitasking
>> system.  Too many other things are going on; even a timer interrupt
>> during the loop can change timings.  You need to have a clean machine
>> (NOTHING else - including network, etc.) running to start.  No
>> paging/swapping.  Even then such tests are suspect because you can't
>> stop everything.  Running on a single tasking system such as MS-DOS
>> would be better, but still not necessarily accurate.
> 
> There are workarounds to this.  Run the test long enough that the
> timer interrupts and other short disturbances will even out for
> both test cases.  For example, run the test for *A FULL YEAR* for
> each case under test.
>

Yes, averaging a lot of runs will minimize the impact of external
factors.  But a small difference can still be incorrect.

>> It's also only valid for one version of PHP - the one he's using.
>> Different versions can operate differently.
>>
>> His whole argument is based on his statement: "I hold the opinion that
>> microoptimization like that is just pointless.".  Good programming
>> practice is not microoptimization!
> 
> I hold the opinion that even if the use of single quotes turns out
> to be megapessimization, you should *still* use them.
> 
> I'm going to argue that you should use single quotes for strings
> that do not need string expansion even if the use of single quotes
> makes the overall time to process the whole web page 100% *SLOWER*.
> That's rather difficult, as presumably you actually *DO* something
> with the string, such as outputting it to the web page, which will
> take a lot longer than even badly written string parsing.
> 
> It's a security and maintenance issue.  A string containing a British
> pound symbol won't cause any problem with string expansion.  Port
> it to a USA environment, making a mass substitution of the British
> pound symbol to '$', and now string expansion may mess up your
> string.  If you don't have warnings turned on about the use of
> undefined variables, this is a difficult error to spot.  And it
> might happen to hit a defined variable.  Or PHP might add some
> other substitution previously unknown.
> 

Very good points, Gordon.

>> I could go on, but the bottom line is - he is obviously biased, and his
>> arguments are full of holes.  I agree with J.O. - single quotes are
>> better unless you need to parse the strings.
> even if single quotes are measurably and significantly slower.
> 



-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14465

Jerry Stuckle wrote:

> On 11/4/2014 4:17 AM, Christoph M. Becker wrote:
>> J.O. Aho wrote:
>>
>>> As the double quotes will make the string to be parsed every time, which
>>> causes some slight overhead.
>>
>> But see
>> <http://nikic.github.io/2012/01/09/Disproving-the-Single-Quotes-Performance-Myth.html>.
> 
> I could go on, but the bottom line is - he is obviously biased, and his
> arguments are full of holes.  I agree with J.O. - single quotes are
> better unless you need to parse the strings.

Obviously you have not really understood the issue -- and neither has
J.O.  A double quoted string is "parsed" (actually, lexed) only *once*.
 A single quoted string is also lexed once.  So only the lexing time
could make a difference (and even this could be ignored when some kind
of bytecode cache is available; OPcache is enabled by default since PHP
5.5.0).

Anyhow, even a single quoted string has to be scanned for escapes ('\\',
'\''), so there is presumably not much difference (if we ignore
interpolation, what is not available for single quoted strings, anyway).
 Nikita's quick benchmark confirms this presumption.  A more thorough
measurement is left to the unbelieving reader.

It should be noted that this behavior does not apply to old PHP
versions, see
<http://blog.golemon.com/2006/06/how-long-is-piece-of-string.html>.

BTW: I rarely use double quoted strings.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#14466

On 11/4/2014 3:42 PM, Christoph M. Becker wrote:
> Jerry Stuckle wrote:
> 
>> On 11/4/2014 4:17 AM, Christoph M. Becker wrote:
>>> J.O. Aho wrote:
>>>
>>>> As the double quotes will make the string to be parsed every time, which
>>>> causes some slight overhead.
>>>
>>> But see
>>> <http://nikic.github.io/2012/01/09/Disproving-the-Single-Quotes-Performance-Myth.html>.
>>
>> I could go on, but the bottom line is - he is obviously biased, and his
>> arguments are full of holes.  I agree with J.O. - single quotes are
>> better unless you need to parse the strings.
> 
> Obviously you have not really understood the issue -- and neither has
> J.O.  A double quoted string is "parsed" (actually, lexed) only *once*.
>  A single quoted string is also lexed once.  So only the lexing time
> could make a difference (and even this could be ignored when some kind
> of bytecode cache is available; OPcache is enabled by default since PHP
> 5.5.0).
>

Oh, I understand the issue, all right.  It's the conclusion I disagree with.

> Anyhow, even a single quoted string has to be scanned for escapes ('\\',
> '\''), so there is presumably not much difference (if we ignore
> interpolation, what is not available for single quoted strings, anyway).
>  Nikita's quick benchmark confirms this presumption.  A more thorough
> measurement is left to the unbelieving reader.
> 

"Presumably" - opinion, not fact.

> It should be noted that this behavior does not apply to old PHP
> versions, see
> <http://blog.golemon.com/2006/06/how-long-is-piece-of-string.html>.
> 
> BTW: I rarely use double quoted strings.
> 

Yes, I understand that, also.  I've been using PHP since 3.something.

But I also have extensive experience in parsing strings, which comes
from over 45 years of programming experience.  I also have extensive
experience in running benchmarks.  Anyone knowledgeable in benchmarking
would see all kinds of holes.

There is a lot of information on the internet.  And quite a bit of it is
wrong.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14467

Jerry Stuckle wrote:

> Yes, I understand that, also.  I've been using PHP since 3.something.

Lucky me.  I can't even image how PHP has looked before 4.3.0,
considering, for instance, that objects had value semantics before 5.0.0.

> But I also have extensive experience in parsing strings, which comes
> from over 45 years of programming experience.  I also have extensive
> experience in running benchmarks.  Anyone knowledgeable in benchmarking
> would see all kinds of holes.

Then it might have been better if *you* had implemented the new PHP 7
AST based parser[1] instead of Nikita.  Especially his assessment
regarding "Impact on performance and memory usage" might be plain wrong. ;)

> There is a lot of information on the internet.  And quite a bit of it is
> wrong.

ACK.

[1] <https://wiki.php.net/rfc/abstract_syntax_tree>
[2]
<https://wiki.php.net/rfc/abstract_syntax_tree#impact_on_performance_and_memory_usage>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#14468

On 11/4/2014 5:46 PM, Christoph M. Becker wrote:
> Jerry Stuckle wrote:
> 
>> Yes, I understand that, also.  I've been using PHP since 3.something.
> 
> Lucky me.  I can't even image how PHP has looked before 4.3.0,
> considering, for instance, that objects had value semantics before 5.0.0.
> 
>> But I also have extensive experience in parsing strings, which comes
>> from over 45 years of programming experience.  I also have extensive
>> experience in running benchmarks.  Anyone knowledgeable in benchmarking
>> would see all kinds of holes.
> 
> Then it might have been better if *you* had implemented the new PHP 7
> AST based parser[1] instead of Nikita.  Especially his assessment
> regarding "Impact on performance and memory usage" might be plain wrong. ;)
>

Perhaps.  But I'm not in the habit of providing free support to
commercial enterprises (although I do contribute to non-commercial
enterprises and open source packages).  If there really is a difference,
it is in the poor implementation of single quotes parsing.

But the web page you cited has unsupportable statements, for the reasons
I mentioned.

>> There is a lot of information on the internet.  And quite a bit of it is
>> wrong.
> 
> ACK.
> 
> [1] <https://wiki.php.net/rfc/abstract_syntax_tree>
> [2]
> <https://wiki.php.net/rfc/abstract_syntax_tree#impact_on_performance_and_memory_usage>
> 

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14457

"Christoph M. Becker" <cmbecker69@arcor.de> writes:

> J.O. Aho wrote:
>
>> As the double quotes will make the string to be parsed every time, which
>> causes some slight overhead.
>
> But see
> <http://nikic.github.io/2012/01/09/Disproving-the-Single-Quotes-Performance-Myth.html>.

I personally prefer single quotes + concatenation (or even better,
sprintf) for readability.

Emacs' php-mode isn't so great at highlighting variables inside double
quotes.

-- 
Matthew Carter (m@ahungry.com)
http://ahungry.com

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web