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

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

Refresher for array handling???

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

Contents

  Refresher for array handling??? bobmct <r.mariotti@fdcx.net> - 2015-07-14 12:12 -0400
    Re: Refresher for array handling??? Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-07-15 15:01 +0200
      Re: Refresher for array handling??? Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-07-15 15:03 +0200
      Re: Refresher for array handling??? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-07-17 21:24 +0200
        Re: Refresher for array handling??? Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-07-20 16:30 +0200
          Re: Refresher for array handling??? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-07-20 19:45 +0200
            Re: Refresher for array handling??? Matthew Carter <m@ahungry.com> - 2015-07-20 22:36 -0400
            Re: Refresher for array handling??? Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-07-21 11:22 +0200
              Re: Refresher for array handling??? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-07-21 13:30 +0200
                Re: Refresher for array handling??? Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-07-21 14:03 +0200
          Re: Refresher for array handling??? Denis McMahon <denismfmcmahon@gmail.com> - 2015-07-21 01:01 +0000
            Re: Refresher for array handling??? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-07-21 09:07 +0200
    Re: Refresher for array handling??? "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-07-15 20:18 +0200
    Re: Refresher for array handling??? Denis McMahon <denismfmcmahon@gmail.com> - 2015-07-17 02:51 +0000

#15585 — Refresher for array handling???

I have come across a rather old php program that develops a two
dimensional array's content then displays the accumulated contents at
the end.

After some upgrades to the latest php 5.x I started seeing "array to
string conversion errors".  I am aware that these warings can be
suppressed but I'd rather take the time to reference the array
elements the correct way.

Here's a snippet of code as it looks now:
$frq = array(array);
.
//  logic to accumulate statistics (all works fine based on dump of
array
.
.
// unload accummulated array as rows in a table
// iterate top to bottom using lowest to highest defined values
for  ( $X=$_minimum; $X<=$_maximum; $X++) {
	$Y = sprintf("%02d",$X);
	$Y1 = sprintf("%u",$X);
	print <<< EOD
	<tr bgcolor="$bgcolor">
	<td align="center"><img src="pix/balls/$Y.png" alt="$Y" ></td>
EOD;
	// iterate left to right based on predefined columns
	for ( $z=0; $z<=7; $z++) {
		$Y2 = sprintf("%u",$z);
		print <<< EOD
		<td align="center">$frq[$Y1][$Y2]</td>
EOD;
	}
}
.
.

as can be seen, I'm expanding the index X to a zero filled 2 character
string representative of the integer to properly select the image.
Also, the sprintf %u is to convert the index pointer to an unsigned
integer to point to each numbered index.

While this or something like this has been working for many years I
know there is a more standard way.  I'm hoping someone will provide an
example of the "best" or at least "most conventional" method to
accomplish this task.

Thanks for any/all that can help.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[toc] | [next] | [standalone]

#15586

On 7/14/2015 6:12 PM, bobmct wrote:
> I have come across a rather old php program that develops a two
> dimensional array's content then displays the accumulated contents at
> the end.
>
> After some upgrades to the latest php 5.x I started seeing "array to
> string conversion errors".  I am aware that these warings can be
> suppressed but I'd rather take the time to reference the array
> elements the correct way.
>
> Here's a snippet of code as it looks now:
> $frq = array(array);
> .
> //  logic to accumulate statistics (all works fine based on dump of
> array
> .
> .
> // unload accummulated array as rows in a table
> // iterate top to bottom using lowest to highest defined values
> for  ( $X=$_minimum; $X<=$_maximum; $X++) {
> 	$Y = sprintf("%02d",$X);
> 	$Y1 = sprintf("%u",$X);
> 	print <<< EOD
> 	<tr bgcolor="$bgcolor">
> 	<td align="center"><img src="pix/balls/$Y.png" alt="$Y" ></td>
> EOD;
> 	// iterate left to right based on predefined columns
> 	for ( $z=0; $z<=7; $z++) {
> 		$Y2 = sprintf("%u",$z);
> 		print <<< EOD
> 		<td align="center">$frq[$Y1][$Y2]</td>
> EOD;
> 	}
> }
> .
> .
>
> as can be seen, I'm expanding the index X to a zero filled 2 character
> string representative of the integer to properly select the image.
> Also, the sprintf %u is to convert the index pointer to an unsigned
> integer to point to each numbered index.
>
> While this or something like this has been working for many years I
> know there is a more standard way.  I'm hoping someone will provide an
> example of the "best" or at least "most conventional" method to
> accomplish this task.
>
> Thanks for any/all that can help.
>
>

Hi,

A few ideas to clean it up little.
Since I don't know what the array $frq represents, I have filled it with 
some just-invented-by-me nonsense, and some numbers for the second index.


<?php
$frq = array();
$frq[12] = array(13.4, 17.4, 20.0);
$frq[13] = array(3.5, 6.7, 17.3);
$frq[19] = array(3.1, 194.45, 10.909);

echo "<pre>";
print_r($frq);	
echo "<pre>";
?>

Now, you have an array with arrays (PHP doesn't have 'real' 
multidimensional arrays, but you can easily mimic their behavior).
The above script creates the following output:

Array
(
     [12] => Array
         (
             [0] => 13.4
             [1] => 17.4
             [2] => 20
         )

     [13] => Array
         (
             [0] => 3.5
             [1] => 6.7
             [2] => 17.3
         )

     [19] => Array
         (
             [0] => 3.1
             [1] => 194.45
             [2] => 10.909
         )

)

As you can see, the first "dimension" (Just call it index) contains 12, 
13, and 19, and they contain a value of.... another array.
Since I didn't assign keys for the secondary arrays, only values, PHP 
creates them for me, being 0,1,2 in this example.

foreach():
Now look at the following example and its output:

<?php
$frq = array();
$frq[12] = array(13.4, 17.4, 20.0);
$frq[13] = array(3.5, 6.7, 17.3);
$frq[19] = array(3.1, 194.45, 10.909);


echo "<table><tbody>";
foreach ($frq as $key => $someArr){
	echo "<tr><td>key:{$key}</td>";
	// now loop over the $someArr, which is an array too:
	foreach($someArr as $value){
		echo "<td>val:{$value}</td>";
	}
}
echo "</tbody></table>";
?>

It uses foreach to loop over all elements in an array.

I would advice you to start with using this snippet to inspect your $frq 
array.
echo "<pre>";
print_r($frq);	
echo "<pre>";

Your error "Array to string conversion" means that you are treating an 
array as a string, so I expect that in your $frq you have something 
unexpected, like:
$frq[33][55] = array(1,4,7) instead of (the expected):
$frq[33][55] = "some_plain_value_that_is_not_an_array"


Hope this helps!

Regards,
Erwin Moller

-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

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

#15587

Fix for missing </tr>

> foreach():
> Now look at the following example and its output:
>
> <?php
> $frq = array();
> $frq[12] = array(13.4, 17.4, 20.0);
> $frq[13] = array(3.5, 6.7, 17.3);
> $frq[19] = array(3.1, 194.45, 10.909);
>
>
> echo "<table><tbody>";
> foreach ($frq as $key => $someArr){
>      echo "<tr><td>key:{$key}</td>";
>      // now loop over the $someArr, which is an array too:
>      foreach($someArr as $value){
>          echo "<td>val:{$value}</td>";
>      }
        echo "</tr>";
> }
> echo "</tbody></table>";
> ?>
>

-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

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

#15590

Erwin Moller wrote:

> <?php
> $frq = array();
> $frq[12] = array(13.4, 17.4, 20.0);
> $frq[13] = array(3.5, 6.7, 17.3);
> $frq[19] = array(3.1, 194.45, 10.909);

DRY:

  $frq = array(
    12 => array(13.4, 17.4, 20.0),
    13 => array(3.5, 6.7, 17.3),
    19 => array(3.1, 194.45, 10.909)
  );

Since PHP 5.4:

  $frq = [
    12 => [13.4, 17.4, 20.0],
    13 => [3.5, 6.7, 17.3],
    19 => [3.1, 194.45, 10.909]
  ];
 
<http://php.net/manual/en/migration54.new-features.php>

> echo "<pre>";
> print_r($frq);
> echo "<pre>";
        ^^
  echo '<pre>' . print_r($frq, true) . '</pre>';

<http://php.net/print_r>

With the Xdebug extension enabled,

  var_dump($frq);

will generate the output using a fixed-width font by default, and you have 
more control over the output, such as the nesting level.

<http://xdebug.org/docs/display>

> ?>

Avoid this in PHP programs unless you are sure that you want what follows to 
be sent to the standard output.

<http://www.php-fig.org/psr/psr-2/> etc.
 
-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#15595

On 7/17/2015 9:24 PM, Thomas 'PointedEars' Lahn wrote:
> Erwin Moller wrote:
>
>> <?php
>> $frq = array();
>> $frq[12] = array(13.4, 17.4, 20.0);
>> $frq[13] = array(3.5, 6.7, 17.3);
>> $frq[19] = array(3.1, 194.45, 10.909);
>
> DRY:
>
>    $frq = array(
>      12 => array(13.4, 17.4, 20.0),
>      13 => array(3.5, 6.7, 17.3),
>      19 => array(3.1, 194.45, 10.909)
>    );
>
> Since PHP 5.4:
>
>    $frq = [
>      12 => [13.4, 17.4, 20.0],
>      13 => [3.5, 6.7, 17.3],
>      19 => [3.1, 194.45, 10.909]
>    ];
>
> <http://php.net/manual/en/migration54.new-features.php>

What is your point?
You have another syntax to create an array?

And the above "improvement" is a poor example of Don't Repeat Yourself, 
in my humble opinion.
DRY is not about slashing out a few $frq in the sourcecode...


>
>> echo "<pre>";
>> print_r($frq);
>> echo "<pre>";
>          ^^
>    echo '<pre>' . print_r($frq, true) . '</pre>';
>
> <http://php.net/print_r>
>
> With the Xdebug extension enabled,
>
>    var_dump($frq);
>
> will generate the output using a fixed-width font by default, and you have
> more control over the output, such as the nesting level.
>
> <http://xdebug.org/docs/display>

???
I try to tell the OP how to inspect his data structure, a worthwhile 
idea for newcomers, and your extra info added nothing.
Could you please stop making such observations???
It is noise.

>
>> ?>
>
> Avoid this in PHP programs unless you are sure that you want what follows to
> be sent to the standard output.

I don't agree with that attitude.
Leaving out ?> at the end is one of the worst ideas PHP ever came up 
with, and I won't support it.

If one doesn't know what ?> means, and one is surprised by the fact that 
what follows after ?> is send to standard output, one should not be 
programming....

>
> <http://www.php-fig.org/psr/psr-2/> etc.
>

Do you really care for that Coding Style Guide?
I don't.

Regards,
Erwin Moller

-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

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

#15596

Erwin Moller wrote:

> On 7/17/2015 9:24 PM, Thomas 'PointedEars' Lahn wrote:
>> DRY:
>>
>>    $frq = array(
>>      12 => array(13.4, 17.4, 20.0),
>>      13 => array(3.5, 6.7, 17.3),
>>      19 => array(3.1, 194.45, 10.909)
>>    );
>>
>> Since PHP 5.4:
>>
>>    $frq = [
>>      12 => [13.4, 17.4, 20.0],
>>      13 => [3.5, 6.7, 17.3],
>>      19 => [3.1, 194.45, 10.909]
>>    ];
>>
>> <http://php.net/manual/en/migration54.new-features.php>
> 
> What is your point?
> You have another syntax to create an array?

That, too.

> And the above "improvement" is a poor example of Don't Repeat Yourself,
> in my humble opinion.
> DRY is not about slashing out a few $frq in the sourcecode...

Obviously you have not understood DRY.  It is about _not_ *repeating* 
yourself in order to make code *less* error-prone and *easier* to maintain.  
There is no need to repeat a variable identifier here, and no need to have 
several statements when you can have one.  This is only an example where
the identifier happens to be short.

Unnecessary repetition is not only time-consuming when reading and writing 
code, but can easily lead to inconsistencies that are even more time-
consuming to spot and fix.  As for PHP, the statement

  $bar['baz'] = 42;

*creates* the $bar array if it did not exist.  Suppose after refactoring the 
real variable name were $foo; it is possible, and it has happened even to 
the best of us, that in a non-trivial piece of code one will spend *hours* 
searching for the reason why the darn $foo array is empty.  This does not 
happen if you initialize the array once, as I suggested, or merge with 
another array later.

>>> […]
>>> echo "<pre>";
>>          ^^
>>    echo '<pre>' . print_r($frq, true) . '</pre>';
>>
>> <http://php.net/print_r>
>>
>> With the Xdebug extension enabled,
>>
>>    var_dump($frq);
>>
>> will generate the output using a fixed-width font by default, and you
>> have more control over the output, such as the nesting level.
>>
>> <http://xdebug.org/docs/display>
> 
> ???
> I try to tell the OP how to inspect his data structure, a worthwhile
> idea for newcomers, and your extra info added nothing.

It did add *a lot*.  *And* I pointed out a mistake that you made that would 
cause the output of the OP to be displayed with a fixed-width font (in the 
best case) starting at that line.

> Could you please stop making such observations???

Could you please read what you are replying to?  And fix your Question Mark 
key.

> It is noise.

It is not, by contrast to what you are making here and now.

>>> ?>
>>
>> Avoid this in PHP programs unless you are sure that you want what follows
>> to be sent to the standard output.
> 
> I don't agree with that attitude.

It is not an attitude, it is a recommendation.  One that is confirmed by 
previous PHP coding standards, and by *the* current PHP Coding Style Guide 
(PSR-2) which extends *the* current PHP Basic Coding Standard (PSR-1), all 
of which I referred to.

> Leaving out ?> at the end is one of the worst ideas PHP ever came up
> with, and I won't support it.

Explain that to the many people who wondered why their HTTP headers were not 
sent after including a library.

> If one doesn't know what ?> means, and one is surprised by the fact that
> what follows after ?> is send to standard output, one should not be
> programming....

Not knowing what “?>” means is not the point here; I have not even given 
indication that it would be.  Avoiding error-prone code is.

>> <http://www.php-fig.org/psr/psr-2/> etc.
> 
> Do you really care for that Coding Style Guide?

I do, and several thousands of other professional PHP developers.

> I don't.

Why should anyone care about your humble opinion?  You are evidentially only 
an amateur when it comes to PHP programming; that is why you do not care 
about “that Coding Style Guide”.  Or is it vice-versa?  Anyhow, you would be 
well-advised to listen instead.

Score adjusted

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#15599

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

>> If one doesn't know what ?> means, and one is surprised by the fact that
>> what follows after ?> is send to standard output, one should not be
>> programming....
>
> Not knowing what “?>” means is not the point here; I have not even given 
> indication that it would be.  Avoiding error-prone code is.
>

I definitely prefer when the closing tag is left out, as whitespace
included after it can be a huge source of confusion for both newcomers
and users of editors that do not make trailing whitespace very clear.

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

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

#15601

On 7/20/2015 7:45 PM, Thomas 'PointedEars' Lahn wrote:
> Erwin Moller wrote:
>
>> On 7/17/2015 9:24 PM, Thomas 'PointedEars' Lahn wrote:
>>> DRY:
>>>
>>>     $frq = array(
>>>       12 => array(13.4, 17.4, 20.0),
>>>       13 => array(3.5, 6.7, 17.3),
>>>       19 => array(3.1, 194.45, 10.909)
>>>     );
>>>
>>> Since PHP 5.4:
>>>
>>>     $frq = [
>>>       12 => [13.4, 17.4, 20.0],
>>>       13 => [3.5, 6.7, 17.3],
>>>       19 => [3.1, 194.45, 10.909]
>>>     ];
>>>
>>> <http://php.net/manual/en/migration54.new-features.php>
>>
>> What is your point?
>> You have another syntax to create an array?
>
> That, too.
>
>> And the above "improvement" is a poor example of Don't Repeat Yourself,
>> in my humble opinion.
>> DRY is not about slashing out a few $frq in the sourcecode...
>
> Obviously you have not understood DRY.

Let's just say at least one of us have not understood the DRY principle 
here, ok?

> It is about _not_ *repeating*
> yourself in order to make code *less* error-prone and *easier* to maintain.

Exactly.
And that means you avoid defining things in multiple places.

"The DRY principle is stated as “Every piece of knowledge must have a 
single, unambiguous, authoritative representation within a system.”"



"When the DRY principle is applied successfully, a modification of any 
single element of a system does not require a change in other logically 
unrelated elements."
[https://en.wikipedia.org/wiki/Don%27t_repeat_yourself]

Thomas, this is NOT about slashing out a few repeating variable names....
That is CODING STYLE.

I am totally fine with your shorter version, but please don't present it 
as important, let alone as implementing DRY by doing so.


> There is no need to repeat a variable identifier here, and no need to have
> several statements when you can have one.  This is only an example where
> the identifier happens to be short.
>
> Unnecessary repetition is not only time-consuming when reading and writing
> code, but can easily lead to inconsistencies that are even more time-
> consuming to spot and fix.  As for PHP, the statement
>
>    $bar['baz'] = 42;
>
> *creates* the $bar array if it did not exist.  Suppose after refactoring the
> real variable name were $foo; it is possible, and it has happened even to
> the best of us, that in a non-trivial piece of code one will spend *hours*
> searching for the reason why the darn $foo array is empty.  This does not
> happen if you initialize the array once, as I suggested, or merge with
> another array later.

Not convincing.
If one is a sloppy programmer, everything will bite you back eventually.

>
>>>> […]
>>>> echo "<pre>";
>>>           ^^
>>>     echo '<pre>' . print_r($frq, true) . '</pre>';
>>>
>>> <http://php.net/print_r>
>>>
>>> With the Xdebug extension enabled,
>>>
>>>     var_dump($frq);
>>>
>>> will generate the output using a fixed-width font by default, and you
>>> have more control over the output, such as the nesting level.
>>>
>>> <http://xdebug.org/docs/display>
>>
>> ???
>> I try to tell the OP how to inspect his data structure, a worthwhile
>> idea for newcomers, and your extra info added nothing.
>
> It did add *a lot*.  *And* I pointed out a mistake that you made that would
> cause the output of the OP to be displayed with a fixed-width font (in the
> best case) starting at that line.

Oh yes, I forgot to mention: The fact that you spotted the missing / in 
my closing pre tag, is the only real contribution coming from you so far.
Well spotted!


>>>> ?>
>>>
>>> Avoid this in PHP programs unless you are sure that you want what follows
>>> to be sent to the standard output.
>>
>> I don't agree with that attitude.
>
> It is not an attitude, it is a recommendation.  One that is confirmed by
> previous PHP coding standards, and by *the* current PHP Coding Style Guide
> (PSR-2) which extends *the* current PHP Basic Coding Standard (PSR-1), all
> of which I referred to.
>
>> Leaving out ?> at the end is one of the worst ideas PHP ever came up
>> with, and I won't support it.
>
> Explain that to the many people who wondered why their HTTP headers were not
> sent after including a library.

I'll explain to them they should follow PHP 101 first before starting to 
use libraries.
And I'll be glad to explain to authors of libraries that they should use 
?> to end their code.
If they are worthy of developing stuff that is worthwhile to recycle, 
they will be able to use ?> as the ending of their files.

It isn't so hard....

>
>> If one doesn't know what ?> means, and one is surprised by the fact that
>> what follows after ?> is send to standard output, one should not be
>> programming....
>
> Not knowing what “?>” means is not the point here; I have not even given
> indication that it would be.  Avoiding error-prone code is.

We agree on something then.

>
>>> <http://www.php-fig.org/psr/psr-2/> etc.
>>
>> Do you really care for that Coding Style Guide?
>
> I do, and several thousands of other professional PHP developers.
>
>> I don't.
>
> Why should anyone care about your humble opinion?  You are evidentially only
> an amateur when it comes to PHP programming; that is why you do not care
> about “that Coding Style Guide”.  Or is it vice-versa?  Anyhow, you would be
> well-advised to listen instead.
>
> Score adjusted
>

Which score?
Your little red book?
And I have received your "score adjusted" many times, but you seem to be 
unable to simple blacklist me.
Feel free to do so. Your unnecessary pedantic comments on my 
contributions in here annoy me.


Erwin Moller

-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

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

#15602

Erwin Moller wrote:

> On 7/20/2015 7:45 PM, Thomas 'PointedEars' Lahn wrote:
>> Erwin Moller wrote:
>>> And the above "improvement" is a poor example of Don't Repeat Yourself,
>>
>> […] [DRY] is about _not_ *repeating* yourself in order to make code 
>> *less* error-prone and *easier* to maintain.
> 
> Exactly.
> And that means you avoid defining things in multiple places.

And you *are *defining a thing in multiple places.  In three 
lines/statements instead of one.  Which AISB, not only is inefficient but 
carries the risk of inconsistencies, therefore of bugs; of wasted resources, 
including time.
 
>>> I don't.
>>
>> Why should anyone care about your humble opinion?  You are evidentially
>> only an amateur when it comes to PHP programming; that is why you do not
>> care about “that Coding Style Guide”.  Or is it vice-versa?  Anyhow, you 
>> would be well-advised to listen instead.
>>
>> Score adjusted
> 
> Which score?

The score of your entry in the scorefile of of my newsreader.  “Score 
adjusted” is the polite version of “Either get a life or FOAD.”

> Your little red book?

No.

> And I have received your "score adjusted" many times, but you seem to be
> unable to simple blacklist me.

My newsreader supports scorefile entries that expire.  I had not given up 
hope that you may come to your senses eventually.  Until now.

> Feel free to do so. Your unnecessary pedantic comments on my
> contributions in here annoy me.

Then die in ignorance.  I will no longer waste my time with you.

*PLONK*

F'up2 poster

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#15603

On 7/21/2015 1:30 PM, Thomas 'PointedEars' Lahn wrote:
> *PLONK*

About time.
Peace at last!


Regards,
Erwin Moller


-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

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

#15598

On Mon, 20 Jul 2015 16:30:27 +0200, Erwin Moller wrote:

> On 7/17/2015 9:24 PM, Thomas 'PointedEars' Lahn wrote:
>> Erwin Moller wrote:

>>> ?>

>> Avoid this in PHP programs unless you are sure that you want what
>> follows to be sent to the standard output.

> I don't agree with that attitude.
> Leaving out ?> at the end is one of the worst ideas PHP ever came up
> with, and I won't support it.

This is a matter of personal preference. I agree that if you're writing 
php and don't understand what '?>' means, you shouldn't be writing php.

But whether you always terminate code with it or not is down to your 
personal style (unless your employer has a house style). At worst, in a 
file where all output is handled with echo or print, you might add a few 
blank lines at the end.

As far as I can tell, most php "style guides" tend to just be the 
opinions of an opinionated person or group of people. Same with most 
programming style guides out there. Find a style that works for you and 
stick with it. Ignore anyone who tells you that you're doing it wrong, 
they're just an opinionated person to likes to sound important by telling 
others their opinion. Listen to people are willing to explain the real 
benefits to them of their preferred coding style, because they are the 
ones who might have something you can learn, not the ones who just state 
"this is how it must be done".

Personally I try to avoid jumping between php and direct output in files, 
because I find it less confusing to debug, but that's just my preference, 
and I wouldn't dream of telling anyone else they should or shouldn't do 
it my way, but I will explain (see above, I find it less confusing to 
debug) why I do it the way I do it.

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#15600

Denis McMahon wrote:

> On Mon, 20 Jul 2015 16:30:27 +0200, Erwin Moller wrote:
>> On 7/17/2015 9:24 PM, Thomas 'PointedEars' Lahn wrote:
>>> Erwin Moller wrote:
>>>> ?>
>>> 
>>> Avoid this in PHP programs unless you are sure that you want what
>>> follows to be sent to the standard output.
> 
>> I don't agree with that attitude.
>> Leaving out ?> at the end is one of the worst ideas PHP ever came up
>> with, and I won't support it.
> 
> This is a matter of personal preference.

It is insofar that it shows whether you have the preferences of a PHP 
amateur.  There are important implications if you write it in the *wrong* 
place, such as at the *supposed* end of library code, that may not be easy 
to debug.  PHP means “PHP Hypertext Preprocessor” (now).  Whitespace (space, 
tab, newline, etc.) outside of <?…?> that is not obviously visible is made 
*output* in PHP, and once output has been sent, you not only have whitespace 
in the output but also cannot send HTTP headers anymore 
(<http://php.net/header>).

Meaning that files dynamically generated with PHP are sent with the default 
“Content-type: text/html” even if the resource content is not HTML, which 
breaks downloads, generated or proxy-fetched images, compacted resources, 
and so on.  And if the content is HTML, it is very easy to force 
Quirks/Compatibilty Mode because the DOCTYPE declaration may not be on the 
first line anymore.

> I agree that if you're writing php and don't understand what '?>' means, 
> you shouldn't be writing php.

Yes, but that is missing the point here completely.  Again.

> Listen to people are willing to explain the real benefits to them of their 
> preferred coding style, because they are the ones who might have something 
> you can learn, not the ones who just state "this is how it must be done".

If you cared to read, which *again* you did _not_, there *were* explanations 
in my posting, and I did _not_ say that “this is how it must be done” but 
gave well-founded recommendations, now elaborated on here.

> But whether you always terminate code with it or not is down to your
> personal style (unless your employer has a house style).

Again, *nobody* has suggested that you either *always* write it or *always* 
omit it.

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#15588

bobmct write:

> Also, the sprintf %u is to convert the index pointer to an unsigned
> integer to point to each numbered index.

That doesn't seem to make much sense.  Even if the array is built this
way, you're better off to change that.

-- 
Christoph M. Becker

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

#15589

On Tue, 14 Jul 2015 12:12:46 -0400, bobmct wrote:


> $frq = array(array);

> for  ( $X=$_minimum; $X<=$_maximum; $X++) {
> 	$Y = sprintf("%02d",$X);
> 	$Y1 = sprintf("%u",$X);
> 	print <<< EOD <tr bgcolor="$bgcolor">
> 	<td align="center"><img src="pix/balls/$Y.png" alt="$Y" ></td>
> EOD;
> 	for ( $z=0; $z<=7; $z++) {
> 		$Y2 = sprintf("%u",$z);
> 		print <<< EOD <td align="center">$frq[$Y1][$Y2]</td>
> EOD;
> 	}
> }

Should '$frq[$Y1][$Y2]' actually be '{$frq[$Y1][$Y2]}'

I'm not sure if array referencing in heredoc requires {} wrappers round 
the array and keys or not, but I always tend to use it. If it does need 
the {} wrappers, absence of them mean it's trying to convert $frq into a 
string on it's own, rather than a second order sub-element of the multi-
level $frq array!

If that's the case, this may be the cause of your "array to string 
conversion errors".

From:

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

"Heredoc text behaves just like a double-quoted string, without the 
double quotes. This means that quotes in a heredoc do not need to be 
escaped, but the escape codes listed above can still be used. Variables 
are expanded, but the same care must be taken when expressing complex 
variables inside a heredoc as with strings."

and:

The most important feature of double-quoted strings is the fact that 
variable names will be expanded. See string parsing for details. 

and:

If a dollar sign ($) is encountered, the parser will greedily take as 
many tokens as possible to form a valid variable name. Enclose the 
variable name in curly braces to explicitly specify the end of the name. 

But the latter statement isn't neccesarily true, as the following test 
shows. The test code:

<?php

$arr = array( array( 'x' ) );

echo print_r($arr, TRUE);

echo "Test 1: {$arr[0][0]}\n";

echo "Test 2: $arr[0][0]\n";

produces:

Array
(
    [0] => Array
        (
            [0] => x
        )

)
Test 1: x
Test 2: Array[0]

Note that the second print appears to have output '$arr[0]' as 'Array', 
and the following '[0]' as a literal '[0]', where reading the 
documentation suggests that the parser should greedily grab the second 
index as well before trying to resolve the variable!

Expanding the test:

<?php

$arr = array( array( 'x' ) );

echo print_r($arr, TRUE);

echo "Test 1: {$arr[0][0]}\n";

echo "Test 2: $arr[0][0]\n";

echo <<< EOT

Test 3: {$arr[0][0]}

EOT;

echo <<< EOT

Test 4: $arr[0][0]

EOT;

gives:

Array
(
    [0] => Array
        (
            [0] => x
        )

)
Test 1: x
Test 2: Array[0]

Test 3: x

Test 4: Array[0]

Which suggests that heredoc also sees '$arr[0]' and '[0]' as two seperate 
things when they're not wrapped in {}.

However there is no error or warning generated, even if I include 
'error_reporting(-1);' as the first line of code.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [standalone]

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

csiph-web