[PHP] Re: Strip outgoing whitespace in html
Opps, we just found mod_tidy. :) Christopher J. Bottaro wrote: > I'm wondering if there's a convenient way to globally add a final step for > apache w/php that will remove unnecessary whitespace from text/html before > it gets sent to the client. Some sort of global config like thing would be > ideal. For what it's worth we're using the smarty template engine too, but > I suppose I'd prefer a solution that doesn't depend on it. Maybe something > like another AddHandler? > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Strip outgoing whitespace in html
I'm wondering if there's a convenient way to globally add a final step for apache w/php that will remove unnecessary whitespace from text/html before it gets sent to the client. Some sort of global config like thing would be ideal. For what it's worth we're using the smarty template engine too, but I suppose I'd prefer a solution that doesn't depend on it. Maybe something like another AddHandler? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Re: trapping fatal errors...?
Jochem Maas wrote:
> Christopher J. Bottaro wrote:
>> Adam Zey wrote:
>>
>>> Christopher J. Bottaro wrote:
>>>> Hello,
>>>> How can I trap a fatal error (like calling a non existant method,
>>>> requiring
>>>> a non existant file, etc) and go to a user defined error handler? I
>>>> tried set_error_handler(), but it seems to skip over the errors I care
>>>> about.
>>>>
>>>> Thanks for the help.
>>> It is always safer to handle errors before they happen by checking that
>>> you're in a good state before you try to do something.
>>>
>>> For example, nonexistent files can be handled by file_exists().
>>> Undefined functions can be checked with function_exists().
>>>
>>> Regards, Adam Zey.
>>
>> Well, I know that.
>>
>> Sometimes unexpected errors happen. We write hundreds of lines of code a
>> day. Typos happen, I forget some includes, I type $d->appendCild()
>> instead
>> of $d->appendChild(). It's all a part of the development process.
>>
>> Our application makes extensive use of AJAX and JSON. Sometimes we make
>> an AJAX request and expect a JSON object in return, but instead a fatal
>> error happens (DOMDocument::appendChid() does not exist), well now we get
>> a JSON error because the response headers were messed up by the fatal
>> error.
>>
>> That JSON error is useless. We would rather see the real error as PHP
>> would have reported it on a simple webpage or command line.
>>
>> Basically, we just want to trap all errors and reraise them as exceptions
>> so that our app's default exception handler can report them.
>
> for fatal errors this not possible.
>
> write test routines to check the output of requests that are usually made
> by AJAX code... and made use a function like this to cover all your bases:
>
> function PHPErrorReturned(response)
> {
> // this is a bit crude and could possibly break if we are recieving
> // [content] HTML as part of the returned data.
> if ((response.indexOf('Notice: ') ||
> response.indexOf('Warning: ') ||
> response.indexOf('Fatal Error: ')) &&
> (response.indexOf('{') != 0))
> {
> alert("Er was een fout opgetreden op de
> server\n"+response.stripTags()); return true;
> }
>
> return false;
> }
>
> String.prototype.stripTags = function (validTags)
> {
> var newstr = this.toString();
> var regExp1 = /<\/?(\w+)(.*?)>/ig;
>
> if (validTags && validTags.prototype == Array) {
> var regExp2 = new RegExp('/^('+validTags.join('|')+')$/i'); //
> em|strong|u|p
> }
>
> while(mt = regExp1.exec(newstr)) {
> oldstr = mt[0]; tag = mt[1]; pars = mt[2];
> repl = '';
>
> if(regExp2 && tag.match(regExp2)) {
> repl = oldstr.replace(pars,'');
> }
>
> newstr = newstr.replace(oldstr, repl);
> }
> return newstr;
> }
>
>
>
>
>>
>> Thanks.
Cool, that sounds promising, thanks for that idea (and everyone else who
replied).
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: trapping fatal errors...?
Adam Zey wrote: > Christopher J. Bottaro wrote: >> Hello, >> How can I trap a fatal error (like calling a non existant method, >> requiring >> a non existant file, etc) and go to a user defined error handler? I >> tried set_error_handler(), but it seems to skip over the errors I care >> about. >> >> Thanks for the help. > > It is always safer to handle errors before they happen by checking that > you're in a good state before you try to do something. > > For example, nonexistent files can be handled by file_exists(). > Undefined functions can be checked with function_exists(). > > Regards, Adam Zey. Well, I know that. Sometimes unexpected errors happen. We write hundreds of lines of code a day. Typos happen, I forget some includes, I type $d->appendCild() instead of $d->appendChild(). It's all a part of the development process. Our application makes extensive use of AJAX and JSON. Sometimes we make an AJAX request and expect a JSON object in return, but instead a fatal error happens (DOMDocument::appendChid() does not exist), well now we get a JSON error because the response headers were messed up by the fatal error. That JSON error is useless. We would rather see the real error as PHP would have reported it on a simple webpage or command line. Basically, we just want to trap all errors and reraise them as exceptions so that our app's default exception handler can report them. Thanks. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] trapping fatal errors...?
Hello, How can I trap a fatal error (like calling a non existant method, requiring a non existant file, etc) and go to a user defined error handler? I tried set_error_handler(), but it seems to skip over the errors I care about. Thanks for the help. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: How to show complete exception text?
Kevin Waterson wrote:
> This one time, at band camp, "Christopher J. Bottaro"
> <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>>
>> When an exception propagates all the way up the stack frame and splatters
>> itself on my webpage, most of the text is cut off! This is completely
>> useless. I can see that there is an error, but I can't read the frickin
>> error message. How do I configure PHP to show the entire exception
>> message?
>
> not sure of your code, are you trying to do something like..
>
> try {
>lots of good code;
> }
>
> catch(Exception $e){
> echo 'oh my, and exception has been thrown'.$e->getMessage();
> }
> ?>
No. The exception is not being caught and is propagating all the way up.
Then it is displayed on the webpage along with the call stack. The problem
is that a lot of the text is cut short so it will fit on the webpage
without word wrapping.
> Kevin
-- C
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] How to show complete exception text?
Hi, When an exception propagates all the way up the stack frame and splatters itself on my webpage, most of the text is cut off! This is completely useless. I can see that there is an error, but I can't read the frickin error message. How do I configure PHP to show the entire exception message? Thank you. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: possible bug (string equality to zero)?
Scott Noyes wrote: >> [snip] >> Is it a bug that ($var == 0) is always true for any string $var? >> [/snip] >> >> You are comparing a string to an integer. > > Right. This is clearly documented at > http://www.php.net/operators.comparison > Oh, I see...it converts the string into number, not the other way around. Thanks for the link. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: possible bug (string equality to zero)?
Torgny Bjers wrote: > No, Christopher, that is not a bug. As long as the var is empty, and if > you try to compare with 0, or false, it will report true in the > comparison because the variable does not contain anything, which will > mean false for a boolean and 0 for a variable. If you are attempting to > discover if a string contains data, use empty() instead. You can also > check if the string is null or actual zero (0). But the var isn't empty. $a[] = 'blah'; $a[] = 'blah'; $a['assoc'] = 'array'; foreach ($a as $k => $v) if ($k == 'assoc') # do something The 'if' statement is incorrectly executing when $k is 0. I find it strange that 0 == any string. The way I see it, 0 is false. false == 'a string' should not be true. Thanks for the reply, -- C > Regards, > Torgny > > Christopher J. Bottaro wrote: > >>Is it a bug that ($var == 0) is always true for any string $var? >> > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] possible bug (string equality to zero)?
Is it a bug that ($var == 0) is always true for any string $var? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: help, no jpeg support compiled in
Richard Lynch wrote: > On Wed, July 6, 2005 5:42 pm, Christopher J. Bottaro said: >> Warning: imagecreatefromstring() [function.imagecreatefromstring]: No >> JPEG support in this PHP build >> >> This is how I configured my php: >> >> ./configure --with-pgsql=/usr/local/postgres/ --with-apxs2=/usr/sbin/apxs >> --with-gd --with-zlib-dir=/usr/lib --with-jpeg-dir=/usr/lib >> >> I also tried with /usr instead of /usr/lib. > > /usr/lib is definitely Not Right. > > ./configure needs to find /usr/lib/*jpeg.so but *ALSO* needs to find > /usr/include/*jpeg.h I know, but the weird thing is that --with-zlib-dir=/usr/lib actually worked (don't ask me why)! It got PNG support working with GD that way. So I figured I'd try it that way with JPEG. > Did you do "ldconfig" after you installed the JPEG lib? > [Assuming you're on a distro that does that...] Yeah, its a Fedora Core 3 install, so most of these image libs are already installed: ldconfig -v | grep -i jpeg ldconfig: Path `/usr/X11R6/lib' given more than once libjpeg.so.62 -> libjpeg.so.62.0.0 libimlib-jpeg.so -> libimlib-jpeg.so > Sometimes getting the OS to suck in the JPEG library makes it all > better... > > In fact, do: > ldconfig -v | grep -i jpeg > to see if you actually got JPEG into the OS. > > I'm not 100% sure you need all this, but at least you know the JPEG stuff > is "there" if the OS can get it. Oops, see above. > If it's not, dink around with /etc/ld.so.conf (or whatever it's named this > week) and add the directories you need to get jpeg.so to get sucked in. > >> P.S. Yes, I am remembering to start Apache. > > I've seen some funky Apache restart scripts that would report a false > successful restart when, in fact, Apache neither stopped nor started... > > Stop Apache, do "ps aux | grep httpd" to make sure it's gone, then > start it. Ugh. Better to be 100% certain, though. Sure wish phpinfo() had > a "php_uptime()" in it... Interesting. I'm pretty sure its restarting because I'm messing around with different config options and phpinfo() is reporting different "Configure Command"s each time. I'll try that though. > If all else fails, you could read the config.log output in your PHP > directory and try to figure out what it's complaining about when it skips > the JPEG part and mindlessly continues to build the PHP binary that does > *NOT* have the parts you asked for... Which I really don't think it > should do, personally, but there it is. > > You'll want to search for JPEG and/or ERROR in that mess, cuz there's a > TON of output. Will do, thanks again for the help. I'll report my findings when (and if) I figure it out. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] help, no jpeg support compiled in
Warning: imagecreatefromstring() [function.imagecreatefromstring]: No JPEG support in this PHP build This is how I configured my php: ./configure --with-pgsql=/usr/local/postgres/ --with-apxs2=/usr/sbin/apxs --with-gd --with-zlib-dir=/usr/lib --with-jpeg-dir=/usr/lib I also tried with /usr instead of /usr/lib. Both libjpeg-6b-33 libjpeg-devel-6b-33 are installed. phpinfo() reports: gd GD Support enabled GD Version bundled (2.0.28 compatible) GIF Read Support enabled GIF Create Support enabled PNG Support enabled WBMP Support enabled XBM Support enabled I'm using php-5.0.4 and Fedora Core 3. Where is jpeg? Thanks for the help. P.S. Yes, I am remembering to start Apache. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Re: Re: Re: __get() not reentrant?
Jochem Maas wrote: >>>On Sun, May 22, 2005 3:24 pm, Christopher J. Bottaro said: >>> >>>>And what would make it any different from a normal recursive function? >>> >>>The fact that *ANY* attempt to access a mis-typed property would kick in >>>a __get() call, and that's too frickin' easy to happen in code that's too >>>easy to fly by QA in large-scale applications springs to mind... > > don't forget the noob factor - a noob could spend days trying to figure > out WTF is going on in such a situation. we might even lose him to ASP > in that time :-/ I didn't realize that PHP had such an emphasis on the "noob factor". >>>Not saying you're "wrong" or they're "right" just that it's not quite as >>>simple as a normal recursive function or loop iteration. >> >> >> I completely disagree. I don't mean any offense to anyone here, but I >> find it kind of ridiculous for a language to restrict itself that like in >> this >> case. Its insulting to our intelligence as programmers. >> > > er whatever, interesting to see how easily you are insulted - I mean its a > programming language with a certain kind of implementation, which may not > be perfect, but I don't think they we're thinking of you when they wrote > it. I just don't like being talked down to, who does? You can be immature and poke fun at my choice of words if you want. All I meant to say is that I find it weird that PHP assumes that I don't understand how recursion works. >>>>Every recursive function runs the risk of going into infinite loop if >>>>the programmer doesn't understand the basic concept (or makes a silly >>>>mistake). >>> >>>Just saying it's an easier silly mistake to mis-type: $whatever->fooo >>>instead of $whatever->foo and have that escape QA somehow. >>> >>> >>>>Loops run the risk of going on indefinitely as well. Maybe PHP should >>>>disable all forms of loops/recursion to protect the programmers from >>>>themselves. >>> >>>That does seem a bit excessive... >> >> >> I was making a point. I don't see why recursion is allowed in every >> other >> function except for __get(). I think your argument is weak about >> protecting people from typos. If PHP wanted to protect people from >> typos, it should force you to declare your variables. >> > > you think its a weak argument, maybe you are missing the point - ask > yourself what the average level of php programmers is? part of the php > philosophy is about making/keeping php accessible. Again, I didn't realize was so geared towards "noobs". > I think you will find that if you we're forced to declare you [class] > variables that your __get() implementation would stop working they way it > does now... No, I use __get() to provide property like access to calculated values. There is no corresponding class var for these values. If I wanted access to class vars, I'd just declare them and then __get() wouldn't be used. >>>Maybe __get() should allow recursion and let the developer worry about >>>infinite recursion. > > Is that the 11th commandment? I have no idea what you are talking about. I meant to say, "Maybe __get()'s implicit invocation should work like normal functions." >>>But, today, it doesn't, so deal with it and move on. > > ditto. Do yall really think I have halted my work because of this? I just want to discuss it. >> I was bringing the to the table a discussion of the current behavior of >> __get(). I proposed that I might be broken or maybe should be changed, >> and > > maybe you are broken, hard to tell from here. Way to make me look stupid because I made a typo. >> you start insulting my abilities as a programmer and suggest that we >> shouldn't consider "moving forward" and just deal with what we have? >> > > I think Richard is a fairly intelligent person, if he had been insulting > you I'm quite sure that he would have done a much better job ;-) Thats great, I'm sure he's the reigning "cut down contest" champ on this list. I don't care. Like I said, I don't like being talked down to. I found it very unnecessarily presumptuous of him to say stuff like "without knowing anything about you, I assume you have made bad design decisions, painted yourself in a corner, etc". What the hell does any of that have to do with the discussion? >> Painted myself into this corner?
[PHP] Re: Re: Re: __get() not reentrant?
Richard Lynch wrote:
> On Sun, May 22, 2005 3:24 pm, Christopher J. Bottaro said:
>> And what would make it any different from a normal recursive function?
>
> The fact that *ANY* attempt to access a mis-typed property would kick in a
> __get() call, and that's too frickin' easy to happen in code that's too
> easy to fly by QA in large-scale applications springs to mind...
>
> Not saying you're "wrong" or they're "right" just that it's not quite as
> simple as a normal recursive function or loop iteration.
I completely disagree. I don't mean any offense to anyone here, but I find
it kind of ridiculous for a language to restrict itself that like in this
case. Its insulting to our intelligence as programmers.
>> Every recursive function runs the risk of going into infinite loop if the
>> programmer doesn't understand the basic concept (or makes a silly
>> mistake).
>
> Just saying it's an easier silly mistake to mis-type: $whatever->fooo
> instead of $whatever->foo and have that escape QA somehow.
>
>> Loops run the risk of going on indefinitely as well. Maybe PHP should
>> disable all forms of loops/recursion to protect the programmers from
>> themselves.
>
> That does seem a bit excessive...
I was making a point. I don't see why recursion is allowed in every other
function except for __get(). I think your argument is weak about
protecting people from typos. If PHP wanted to protect people from typos,
it should force you to declare your variables.
> Maybe __get() should allow recursion and let the developer worry about
> infinite recursion.
>
> But, today, it doesn't, so deal with it and move on.
I was bringing the to the table a discussion of the current behavior of
__get(). I proposed that I might be broken or maybe should be changed, and
you start insulting my abilities as a programmer and suggest that we
shouldn't consider "moving forward" and just deal with what we have?
>> What is wrong with that? Why should PHP disallow that recursive __get()
>> call? It is perfectly valid recursive code. It terminates for all
>> cases.
>
> What happens if you do:
>
> class example {
> function __get($x){
> return $this->recursive_get($x);
> }
>
> function recursive_get($x){
> /* paste your current __get function body here */
> }
> }
>
> I suspect it will work just fine at the expense of one (1) extra function
> call, which is not significant in recursion.
I suspect it doesn't. If __get() is anywhere in the call stack, then
$this->x won't invoke a 2nd __get() call.
> A recursive __get() has some serious implications to performance and
> design decisions that painted you into this corner.
Well, it doesn't have any implication on the performance of my app,
considering the code path is executed like 5% (or less) of the time.
Painted myself into this corner? Why? Because I think its easier to write
$this->myvar than it is to write $this->attrs['myvar']? Its PHP's job to
make my life easier and more convenient.
> Obviously, it's entirely possible that your Design is the most elegant
> beautiful disciplined bit of code since John von Nueman... But it's more
> likely, without knowing anything about you, that you've come up with this
> as a result of some bad Design decisions.
>
> Review your Design. :-)
>
Wow, how pompous of you. Bad design, huh? Since when is it bad design to
calculate attribute values on the fly? Many "cookbook" style books have
idioms for doing this. In my case, one of the calculated values depends on
other values accessible via __get(). So why shouldn't I use __get()? The
syntax is cleaner. Btw, when I say "use __get()", I mean implicitly call
__get() via $this->attribute syntax. This whole problem does not exist if
you call __get() explicitly, but then whats the point.
Speaking of "good design", Python's __getattr__() behaves how I expect.
-- C
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Re: __get() not reentrant?
Marek Kilimajer wrote:
> Christopher J. Bottaro wrote:
>> Jochem Maas wrote:
>>
>>
>>>Christopher J. Bottaro wrote:
>>>
>>>>Maybe I'm using "reentrant" incorrectly, but here is what I mean...
>>>>
>>>>class Test {
>>>> function __get($nm) {
>>>> if ($nm == 'x')
>>>> return $this->func();
>>>> elseif ($nm == 'y')
>>>> return 'y';
>>>> elseif ($nm == 'xx')
>>>> return 'x';
>>>> }
>>>> function func() {
>>>> return $this->xx;
>>>> }
>>>>}
>>>>$t = new Test();
>>>>print $t->y . "\n";
>>>>print $t->xx . "\n";
>>>>print $t->x . "\n";
>>>>print $t->func() . "\n";
>>>>
>>>>I would expect the following code to output:
>>>>y
>>>>x
>>>>x
>>>>x
>>>>
>>>>But instead, it outputs:
>>>>y
>>>>x
>>>>
>>>>x
>>>>
>>>>Is this a bug? This limitation is not documented (maybe it should be?).
>>>
>>>its not a bug, I believe its documented somewhere how this works.
>>>bottom line __get() does not work from 'inside' the class/object,
>>>so do something like instead:
>>>
>>> function func() {
>>>return $this->__get('xx');
>>> }
>>>
>>>which may not please the soul, but does work ;-)
>>
>>
>> Hehe, my soul is hard to please...=P
>>
>> Actually, __get() does work from inside the class. In the sample code I
>> posted, func() does indeed return 'x' when called from main. It does not
>> work when called from within a call to __get(). In other words,
>> $this->attribute does not work if __get() appears anywhere in the call
>> stack.
>>
>> Its just a small annoyance.
>
> I think it would be more annoying if __get() would be recursively called
> to infinity.
And what would make it any different from a normal recursive function?
Every recursive function runs the risk of going into infinite loop if the
programmer doesn't understand the basic concept (or makes a silly mistake).
Loops run the risk of going on indefinitely as well. Maybe PHP should
disable all forms of loops/recursion to protect the programmers from
themselves.
Trace my code for $t->x...
$t->x;
$t->__get('x');
$t->func();
$t->xx;
$t->__get('xx');
'x'
What is wrong with that? Why should PHP disallow that recursive __get()
call? It is perfectly valid recursive code. It terminates for all cases.
-- C
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: __get() not reentrant?
Jochem Maas wrote:
> Christopher J. Bottaro wrote:
>> Maybe I'm using "reentrant" incorrectly, but here is what I mean...
>>
>> class Test {
>>function __get($nm) {
>> if ($nm == 'x')
>> return $this->func();
>> elseif ($nm == 'y')
>> return 'y';
>> elseif ($nm == 'xx')
>> return 'x';
>>}
>>function func() {
>> return $this->xx;
>>}
>> }
>> $t = new Test();
>> print $t->y . "\n";
>> print $t->xx . "\n";
>> print $t->x . "\n";
>> print $t->func() . "\n";
>>
>> I would expect the following code to output:
>> y
>> x
>> x
>> x
>>
>> But instead, it outputs:
>> y
>> x
>>
>> x
>>
>> Is this a bug? This limitation is not documented (maybe it should be?).
>
> its not a bug, I believe its documented somewhere how this works.
> bottom line __get() does not work from 'inside' the class/object,
> so do something like instead:
>
> function func() {
> return $this->__get('xx');
> }
>
> which may not please the soul, but does work ;-)
Hehe, my soul is hard to please...=P
Actually, __get() does work from inside the class. In the sample code I
posted, func() does indeed return 'x' when called from main. It does not
work when called from within a call to __get(). In other words,
$this->attribute does not work if __get() appears anywhere in the call
stack.
Its just a small annoyance. I use $this->attribute everywhere in the class,
but I have to remember to use $this->__get(attribute) in methods that can
be called from __get().
-- C
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] __get() not reentrant?
Maybe I'm using "reentrant" incorrectly, but here is what I mean...
class Test {
function __get($nm) {
if ($nm == 'x')
return $this->func();
elseif ($nm == 'y')
return 'y';
elseif ($nm == 'xx')
return 'x';
}
function func() {
return $this->xx;
}
}
$t = new Test();
print $t->y . "\n";
print $t->xx . "\n";
print $t->x . "\n";
print $t->func() . "\n";
I would expect the following code to output:
y
x
x
x
But instead, it outputs:
y
x
x
Is this a bug? This limitation is not documented (maybe it should be?).
-- C
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] debugger for CLI PHP scripts...?
Is there such a thing? You know, with single stepping, breakpoints, examining vars, etc. 100% of my PHP stuff is CLI (wacky, huh?) and I'd really benefit from a traditional debugger. Oh btw, I'm looking for a free/opensource one. Thanks! P.S. Yes, I've searched Google and www.php.net/manual, and yes, I've found stuff... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: expand array into function arguments?
Richard Lynch wrote: > On Wed, May 11, 2005 12:13 pm, Christopher J. Bottaro said: >> You can do this in Python: >> >> >> def myFunc(arg1, arg2, arg): >> #do something >> >> myList = [1, "arg", 5] >> myFunc(*myList) # calls myFunc(1, "arg", 2) >> >> >> Can that be done in PHP, and if so, how? > > You mean call a user function with an array for the parameters? > > Didja search the PHP website? Yes, but sometimes its hard to search unless you know exactly what you are looking for. I was looking for a language construct, I wasn't really expecting a function. > You should have found this: > > http://php.net/call_user_func_array That its, perfect. Thank you. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] expand array into function arguments?
You can do this in Python: def myFunc(arg1, arg2, arg): #do something myList = [1, "arg", 5] myFunc(*myList) # calls myFunc(1, "arg", 2) Can that be done in PHP, and if so, how? Thanks for the help. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] calling a derived static method from a base class
class Base {
static function f() {
self::g();
}
static function g() {
print("Base\n");
}
}
class Derived extends Base {
static function g() {
print("Derived\n");
}
}
Derived::f();
I want that to print "Derived", but it prints "Base" instead. How can I get
it to do what I want?
Thank for the help.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
