|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
php-general-digest-help
lists.php.net
Date: Fri Apr 18 2008 - 19:15:31 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
php-general Digest 19 Apr 2008 00:15:31 -0000 Issue 5412
Topics (messages 273223 through 273285):
Re: PHP console script vs C/C++/C#
273223 by: Per Jessen
273228 by: Daniel Kolbo
273232 by: Eric Butera
273233 by: Nathan Nobbe
273236 by: Eric Butera
273237 by: Nick Stinemates
273240 by: Nathan Nobbe
273243 by: Nick Stinemates
273254 by: Nick Stinemates
273258 by: Per Jessen
273265 by: Nathan Nobbe
Re: & performance issues
273224 by: Ford, Mike
need "pop-up" in progress alert
273225 by: Steve Holmes
273229 by: Jason Pruim
273230 by: James Dempster
273231 by: Steve Holmes
273234 by: Eric Butera
273235 by: Eric Butera
273239 by: Steve Holmes
273241 by: Eric Butera
273247 by: Nick Stinemates
273248 by: Eric Butera
273250 by: bruce
273255 by: Nick Stinemates
273277 by: Steve Holmes
Apache2 and cli return diferent values on glob function
273226 by: Luciano A. Andrade
Re: loop inside a loop
273227 by: Alan Willsher
Re: PHP5 and the DOM model
273238 by: Nick Stinemates
273245 by: Nathan Nobbe
273253 by: Nick Stinemates
273256 by: Jim Lucas
273257 by: Nick Stinemates
273261 by: Nathan Nobbe
273262 by: Nathan Nobbe
273263 by: Jim Lucas
273267 by: Robert Cummings
273268 by: Nathan Nobbe
273270 by: Nathan Nobbe
273275 by: Robert Cummings
273279 by: Nathan Nobbe
273282 by: Robert Cummings
273284 by: Nathan Nobbe
Re: Hack question
273242 by: Al
273244 by: Eric Butera
273246 by: Al
273249 by: Eric Butera
273251 by: Daniel Brown
273252 by: Jim Lucas
273259 by: Eric Butera
273260 by: Eric Butera
273264 by: Al
273266 by: Jim Lucas
273269 by: Eric Butera
273271 by: Jim Lucas
273272 by: Daniel Brown
273273 by: Daniel Brown
273274 by: Eric Butera
273276 by: Jim Lucas
273278 by: Eric Butera
273280 by: Jason Pruim
273281 by: Jim Lucas
Quick Guide to Building On Windows
273283 by: Andy
OS X 10.5.2
273285 by: Lee Perry
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscribelists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscribelists.php.net
To post to the list, e-mail:
php-generallists.php.net
----------------------------------------------------------------------
attached mail follows:
Daniel Kolbo wrote:
> If I wrote the console application in a c language (and compiled)
> would one expect to see any improvements in performance? If so, how
> much improvement could one expect (in general)?
You haven't given us much to work with, so it's a wild guess, but I
think you'd probably be able to cut your runtime by half or more.
I recently wrote a multi-threaded postgrey daemon in C as the original
postgrey (written in perl) was taking up far too much CPU. With high
concurrent load (2000 clients or more), the original postgrey would
easily take 70-80% of the CPU, and I would see lots of timeouts.
My new daemon takes up less than 10% CPU under the same load and I've
not seen a timeout yet.
/Per Jessen, Zürich
attached mail follows:
Struan Donald wrote:
> * at 17/04 16:30 -0500 Daniel Kolbo said:
>
>> Hello,
>>
>> I am writing a PHP script for a local application (not web/html
>> based). My script is taking a longer time to execute than I want. The
>> source code is a few thousand lines, so I will spare you all this
>> level of detail.
>>
>> I prefer to write in PHP because that is what I know best. However, I
>> do not think there is anything inherent with my script that requires PHP
>> over C/C++/C#.
>>
>
> I think this points to an answer. If you're not too familiar with one
> of the compiled languages then producing code that runs faster than
> your current PHP implementation is a tall order. PHP, like most
> scripting languages, is compiled into an internal format as a first
> step and it's this that's then run. A lot of effort has gone into
> making this pretty fast and by deciding to rewrite in a compiled
> language you are betting that the C code, or whatever, you write will
> be faster. Given the effort I imagine translating a few thousand
> lines of PHP into one of the languages you name is likely to be
> significant you'd want to be sure of winning that bet.
>
>
>> If I wrote the console application in a c language (and compiled) would
>> one expect to see any improvements in performance? If so, how much
>> improvement could one expect (in general)?
>>
>
> How long will it take you to convert the program? How much more time
> will you spend on support and bugfixing?
>
>
>> I assume because php is not compiled that this real time interpretation
>> of the script by the zend engine must take some time. This is why I am
>> thinking about rewriting my whole script in a C language. But before I
>> begin that ordeal, i wanted to ask the community for their opinions. If
>> you think using a c language would suit me well, what language would you
>> recommend?
>>
>
> It's not real time interpretation. It's a one time parse and compile
> when the script starts and then it runs the internal bytecode. If you
> have APC, or some other sort of caching mechanism installed then part
> of the speed up comes from caching the bytecode and saving on the
> initial parse and compile phase.
>
> As to what language then if you want to go ahead and do this you
> should pick the one you know best. If you don't know any of them that
> well then I really think that your time would be better spent on
> optimising the existing PHP code first. Are you sure it's running as
> fast as it can? Do you know where it's slow?
>
> Rewriting it in another language really is the 50 pound lump hammer
> solution to the problem if you've not tried anything else to speed it
> up.
>
>
>> My google and mail archive searching for this yielded mainly PHP for web
>> apps, so I am asking all of you.
>>
>> My main question is, how much of an improvement in performance will one
>> see by using a compiled version of an application versus using a
>> scripted version of an application?
>>
>> I looked at PHP's bcompiler, but the documentation is minimal so I am
>> hesitant to dig much deeper into that, unless someone strongly suggests
>> otherwise.
>>
>
> A quick look at the docs tells me that all that bcompiler will do is
> save you the initial parse and compile phase and not speed up the
> execution of the code.
>
> The one thing you don't say is exactly how long is too long? Is it
> hours or minutes? If it's seconds then consider, as someone has
> suggested elsewhere in the thread, looking at APC as that should cut
> down the start up time of the script.
>
> HTH and apologies if none of this is news to you.
>
> Struan
>
>
You are correct in that I want to be pretty sure I win the bet, before
translating all the code. The code really isn't that complicated, so I
think I am capable of translating it. Just a bunch of pretty small
functions. The code is a simulation-model type of program, so the
bottleneck in the code is the "looping". I know the exact function that
takes up 86% of the time. I have tried to rewrite this function from
different approaches. The bottom line is "work" needs to be done, and a
lot of it. I really can't think of any other ways to improve the
"logic" of the code at this time. Perhaps there are different methods I
could be using to speed up execution. Again, I think the source of the
issue is looping.
Here is the function that takes 86% of the time...This function is
called 500,000,000 times with different parameters ($arr and $arr2)
(which I cannot predict their values just their size).
========= C O D E ===S T AR T ========
//this function is essentially a search and remove function for a nested
array
foreach ($arr as $key => $value) {
//count($arr) == 3
foreach ($value as $key2 => $value2) {
//0<=count($value) <=1000
foreach($arr2 as $value3) {
//count($arr2) == 2
if (in_array($value3, $value2)) {
unset($arr[$key][$key2]);
break;
}
}
}
========= C O D E ===E N D ========
So essentially 3 foreach nested, invoking in_array(), and unset().
I rewrote the above code by making $arr a 1 dimensional array and
'storing' the nested key values as a string index with delimiter, so
that I could unset the original nested $arr by exploding this
index...i'll just show the code.
========= C O D E 2 ==== S T A R T=======
//first i prepare $arr
function CompressRay($some_nested_ray, $delimiter = "|") {
//not really compression just flattens the array
//returns an array of string of key_strings and the final value
$answer_ray = array();
foreach ($some_nested_ray as $key => $value) {
$key_string = (string)$key.$delimiter;
if (is_array($value)) {
$compressed_sub_ray = CompressRay($value, $delimiter);
//echo "Compressed Sub is \n";
//print_r($compressed_sub_ray);
foreach ($compressed_sub_ray as $sub_key_string =>
$final_value) {
$answer_ray[$key_string.$sub_key_string] = $final_value;
}
}else {
$answer_ray[substr($key_string,0,-1)] = $value;
}
}
return $answer_ray;
}
$arr['compressed'] = CompressRay($arr);
//this part happens quickly, no worries so far
//then i call the below procedure oh, about 500,000,000 times
foreach ($arr2 as $value3) {
$key_strings = array_keys($arr['compressed'], $value3);
foreach ($key_strings as $key_string) {
$key_sequence = explode("|",$key_string);
unset($all_vs_holes[$key_sequence[0]][$key_sequence[1]]);
$upto_hole = substr($key_string,0,-2);
unset($arr['compressed'][$upto_hole."|0"]);
//to keep the compressed archive accurate
unset($arr['compressed'][$upto_hole."|1"]);
//to keep the compressed archive accurate
}
}
========= C O D E 2 ==== E N D=======
to my surprise code2 was actually slower, twice as slow. I started
thinking maybe by passing the relatively large $arr by value 500 million
times was taking up a lot of time...but some bench mark testing I did,
actually didn't show that much improvement (if any) by passing a large
array by reference. This seemed counterintuitive to me, and b/c i would
have to make a duplicate copy of $arr if i did pass by reference it
seemed like little gain would come of it.
Like I said, some work has to be done...these iterations have to be
performed.
By long time, i am speaking about days. I am not entirely convinced
that by making minor optimization changes to the particular syntax or
methods invoked will yield any order of magnitude difference. The order
of magnitude difference I need, (i think) must come from changing actual
logic of the code - which is difficult to do in an almost simple
iteration procedure. An analogy, it doesn't matter if the code is lance
armstrong or some big NFL lineman, they are running 100,000 back to back
marathons and are going to get tired and start crawling either way.
This is why i feel i am up against a brick wall, and must start looking
for a language that runs a bit faster. Some preliminary looping of 1
billion iterations in C++ vs. PHP has yielded substantial
difference...like 10^4 magnitude difference in time. This makes me feel
like my bet is justified in translating the code.
I am going to miss php ;(
As I know the bottleneck is in the actual execution of the code, the APC
and bcompiler won't offer much gain, thanks for the consideration and
looking into those.
At this point some of you may encourage me to go to C++ so i stop with
this question...but I'd like to hear if you all agree that perhaps it is
time to pull out the 50 lbp lump hammer?
Thanks,
Dan K
attached mail follows:
On Fri, Apr 18, 2008 at 10:53 AM, Daniel Kolbo <kolb0057umn.edu> wrote:
>
>
>
> Struan Donald wrote:
>
> > * at 17/04 16:30 -0500 Daniel Kolbo said:
> >
> >
> > > Hello,
> > >
> > > I am writing a PHP script for a local application (not web/html
> > > based). My script is taking a longer time to execute than I want. The
> > > source code is a few thousand lines, so I will spare you all this
> > > level of detail.
> > >
> > > I prefer to write in PHP because that is what I know best. However, I
> do not think there is anything inherent with my script that requires PHP
> over C/C++/C#.
> > >
> > >
> >
> > I think this points to an answer. If you're not too familiar with one
> > of the compiled languages then producing code that runs faster than
> > your current PHP implementation is a tall order. PHP, like most
> > scripting languages, is compiled into an internal format as a first
> > step and it's this that's then run. A lot of effort has gone into
> > making this pretty fast and by deciding to rewrite in a compiled
> > language you are betting that the C code, or whatever, you write will
> > be faster. Given the effort I imagine translating a few thousand
> > lines of PHP into one of the languages you name is likely to be
> > significant you'd want to be sure of winning that bet.
> >
> >
> >
> > > If I wrote the console application in a c language (and compiled) would
> one expect to see any improvements in performance? If so, how much
> improvement could one expect (in general)?
> > >
> > >
> >
> > How long will it take you to convert the program? How much more time
> > will you spend on support and bugfixing?
> >
> >
> >
> > > I assume because php is not compiled that this real time interpretation
> of the script by the zend engine must take some time. This is why I am
> thinking about rewriting my whole script in a C language. But before I
> begin that ordeal, i wanted to ask the community for their opinions. If you
> think using a c language would suit me well, what language would you
> recommend?
> > >
> > >
> >
> > It's not real time interpretation. It's a one time parse and compile
> > when the script starts and then it runs the internal bytecode. If you
> > have APC, or some other sort of caching mechanism installed then part
> > of the speed up comes from caching the bytecode and saving on the
> > initial parse and compile phase.
> >
> > As to what language then if you want to go ahead and do this you
> > should pick the one you know best. If you don't know any of them that
> > well then I really think that your time would be better spent on
> > optimising the existing PHP code first. Are you sure it's running as
> > fast as it can? Do you know where it's slow?
> >
> > Rewriting it in another language really is the 50 pound lump hammer
> > solution to the problem if you've not tried anything else to speed it
> > up.
> >
> >
> >
> > > My google and mail archive searching for this yielded mainly PHP for web
> apps, so I am asking all of you.
> > >
> > > My main question is, how much of an improvement in performance will one
> see by using a compiled version of an application versus using a scripted
> version of an application?
> > >
> > > I looked at PHP's bcompiler, but the documentation is minimal so I am
> hesitant to dig much deeper into that, unless someone strongly suggests
> otherwise.
> > >
> > >
> >
> > A quick look at the docs tells me that all that bcompiler will do is
> > save you the initial parse and compile phase and not speed up the
> > execution of the code.
> >
> > The one thing you don't say is exactly how long is too long? Is it
> > hours or minutes? If it's seconds then consider, as someone has
> > suggested elsewhere in the thread, looking at APC as that should cut
> > down the start up time of the script.
> >
> > HTH and apologies if none of this is news to you.
> >
> > Struan
> >
> >
> >
>
> You are correct in that I want to be pretty sure I win the bet, before
> translating all the code. The code really isn't that complicated, so I
> think I am capable of translating it. Just a bunch of pretty small
> functions. The code is a simulation-model type of program, so the
> bottleneck in the code is the "looping". I know the exact function that
> takes up 86% of the time. I have tried to rewrite this function from
> different approaches. The bottom line is "work" needs to be done, and a lot
> of it. I really can't think of any other ways to improve the "logic" of the
> code at this time. Perhaps there are different methods I could be using to
> speed up execution. Again, I think the source of the issue is looping.
>
> Here is the function that takes 86% of the time...This function is called
> 500,000,000 times with different parameters ($arr and $arr2) (which I cannot
> predict their values just their size).
>
> ========= C O D E ===S T AR T ========
> //this function is essentially a search and remove function for a nested
> array
>
> foreach ($arr as $key => $value) {
> //count($arr) == 3
> foreach ($value as $key2 => $value2) {
> //0<=count($value) <=1000
> foreach($arr2 as $value3) {
> //count($arr2) == 2
> if (in_array($value3, $value2)) {
> unset($arr[$key][$key2]);
> break;
> }
> }
> }
>
> ========= C O D E ===E N D ========
>
> So essentially 3 foreach nested, invoking in_array(), and unset().
> I rewrote the above code by making $arr a 1 dimensional array and 'storing'
> the nested key values as a string index with delimiter, so that I could
> unset the original nested $arr by exploding this index...i'll just show the
> code.
>
> ========= C O D E 2 ==== S T A R T=======
> //first i prepare $arr
>
> function CompressRay($some_nested_ray, $delimiter = "|") {
> //not really compression just flattens the array
> //returns an array of string of key_strings and the final value
> $answer_ray = array();
> foreach ($some_nested_ray as $key => $value) {
> $key_string = (string)$key.$delimiter;
> if (is_array($value)) {
> $compressed_sub_ray = CompressRay($value, $delimiter);
> //echo "Compressed Sub is \n";
> //print_r($compressed_sub_ray);
> foreach ($compressed_sub_ray as $sub_key_string => $final_value)
> {
> $answer_ray[$key_string.$sub_key_string] = $final_value;
> }
> }else {
> $answer_ray[substr($key_string,0,-1)] = $value;
> }
> }
> return $answer_ray;
> }
>
> $arr['compressed'] = CompressRay($arr);
> //this part happens quickly, no worries so far
>
> //then i call the below procedure oh, about 500,000,000 times
>
> foreach ($arr2 as $value3) {
> $key_strings = array_keys($arr['compressed'], $value3);
> foreach ($key_strings as $key_string) {
> $key_sequence = explode("|",$key_string);
> unset($all_vs_holes[$key_sequence[0]][$key_sequence[1]]);
> $upto_hole = substr($key_string,0,-2);
> unset($arr['compressed'][$upto_hole."|0"]);
> //to keep the compressed archive accurate
> unset($arr['compressed'][$upto_hole."|1"]);
> //to keep the compressed archive accurate
> }
> }
>
> ========= C O D E 2 ==== E N D=======
>
> to my surprise code2 was actually slower, twice as slow. I started
> thinking maybe by passing the relatively large $arr by value 500 million
> times was taking up a lot of time...but some bench mark testing I did,
> actually didn't show that much improvement (if any) by passing a large array
> by reference. This seemed counterintuitive to me, and b/c i would have to
> make a duplicate copy of $arr if i did pass by reference it seemed like
> little gain would come of it.
>
> Like I said, some work has to be done...these iterations have to be
> performed.
> By long time, i am speaking about days. I am not entirely convinced that
> by making minor optimization changes to the particular syntax or methods
> invoked will yield any order of magnitude difference. The order of
> magnitude difference I need, (i think) must come from changing actual logic
> of the code - which is difficult to do in an almost simple iteration
> procedure. An analogy, it doesn't matter if the code is lance armstrong or
> some big NFL lineman, they are running 100,000 back to back marathons and
> are going to get tired and start crawling either way.
>
> This is why i feel i am up against a brick wall, and must start looking for
> a language that runs a bit faster. Some preliminary looping of 1 billion
> iterations in C++ vs. PHP has yielded substantial difference...like 10^4
> magnitude difference in time. This makes me feel like my bet is justified
> in translating the code.
>
> I am going to miss php ;(
>
> As I know the bottleneck is in the actual execution of the code, the APC
> and bcompiler won't offer much gain, thanks for the consideration and
> looking into those.
>
> At this point some of you may encourage me to go to C++ so i stop with this
> question...but I'd like to hear if you all agree that perhaps it is time to
> pull out the 50 lbp lump hammer?
>
> Thanks,
> Dan K
>
>
Like I said before, since you know that most of your time is in a
specific part of your script, just move that function into a custom
extension written in c/c++.
http://talks.php.net/show/extending-php-apachecon2003/0
attached mail follows:
On Fri, Apr 18, 2008 at 9:33 AM, Eric Butera <eric.buteragmail.com> wrote:
> Like I said before, since you know that most of your time is in a
> specific part of your script, just move that function into a custom
> extension written in c/c++.
>
> http://talks.php.net/show/extending-php-apachecon2003/0
its likely easier, and probly not much slower to build it as a standalone
cli program and invoke it via shell_exec() or backticks.
-nathan
attached mail follows:
On Fri, Apr 18, 2008 at 11:36 AM, Nathan Nobbe <quickshiftingmail.com> wrote:
> On Fri, Apr 18, 2008 at 9:33 AM, Eric Butera <eric.buteragmail.com> wrote:
>
> > Like I said before, since you know that most of your time is in a
> > specific part of your script, just move that function into a custom
> > extension written in c/c++.
> >
> > http://talks.php.net/show/extending-php-apachecon2003/0
>
> its likely easier, and probly not much slower to build it as a standalone
> cli program and invoke it via shell_exec() or backticks.
>
> -nathan
>
Or that ;D
attached mail follows:
On Thu, Apr 17, 2008 at 04:30:00PM -0500, Daniel Kolbo wrote:
> Hello,
>
> I am writing a PHP script for a local application (not web/html based). My
> script is taking a longer time to execute than I want. The source code is
> a few thousand lines, so I will spare you all this level of detail.
>
> I prefer to write in PHP because that is what I know best. However, I do
> not think there is anything inherent with my script that requires PHP over
> C/C++/C#.
What makes you feel this way?
>
> If I wrote the console application in a c language (and compiled) would one
> expect to see any improvements in performance? If so, how much improvement
> could one expect (in general)?
Depends. Shitty algorithms are shitty, regardless of language
implementation.
>
> I assume because php is not compiled that this real time interpretation of
> the script by the zend engine must take some time. This is why I am
> thinking about rewriting my whole script in a C language. But before I
> begin that ordeal, i wanted to ask the community for their opinions. If
> you think using a c language would suit me well, what language would you
> recommend?
Depends on the task, but based on this e-mail I have a feeling you'll
encounter the same problem.
--
Nick Stinemates (nickstinemates.org)
http://nick.stinemates.org
attached mail follows:
On Thu, Apr 17, 2008 at 5:46 PM, Nick Stinemates <nickstinemates.org>
wrote:
> > If I wrote the console application in a c language (and compiled) would
> one
> > expect to see any improvements in performance? If so, how much
> improvement
> > could one expect (in general)?
>
> Depends. Shitty algorithms are shitty, regardless of language
> implementation.
>
right, but there shitiness is relative to the performance of the underlying
language. according to the great computer language shootout, if OP
implemented in C / C++ he could expect something along the lines an increase
in performace ~ 23x greater than the current php implementation. obviously
there are many factors here; and well i dont think weve even found out what
the script is doing :O. if its having to deal w/ lots of external calls for
example to a database or remote system, those will still be major
bottlenecks. but as far as processing the data and running though logic,
yes there is much performance to be had by compiling.
-nathan
attached mail follows:
>
> ========= C O D E ===S T AR T ========
> //this function is essentially a search and remove function for a nested
> array
>
> foreach ($arr as $key => $value) {
> //count($arr) == 3
> foreach ($value as $key2 => $value2) {
> //0<=count($value) <=1000
> foreach($arr2 as $value3) {
> //count($arr2) == 2
> if (in_array($value3, $value2)) {
> unset($arr[$key][$key2]);
> break;
> }
> }
> }
>
> ========= C O D E ===E N D ========
>
I can see why you would like to refactor this code to C, but, the
problem comes from looping through 3 sets of arrays instead of using
small data models.
If you use arrays in C/++ you'll be no better off. This type of
operation is expensive on large numbers of data. You may have some great
compiler optimization in C, though.
How big of a dataset are we talking about in these 3 arrays?
> So essentially 3 foreach nested, invoking in_array(), and unset().
> I rewrote the above code by making $arr a 1 dimensional array and 'storing'
> the nested key values as a string index with delimiter, so that I could
> unset the original nested $arr by exploding this index...i'll just show the
> code.
>
> ========= C O D E 2 ==== S T A R T=======
> //first i prepare $arr
>
> function CompressRay($some_nested_ray, $delimiter = "|") {
> //not really compression just flattens the array
> //returns an array of string of key_strings and the final value
> $answer_ray = array();
> foreach ($some_nested_ray as $key => $value) {
> $key_string = (string)$key.$delimiter;
> if (is_array($value)) {
> $compressed_sub_ray = CompressRay($value, $delimiter);
> //echo "Compressed Sub is \n";
> //print_r($compressed_sub_ray);
> foreach ($compressed_sub_ray as $sub_key_string => $final_value)
> {
> $answer_ray[$key_string.$sub_key_string] = $final_value;
> }
> }else {
> $answer_ray[substr($key_string,0,-1)] = $value;
> }
> }
> return $answer_ray;
> }
>
> $arr['compressed'] = CompressRay($arr);
> //this part happens quickly, no worries so far
>
> //then i call the below procedure oh, about 500,000,000 times
>
> foreach ($arr2 as $value3) {
> $key_strings = array_keys($arr['compressed'], $value3);
> foreach ($key_strings as $key_string) {
> $key_sequence = explode("|",$key_string);
> unset($all_vs_holes[$key_sequence[0]][$key_sequence[1]]);
> $upto_hole = substr($key_string,0,-2);
> unset($arr['compressed'][$upto_hole."|0"]);
> //to keep the compressed archive accurate
> unset($arr['compressed'][$upto_hole."|1"]);
> //to keep the compressed archive accurate
> }
> }
>
> ========= C O D E 2 ==== E N D=======
>
> to my surprise code2 was actually slower, twice as slow. I started
> thinking maybe by passing the relatively large $arr by value 500 million
> times was taking up a lot of time...but some bench mark testing I did,
> actually didn't show that much improvement (if any) by passing a large
> array by reference. This seemed counterintuitive to me, and b/c i would
> have to make a duplicate copy of $arr if i did pass by reference it seemed
> like little gain would come of it.
Unfortunately passing be reference is not the same as passing a pointer.
:(
>
> Like I said, some work has to be done...these iterations have to be
> performed.
> By long time, i am speaking about days. I am not entirely convinced that
> by making minor optimization changes to the particular syntax or methods
> invoked will yield any order of magnitude difference. The order of
> magnitude difference I need, (i think) must come from changing actual logic
> of the code - which is difficult to do in an almost simple iteration
> procedure. An analogy, it doesn't matter if the code is lance armstrong or
> some big NFL lineman, they are running 100,000 back to back marathons and
> are going to get tired and start crawling either way.
>
> This is why i feel i am up against a brick wall, and must start looking for
> a language that runs a bit faster. Some preliminary looping of 1 billion
> iterations in C++ vs. PHP has yielded substantial difference...like 10^4
> magnitude difference in time. This makes me feel like my bet is justified
> in translating the code.
>
> I am going to miss php ;(
>
> As I know the bottleneck is in the actual execution of the code, the APC
> and bcompiler won't offer much gain, thanks for the consideration and
> looking into those.
>
> At this point some of you may encourage me to go to C++ so i stop with this
> question...but I'd like to hear if you all agree that perhaps it is time to
> pull out the 50 lbp lump hammer?
Still disagree. I have a feeling that if you explained the domain a bit
more, what the input for these functions would be, we could come up with
a solution which would be sufficiently faster.
While you may see some moderate gains going to C, I think the basework
could still use some optimization.
>
> Thanks,
> Dan K
>
--
Nick Stinemates (nickstinemates.org)
http://nick.stinemates.org
attached mail follows:
On Fri, Apr 18, 2008 at 09:58:14AM -0600, Nathan Nobbe wrote:
> On Thu, Apr 17, 2008 at 5:46 PM, Nick Stinemates <nickstinemates.org>
> wrote:
>
> > > If I wrote the console application in a c language (and compiled) would
> > one
> > > expect to see any improvements in performance? If so, how much
> > improvement
> > > could one expect (in general)?
> >
> > Depends. Shitty algorithms are shitty, regardless of language
> > implementation.
> >
>
>
> right, but there shitiness is relative to the performance of the underlying
> language. according to the great computer language shootout, if OP
> implemented in C / C++ he could expect something along the lines an increase
> in performace ~ 23x greater than the current php implementation. obviously
> there are many factors here; and well i dont think weve even found out what
> the script is doing :O. if its having to deal w/ lots of external calls for
> example to a database or remote system, those will still be major
> bottlenecks. but as far as processing the data and running though logic,
> yes there is much performance to be had by compiling.
>
> -nathan
I don't think there was a single place where I said PHP was faster than
C, nor did I imply it.
The point I was making is simple, if you have a shitty algorithm (which
is the case for our op) expect shitty performance.
There's no doubt you will gain performance moving to C, but, if properly
designed, you have a performance that is acceptable, then why go to that
level?
--
Nick Stinemates (nickstinemates.org)
http://nick.stinemates.org
attached mail follows:
Nick Stinemates wrote:
> The point I was making is simple, if you have a shitty algorithm
> (which is the case for our op) expect shitty performance.
Agree completely, that's the case in a nutshell.
> There's no doubt you will gain performance moving to C, but, if
> properly designed, you have a performance that is acceptable, then why
> go to that level?
That's a different issue - whether you chose to write a script or a
program, is all about intended use, speed of development, expected
lifetime, maintainability, ease of development etc etc. If the OPs
script was only meant to run once or twice a year, it probably wouldn't
matter if it ran or month or two.
Personally, I rewrite in C when my PHP (or other script language) script
exceeds a thousand lines.
/Per Jessen, Zürich
attached mail follows:
On Fri, Apr 18, 2008 at 11:25 AM, Nick Stinemates <nickstinemates.org>
wrote:
> I don't think there was a single place where I said PHP was faster than
> C, nor did I imply it.
>
> > Depends. Shitty algorithms are shitty, regardless of language
> > implementation.
implies that the same algorithm in different languages will not perform
differently. thats innacurate. the same algorithm w/o external
dependencies, such as db calls, or calls to remote systems will run faster
in java / c / c++ and others than it will in php.
The point I was making is simple, if you have a shitty algorithm (which
> is the case for our op) expect shitty performance.
>
right, and i agree with that, but its a different point. if op moved the
same shitty algorithm to c it would be faster.
> There's no doubt you will gain performance moving to C, but, if properly
> designed, you have a performance that is acceptable, then why go to that
> level?
obviously, it makes perfect sense to clean up php code (esp if its written
poorly) prior to porting to a low-level language. i am in total agreement
with you there. however, the point i was making was, if the same crap was
ported to a compiled language, it would be faster (barring external calls
that for example go over the network [which even then it would likely still
be a little faster]).
-nathan
attached mail follows:
On 17 April 2008 11:57, Bojan Tesanovic advised:
> in PHP5 by default Objects are passed by reference
Please stop repeating this -- erm -- inexactitude.
In PHP5, objects are passed around by their handle, *not* as a
reference. Most of the time, this has the same effect, as you are
addressing the same object either way. However, the behaviour of a
copied object handle is not the same as a reference. In fact, when you
create a reference to an object, what you're actually getting is a
reference to the object's handle!
To prove this, try running the test code below -- the object handling
will not, I assure you, behave as though you were passing a reference
around by default, but is directly comparable to the following string
example:
<?php
class test {
public $me;
}
$t = new test;
$t->me = 'Original';
$copy_t = $t;
$ref_t = &$t;
$copy_t = new test;
$copy_t->me = 'Altered Copy';
echo <<<RESULT1
Original: $t->me<br />
Copy: $copy_t->me<br />
Reference: $ref_t->me<br />
RESULT1;
$ref_t = new test;
$ref_t->me = 'Altered Reference';
echo <<<RESULT2
<br />
Original: $t->me<br />
Copy: $copy_t->me<br />
Reference: $ref_t->me<br />
RESULT2;
$s = 'String';
$copy_s = $s;
$ref_s = &$s;
$copy_s = 'String Copy';
echo <<<RESULT3
<br />
Original: $s<br />
Copy: $copy_s<br />
Reference: $ref_s<br />
RESULT3;
$ref_s = 'String Reference';
echo <<<RESULT4
<br />
Original: $s<br />
Copy: $copy_s<br />
Reference: $ref_s<br />
RESULT4;
?>
Cheers!
--
Mike Ford, Electronic Information Services Adviser,
JG125, The Headingley Library,
James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: m.fordleedsmet.ac.uk
Tel: +44 113 812 4730 Fax: +44 113 812 3211
To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm
attached mail follows:
Greetings, I'm relatively new to PHP and I've been lurking for a while on
the list, but now I need a pointer or two.
I have an application which has one function that does a lengthy process
(installing a piece of software) and I don't want the user to panic thinking
nothing is going on. So I want to put up a 'working' box or a progress bar.
I have no idea how to do that. I haven't dipped my toes into pear yet. I
don't even know how to install or use a pear module. If there is something
available that doesn't require pear knowledge so much the better, I guess,
but if this is the straw that gets me into pear, so be it.
So if someone could point me in the right direction I'd really appreciate
it.
Thanks,
Steve Holmes
Purdue University
attached mail follows:
On Apr 18, 2008, at 10:42 AM, Steve Holmes wrote:
> Greetings, I'm relatively new to PHP and I've been lurking for a
> while on
> the list, but now I need a pointer or two.
> I have an application which has one function that does a lengthy
> process
> (installing a piece of software) and I don't want the user to panic
> thinking
> nothing is going on. So I want to put up a 'working' box or a
> progress bar.
> I have no idea how to do that. I haven't dipped my toes into pear
> yet. I
> don't even know how to install or use a pear module. If there is
> something
> available that doesn't require pear knowledge so much the better, I
> guess,
> but if this is the straw that gets me into pear, so be it.
> So if someone could point me in the right direction I'd really
> appreciate
> it.
Hi Steve,
From my understanding of how PHP works and from reading the archives
of this list, and asking quite a few questions my self.. You can't do
a progress bar in PHP since by the time it gets to the browser, PHP is
done doing what it does. I don't know about pear, but I know lots of
people have used AJAX progress bars to tell the user what's going on.
Hopefully someone can fill in the blanks for you... Just thought I
would share my knowledge a little bit :)
--
Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424-9337
www.raoset.com
japruimraoset.com
attached mail follows:
As a suggestion you could store a progress of the function in the session
and make regular calls via ajax back to the server for the progress.
--
/James
On Fri, Apr 18, 2008 at 3:42 PM, Steve Holmes <sholmes42mac.com> wrote:
> Greetings, I'm relatively new to PHP and I've been lurking for a while on
> the list, but now I need a pointer or two.
> I have an application which has one function that does a lengthy process
> (installing a piece of software) and I don't want the user to panic
> thinking
> nothing is going on. So I want to put up a 'working' box or a progress
> bar.
> I have no idea how to do that. I haven't dipped my toes into pear yet. I
> don't even know how to install or use a pear module. If there is something
> available that doesn't require pear knowledge so much the better, I guess,
> but if this is the straw that gets me into pear, so be it.
> So if someone could point me in the right direction I'd really appreciate
> it.
>
> Thanks,
> Steve Holmes
> Purdue University
>
attached mail follows:
Thanks (to both). Ajax is yet another thing I don't know anything about.
:-). Time to do some studyin' up I guess.If there are any canned ajax
solutions, I'd like to hear about them.
Steve.
On Fri, Apr 18, 2008 at 11:04 AM, James Dempster <letssurfgmail.com> wrote:
> As a suggestion you could store a progress of the function in the session
> and make regular calls via ajax back to the server for the progress.
>
> --
> /James
>
>
> On Fri, Apr 18, 2008 at 3:42 PM, Steve Holmes <sholmes42mac.com> wrote:
>
> > Greetings, I'm relatively new to PHP and I've been lurking for a while
> > on
> > the list, but now I need a pointer or two.
> > I have an application which has one function that does a lengthy process
> > (installing a piece of software) and I don't want the user to panic
> > thinking
> > nothing is going on. So I want to put up a 'working' box or a progress
> > bar.
> > I have no idea how to do that. I haven't dipped my toes into pear yet. I
> > don't even know how to install or use a pear module. If there is
> > something
> > available that doesn't require pear knowledge so much the better, I
> > guess,
> > but if this is the straw that gets me into pear, so be it.
> > So if someone could point me in the right direction I'd really
> > appreciate
> > it.
> >
> > Thanks,
> > Steve Holmes
> > Purdue University
> >
>
>
--
There is no greater gift to an insecure leader that quite matches a vague
enemy who can be used to whip up fear and hatred among the population.
-Paul Rusesabagina, humanitarian (b. 1954)
Human beings are perhaps never more frightening than when they are
convinced beyond doubt that they are right. -Laurens van der Post, explorer
and writer (1906-1996)
attached mail follows:
On Fri, Apr 18, 2008 at 10:42 AM, Steve Holmes <sholmes42mac.com> wrote:
> Greetings, I'm relatively new to PHP and I've been lurking for a while on
> the list, but now I need a pointer or two.
> I have an application which has one function that does a lengthy process
> (installing a piece of software) and I don't want the user to panic thinking
> nothing is going on. So I want to put up a 'working' box or a progress bar.
> I have no idea how to do that. I haven't dipped my toes into pear yet. I
> don't even know how to install or use a pear module. If there is something
> available that doesn't require pear knowledge so much the better, I guess,
> but if this is the straw that gets me into pear, so be it.
> So if someone could point me in the right direction I'd really appreciate
> it.
>
> Thanks,
> Steve Holmes
> Purdue University
>
It might be a better idea to have this installation happen via some
other means such as a cron job that isn't influenced by the browser.
Then just keep refreshing the page or doing an ajax poll until the job
has returned success. Internet connections get dropped, people hit
refresh, or whatever and that shouldn't break what is going on (in an
ideal world ;)).
If you can't figure that out at least put in an ignore_user_abort to
prevent the user from hitting stop and messing up the installation
process. Just make sure to create some way of knowing that an
installation has been started and check a session value/flat file to
see if the installation is still going in case the user does request
the page again. Once everything is done make sure your script unsets
the session variable/flat file to know you can proceed to the next
step.
Good luck!
attached mail follows:
On Fri, Apr 18, 2008 at 11:31 AM, Steve Holmes <sholmes42mac.com> wrote:
> If there are any canned ajax solutions, I'd like to hear about them.
http://developer.yahoo.com/yui/connection/
attached mail follows:
On Fri, Apr 18, 2008 at 11:39 AM, Eric Butera <eric.buteragmail.com> wrote:
> On Fri, Apr 18, 2008 at 10:42 AM, Steve Holmes <sholmes42mac.com> wrote:
> > Greetings, I'm relatively new to PHP and I've been lurking for a while
> on
> > the list, but now I need a pointer or two.
> > I have an application which has one function that does a lengthy
> process
> > (installing a piece of software) and I don't want the user to panic
> thinking
> > nothing is going on. So I want to put up a 'working' box or a progress
> bar.
> > I have no idea how to do that. I haven't dipped my toes into pear yet.
> I
> > don't even know how to install or use a pear module. If there is
> something
> > available that doesn't require pear knowledge so much the better, I
> guess,
> > but if this is the straw that gets me into pear, so be it.
> > So if someone could point me in the right direction I'd really
> appreciate
> > it.
> >
> > Thanks,
> > Steve Holmes
> > Purdue University
> >
>
> It might be a better idea to have this installation happen via some
> other means such as a cron job that isn't influenced by the browser.
> Then just keep refreshing the page or doing an ajax poll until the job
> has returned success. Internet connections get dropped, people hit
> refresh, or whatever and that shouldn't break what is going on (in an
> ideal world ;)).
>
Thanks for the suggestion, but I'm pretty far along in this project and the
idea is that the software install happens on demand. What we are trying to
do is get the student/faculty population (tens of thousands of users) to
keep their blog/bb/etc. software up to date by giving them a point and click
method of updating them (wordpress, phpBB, drupal, etc). We can't *force*
them to update, that's against policy, but they keep getting hacked and
don't know/care enough to bother doing the update.
> If you can't figure that out at least put in an ignore_user_abort to
> prevent the user from hitting stop and messing up the installation
> process. Just make sure to create some way of knowing that an
> installation has been started and check a session value/flat file to
> see if the installation is still going in case the user does request
> the page again. Once everything is done make sure your script unsets
> the session variable/flat file to know you can proceed to the next
> step.
>
Great suggestion. I will have to do this at a minimum.
>
> Good luck!
>
Thanks.Steve.
attached mail follows:
On Fri, Apr 18, 2008 at 11:56 AM, Steve Holmes <sholmes42mac.com> wrote:
> Thanks for the suggestion, but I'm pretty far along in this project and the
> idea is that the software install happens on demand. What we are trying to
> do is get the student/faculty population (tens of thousands of users) to
> keep their blog/bb/etc. software up to date by giving them a point and click
> method of updating them (wordpress, phpBB, drupal, etc). We can't *force*
> them to update, that's against policy, but they keep getting hacked and
> don't know/care enough to bother doing the update.
The way the cron job would work is that the user requests an install.
This would write out a queue file or flag in a database marking a
specific user wants to do x upgrades.
Then the cron job, which runs every minute or so, will constantly
check for users whom have requested upgrades and proceed from there.
This way your front end script can poll against the queue/db to see
when the upgrade is finished.
Whatever gets the job done correctly is what is important, not really
the way you "skin the cat." I just know I've had to stop relying on
some of my front end scripts from doing heavy lifting as they flake
out sometimes for any of a million reasons.
attached mail follows:
On Fri, Apr 18, 2008 at 10:54:36AM -0400, Jason Pruim wrote:
>
>> So if someone could point me in the right direction I'd really appreciate
>> it.
>
> Hi Steve,
>
> From my understanding of how PHP works and from reading the archives of
> this list, and asking quite a few questions my self.. You can't do a
> progress bar in PHP since by the time it gets to the browser, PHP is done
> doing what it does.
This is actually false, at least on my system(s).
Try this out:
<?php
while (true) {
print "x";
}
?>
--
Nick Stinemates (nickstinemates.org)
http://nick.stinemates.org
attached mail follows:
On Fri, Apr 18, 2008 at 12:34 PM, Nick Stinemates <nickstinemates.org> wrote:
> On Fri, Apr 18, 2008 at 10:54:36AM -0400, Jason Pruim wrote:
> Try this out:
>
> <?php
>
> while (true) {
> print "x";
> }
Jason,
Call ob_flush() and then this example and see what happens.
attached mail follows:
hi..
if you have an action that the server is performing, and the action is going
to take some amount of time, then you're going to need to provide some form
of "progress" bar, that's a function of jscript/ajax on the client side...
you can't use just php, as php runs on the server, which is where your
action is also running. the unfortunate situation is that a php 'progress
bar' wouldn't be invoked until after the action has completed... unless you
had a periodic timer within the "action" that periodically displayed
something to the page (which could be possible)
action
{
loop through the action/task
do some events
display "x" //for progress bar
continue with the event processing
end loop
}
the other, probably better option would be to have a progress area, that
was/is a jscript/ajax based, that talked/polled the server to determine the
overall status of the "action" as it's being performed.
what did a google search on php/ajax progress bar return?
peace
-----Original Message-----
From: Nick Stinemates [mailto:nickstinemates.org]
Sent: Friday, April 18, 2008 9:35 AM
To: php-generallists.php.net
Subject: Re: [PHP] need "pop-up" in progress alert
On Fri, Apr 18, 2008 at 10:54:36AM -0400, Jason Pruim wrote:
>
>> So if someone could point me in the right direction I'd really appreciate
>> it.
>
> Hi Steve,
>
> From my understanding of how PHP works and from reading the archives of
> this list, and asking quite a few questions my self.. You can't do a
> progress bar in PHP since by the time it gets to the browser, PHP is done
> doing what it does.
This is actually false, at least on my system(s).
Try this out:
<?php
while (true) {
print "x";
}
?>
--
Nick Stinemates (nickstinemates.org)
http://nick.stinemates.org
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
attached mail follows:
On Fri, Apr 18, 2008 at 09:43:07AM -0700, bruce wrote:
> hi..
>
> if you have an action that the server is performing, and the action is going
> to take some amount of time, then you're going to need to provide some form
> of "progress" bar, that's a function of jscript/ajax on the client side...
>
> you can't use just php, as php runs on the server, which is where your
> action is also running. the unfortunate situation is that a php 'progress
> bar' wouldn't be invoked until after the action has completed... unless you
> had a periodic timer within the "action" that periodically displayed
> something to the page (which could be possible)
>
>
> action
> {
> loop through the action/task
> do some events
> display "x" //for progress bar
> continue with the event processing
> end loop
> }
>
> the other, probably better option would be to have a progress area, that
> was/is a jscript/ajax based, that talked/polled the server to determine the
> overall status of the "action" as it's being performed.
>
> what did a google search on php/ajax progress bar return?
>
> peace
>
Or the name of the file, kind of like a log.
--
Nick Stinemates (nickstinemates.org)
http://nick.stinemates.org
attached mail follows:
On Fri, Apr 18, 2008 at 12:43 PM, bruce <bedouglasearthlink.net> wrote:
>
>
> what did a google search on php/ajax progress bar return?
>
> peace
>
Once I know kind of what to search for (thanks for that) I found some very
interesting things. In particular I like:
http://www.bram.us/projects/js_bramus/jsprogressbarhandler/
I know this isn't a pop-up but I can make it work. As long as the user knows
something is happening (and I protect them from their own stupidity :-) I'll
be fine.
Thanks for all the quick help!
Steve
attached mail follows:
Hello everyone, i am working on a php script and found out that the
glob function is not working properly on the apache2 sapi, is working
just fine on the cli version, i try with php 5.2.3, 5.2.5 y 5.2.6RC5.
also try the cli version with the www-data user (the one is running
the apache) and it get the same result, any one can give me a hint
about this problem.
attached mail follows:
Thanks !
On Fri, Apr 18, 2008 at 4:03 AM, Casey <heavyccaseygmail.com> wrote:
> On Thu, Apr 17, 2008 at 6:51 PM, Alan Willsher
> <al.willshergooglemail.com> wrote:
> > Hi can you put a loop inside a loop?
> >
> > what I want to do is have something looping every 1 second and then
> > something else looping once every 10 seconds.
> >
> > something like a combination of these two..
> >
> > $x = 0;
> > while ($x < 1000) {
> > echo "1";
> > $x++;
> > sleep(1);
> > }
> >
> > $y = 0;
> > while ($y < 100) {
> > echo "2";
> > $y++;
> > sleep(10);
> > }
> >
> > but at the same time so it would output something like
> >
> > 1111111111211111111112111111111121111111112
> >
> > Thanks
> >
> <?php
> $x = 0;
> while ($x < 1000) {
> echo "1";
> $x++;
> if ($x % 10 == 9)
> echo "2";
> sleep(1);
> }
> ?>
> :)
> --
> -Casey
>
attached mail follows:
On Thu, Apr 17, 2008 at 10:05:11AM +0200, Michael Preminger wrote:
> Hello!
>
> Seems that PHP gets more and more object oriented, which is good.
>
> I am now running a course in PHP, using PHP 5, where we are going to
> use the *DOM* interface. I am trying to teach them good OO practices,
> meaning that we insistently hide properties and expose them as get or
> set methods.
Get/set methods are more often than not breaking encapsulation and
should be avoided (unless purposefully designing Model object or
something similar.)
>
> Looking at the PHPs *DOM* implementation, I see that many of the
> properties are exposed directly, without even offering get methods.
Can you please provide an example of where this is happening?
>
> 1. Is there something I am misunderstanding orotherwise missing? (I
> havenot used *DOM* in PHP before).
>
> 2.This poses a pedagogical problem for me as a teacher. How do I
> explain this contradiction to my students?
Explain that the DOM API and PHP's binding to the DOM API are 2
different things with 2 different goals.
>
> Thanks
>
> Michael
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
attached mail follows:
On Thu, Apr 17, 2008 at 5:43 PM, Nick Stinemates <nickstinemates.org>
wrote:
> On Thu, Apr 17, 2008 at 10:05:11AM +0200, Michael Preminger wrote:
> > Hello!
> >
> > Seems that PHP gets more and more object oriented, which is good.
> >
> > I am now running a course in PHP, using PHP 5, where we are going to
> > use the *DOM* interface. I am trying to teach them good OO practices,
> > meaning that we insistently hide properties and expose them as get or
> > set methods.
>
> Get/set methods are more often than not breaking encapsulation and
> should be avoided (unless purposefully designing Model object or
> something similar.)
>
egh? we had a massive argument about this last year, but if u ask me data
hiding is an integral part of encapsulation; therefore i agree w/ Michael.
>
> Looking at the PHPs *DOM* implementation, I see that many of the
> properties are exposed directly, without even offering get methods.
so, if its a big deal, write a proxy(s) which adds the encapsulation (as u
see it) u need.
Can you please provide an example of where this is happening?
>
heres a list of em from DomDocument,
readonly public string
$actualEncoding<http://us2.php.net/manual/en/class.domdocument.php#domdocument.props.actualencoding>;
readonly public DOMConfiguration
$config<http://us2.php.net/manual/en/class.domdocument.php#domdocument.props.config>;
readonly public
DOMDocumentType<http://us2.php.net/manual/en/class.domdocumenttype.php>
$doctype<http://us2.php.net/manual/en/class.domdocument.php#domdocument.props.doctype>;
readonly public DOMElement<http://us2.php.net/manual/en/class.domelement.php>
$documentElement<http://us2.php.net/manual/en/class.domdocument.php#domdocument.props.documentelement>;
public string $documentURI<http://us2.php.net/manual/en/class.domdocument.php#domdocument.props.documenturi>;
public string $encoding<http://us2.php.net/manual/en/class.domdocument.php#domdocument.props.encoding>;
public bool $formatOutput<http://us2.php.net/manual/en/class.domdocument.php#domdocument.props.formatoutput>;
readonly public
DOMImplementation<http://us2.php.net/manual/en/class.domimplementation.php>
$implementation<http://us2.php.net/manual/en/class.domdocument.php#domdocument.props.implementation>;
public bool $preserveWhiteSpace<http://us2.php.net/manual/en/class.domdocument.php#domdocument.props.preservewhitespace>
=true ;
public bool $recover<http://us2.php.net/manual/en/class.domdocument.php#domdocument.props.recover>;
public bool $resolveExternals<http://us2.php.net/manual/en/class.domdocument.php#domdocument.props.resolveexternals>;
public bool $standalone<http://us2.php.net/manual/en/class.domdocument.php#domdocument.props.standalone>;
public bool $strictErrorChecking<http://us2.php.net/manual/en/class.domdocument.php#domdocument.props.stricterrorchecking>
=true ;
public bool $substituteEntities<http://us2.php.net/manual/en/class.domdocument.php#domdocument.props.substituteentities>;
public bool $validateOnParse<http://us2.php.net/manual/en/class.domdocument.php#domdocument.props.validateonparse>
=false ;
public string $version<http://us2.php.net/manual/en/class.domdocument.php#domdocument.props.version>;
readonly public string
$xmlEncoding<http://us2.php.net/manual/en/class.domdocument.php#domdocument.props.xmlencoding>;
public bool $xmlStandalone<http://us2.php.net/manual/en/class.domdocument.php#domdocument.props.xmlstandalone>;
public string $xmlVersion<http://us2.php.net/manual/en/class.domdocument.php#domdocument.props.xmlversion>;
>
> 1. Is there something I am misunderstanding orotherwise missing? (I
> havenot used *DOM* in PHP before).
have you looked at SimpleXMLElement / SimpleXMLIterator ?? i find it to be
one of those 80% / 20% relationships where simplexml takes care of the needs
most of the time (and saves your poor brain from smoking).
> 2.This poses a pedagogical problem for me as a teacher. How do I
> explain this contradiction to my students?
the world doest operate 'by-the-book' thats life. i was a teacher once
(just for a semester) but i was teaching oop. at the end of the day who
knows why they did it that way. perhaps their views are different than
yours or the book from which your teaching. explain to them that there are
options, such as building a proxy, but there will be consequences in terms
of performance and increased complexity.
-nathan
attached mail follows:
On Fri, Apr 18, 2008 at 10:25:29AM -0600, Nathan Nobbe wrote:
> On Thu, Apr 17, 2008 at 5:43 PM, Nick Stinemates <nickstinemates.org>
> wrote:
>
> > On Thu, Apr 17, 2008 at 10:05:11AM +0200, Michael Preminger wrote:
> > > Hello!
> > >
> > > Seems that PHP gets more and more object oriented, which is good.
> > >
> > > I am now running a course in PHP, using PHP 5, where we are going to
> > > use the *DOM* interface. I am trying to teach them good OO practices,
> > > meaning that we insistently hide properties and expose them as get or
> > > set methods.
> >
> > Get/set methods are more often than not breaking encapsulation and
> > should be avoided (unless purposefully designing Model object or
> > something similar.)
> >
>
> egh? we had a massive argument about this last year, but if u ask me data
> hiding is an integral part of encapsulation; therefore i agree w/ Michael.
>
Data Hiding IS Encapsulation.
But, you have to agree,
<?php
class Lol {
private $bar;
public function getBar() { return $bar }
public function setBar($bar) { $this->bar = $bar}
}
?>
Is no different than:
<?php
class Lol {
public $bar;
}
?>
Here's a more thought out argument from http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html :
> A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details.
>
> To see why, consider that there might be 1,000 calls to a getX() method in your program, and each call assumes that the return value is of a particular type. You might store getX()'s return value in a local variable, for example, and that variable type must match the return-value type. If you need to change the way the object is implemented in such a way that the type of X changes, you're in deep trouble.
--
Nick Stinemates (nickstinemates.org)
http://nick.stinemates.org
attached mail follows:
Nick Stinemates wrote:
> On Fri, Apr 18, 2008 at 10:25:29AM -0600, Nathan Nobbe wrote:
>> On Thu, Apr 17, 2008 at 5:43 PM, Nick Stinemates <nickstinemates.org>
>> wrote:
>>
>>> On Thu, Apr 17, 2008 at 10:05:11AM +0200, Michael Preminger wrote:
>>>> Hello!
>>>>
>>>> Seems that PHP gets more and more object oriented, which is good.
>>>>
>>>> I am now running a course in PHP, using PHP 5, where we are going to
>>>> use the *DOM* interface. I am trying to teach them good OO practices,
>>>> meaning that we insistently hide properties and expose them as get or
>>>> set methods.
>>> Get/set methods are more often than not breaking encapsulation and
>>> should be avoided (unless purposefully designing Model object or
>>> something similar.)
>>>
>> egh? we had a massive argument about this last year, but if u ask me data
>> hiding is an integral part of encapsulation; therefore i agree w/ Michael.
>>
>
> Data Hiding IS Encapsulation.
>
> But, you have to agree,
>
> <?php
>
> class Lol {
> private $bar;
>
> public function getBar() { return $bar }
> public function setBar($bar) { $this->bar = $bar}
>
> }
> ?>
>
> Is no different than:
>
> <?php
> class Lol {
> public $bar;
> }
> ?>
>
>
> Here's a more thought out argument from http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html :
>
>> A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details.
>>
>> To see why, consider that there might be 1,000 calls to a getX() method in your program, and each call assumes that the return value is of a particular type. You might store getX()'s return value in a local variable, for example, and that variable type must match the return-value type. If you need to change the way the object is implemented in such a way that the type of X changes, you're in deep trouble.
>
No,but in the first one, you can control, from within the class/method, what
data is actually allowed to be injected into that variable. Whereas the second
example would allow you to stuff any type of data into that class variable.
That might not be a good thing.
--
Jim Lucas
"Some men are born to greatness, some achieve greatness,
and some have greatness thrust upon them."
Twelfth Night, Act II, Scene V
by William Shakespeare
attached mail follows:
>> Data Hiding IS Encapsulation.
>> But, you have to agree,
>> <?php
>> class Lol {
>> private $bar;
>> public function getBar() { return $bar }
>> public function setBar($bar) { $this->bar = $bar}
>> }
>> ?>
>> Is no different than:
>> <?php
>> class Lol {
>> public $bar;
>> }
>> ?>
>> Here's a more thought out argument from
>> http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html :
>>> A fundamental precept of OO systems is that an object should not expose
>>> any of its implementation details. This way, you can change the
>>> implementation without changing the code that uses the object. It follows
>>> then that in OO systems you should avoid getter and setter functions
>>> since they mostly provide access to implementation details.
>>>
>>> To see why, consider that there might be 1,000 calls to a getX() method
>>> in your program, and each call assumes that the return value is of a
>>> particular type. You might store getX()'s return value in a local
>>> variable, for example, and that variable type must match the return-value
>>> type. If you need to change the way the object is implemented in such a
>>> way that the type of X changes, you're in deep trouble.
>
> No,but in the first one, you can control, from within the class/method,
> what data is actually allowed to be injected into that variable. Whereas
> the second example would allow you to stuff any type of data into that
> class variable. That might not be a good thing.
>
That's a relatively narrow minded response to my point, since I gave
a pretty concrete example of exactly what I meant, followed by a great
article which furthered my point.
The general rule of encapsulation is: Don't ask an object for data, ask
the object to work with the data.
--
Nick Stinemates (nickstinemates.org)
http://nick.stinemates.org
attached mail follows:
On Fri, Apr 18, 2008 at 11:21 AM, Nick Stinemates <nickstinemates.org>
wrote:
> On Fri, Apr 18, 2008 at 10:25:29AM -0600, Nathan Nobbe wrote:
> > On Thu, Apr 17, 2008 at 5:43 PM, Nick Stinemates <nickstinemates.org>
> > wrote:
> >
> > > On Thu, Apr 17, 2008 at 10:05:11AM +0200, Michael Preminger wrote:
> > > > Hello!
> > > >
> > > > Seems that PHP gets more and more object oriented, which is good.
> > > >
> > > > I am now running a course in PHP, using PHP 5, where we are going to
> > > > use the *DOM* interface. I am trying to teach them good OO
> practices,
> > > > meaning that we insistently hide properties and expose them as get
> or
> > > > set methods.
> > >
> > > Get/set methods are more often than not breaking encapsulation and
> > > should be avoided (unless purposefully designing Model object or
> > > something similar.)
> > >
> >
> > egh? we had a massive argument about this last year, but if u ask me
> data
> > hiding is an integral part of encapsulation; therefore i agree w/
> Michael.
> >
>
> Data Hiding IS Encapsulation.
>
> But, you have to agree,
>
> <?php
>
> class Lol {
> private $bar;
>
> public function getBar() { return $bar }
> public function setBar($bar) { $this->bar = $bar}
>
> }
> ?>
>
> Is no different than:
>
> <?php
> class Lol {
> public $bar;
> }
> ?>
it is different, by your very definition. quote 'Data Hiding IS
Encapsulation' so the difference in the 2 examples you supplied is that the
first one is an example of encapsulation, whereas the later is not.
encapsulation provides control. it reduces the possibility of client code
binding to implementation details which decreases coupling. go into the
archives, you will find the argument from last year. its in the same one
about interfaces, that we pretty much re-hashed this week.
-nathan
attached mail follows:
On Fri, Apr 18, 2008 at 11:50 AM, Nick Stinemates <nickstinemates.org>
wrote:
> That's a relatively narrow minded response to my point, since I gave
> a pretty concrete example of exactly what I meant,
no, its a very valid criticism of your flawed example. you supply a
definition of encapsulation, and then demonstrate, by example, that you dont
understand its importance.
> followed by a great
> article which furthered my point.
take a look at the books i listed in the argument last year. youll find
that all the books ive ever read on oop are strong proponents of data-hiding
as a component of encapsulation.
The general rule of encapsulation is: Don't ask an object for data, ask
> the object to work with the data.
more precisely, operations on a class should be driven through a
well-defined public interface.
-nathan
attached mail follows:
Nick Stinemates wrote:
>>> Data Hiding IS Encapsulation.
>>> But, you have to agree,
>>> <?php
>>> class Lol {
>>> private $bar;
>>> public function getBar() { return $bar }
>>> public function setBar($bar) { $this->bar = $bar}
>>> }
>>> ?>
>>> Is no different than:
>>> <?php
>>> class Lol {
>>> public $bar;
>>> }
>>> ?>
>>> Here's a more thought out argument from
>>> http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html :
>>>> A fundamental precept of OO systems is that an object should not expose
>>>> any of its implementation details. This way, you can change the
>>>> implementation without changing the code that uses the object. It follows
>>>> then that in OO systems you should avoid getter and setter functions
>>>> since they mostly provide access to implementation details.
>>>>
>>>> To see why, consider that there might be 1,000 calls to a getX() method
>>>> in your program, and each call assumes that the return value is of a
>>>> particular type. You might store getX()'s return value in a local
>>>> variable, for example, and that variable type must match the return-value
>>>> type. If you need to change the way the object is implemented in such a
>>>> way that the type of X changes, you're in deep trouble.
>> No,but in the first one, you can control, from within the class/method,
>> what data is actually allowed to be injected into that variable. Whereas
>> the second example would allow you to stuff any type of data into that
>> class variable. That might not be a good thing.
>>
>
> That's a relatively narrow minded response to my point, since I gave
> a pretty concrete example of exactly what I meant, followed by a great
> article which furthered my point.
>
Let me quote, you said this: "Is no different than" You are wrong, in fact it
IS different. Having your own custom methods to get or set data allows you to
have more control over what data is injected into your object.
I would call is a personal preference which may not work for you, but works fine
for me.
All I can say is that all my __set methods do data sanitizing and validation,
which is were I think it should be done. If anybody thinks this might be a bad
thing, please by all means explain why it is bad.
> The general rule of encapsulation is: Don't ask an object for data, ask
> the object to work with the data.
>
I hope it checks the data first before using it. If you don't then you might
end up with something you had not planned on.
If I am not to ask an object for data how is my db class/object ever going to
return me data from my database?
--
Jim Lucas
"Some men are born to greatness, some achieve greatness,
and some have greatness thrust upon them."
Twelfth Night, Act II, Scene V
by William Shakespeare
attached mail follows:
On Fri, 2008-04-18 at 11:50 -0700, Jim Lucas wrote:
> Nick Stinemates wrote:
> >>> Data Hiding IS Encapsulation.
> >>> But, you have to agree,
> >>> <?php
> >>> class Lol {
> >>> private $bar;
> >>> public function getBar() { return $bar }
> >>> public function setBar($bar) { $this->bar = $bar}
> >>> }
> >>> ?>
> >>> Is no different than:
> >>> <?php
> >>> class Lol {
> >>> public $bar;
> >>> }
> >>> ?>
> >>> Here's a more thought out argument from
> >>> http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html :
> >>>> A fundamental precept of OO systems is that an object should not expose
> >>>> any of its implementation details. This way, you can change the
> >>>> implementation without changing the code that uses the object. It follows
> >>>> then that in OO systems you should avoid getter and setter functions
> >>>> since they mostly provide access to i