php-general Digest 14 Jun 2013 04:22:06 -0000 Issue 8265
Topics (messages 321378 through 321400):
Enabling the chroot() function in PHP 5.4
321378 by: Aaron Stephens
321393 by: Matijn Woudt
PHP is Zero
321379 by: BUSCHKE Daniel
321380 by: georg
321381 by: BUSCHKE Daniel
321382 by: Pete Ford
321383 by: BUSCHKE Daniel
321384 by: richard gray
321385 by: Pete Ford
321386 by: BUSCHKE Daniel
321387 by: BUSCHKE Daniel
321388 by: Samuel Lopes Grigolato
321389 by: Stuart Dallas
321390 by: Samuel Lopes Grigolato
321392 by: Alessandro Pellizzari
321397 by: Matijn Woudt
Re: Detect and Redirect Mobile Users
321391 by: raphael khaiat
321394 by: Matijn Woudt
321395 by: Matijn Woudt
321396 by: Camille Hodoul
321400 by: Dead Letter.Office
What is the name of the pattern that will ...
321398 by: Richard Quadling
321399 by: David Harkness
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
Hi All,
Does anybody know how to enable the chroot() function in PHP 5.4?
It was easy in PHP 5.3 as long as you were building the CLI by itself.
In the PHP 5.4 configure script there is a new PHP_BINARIES variable
being used instead of setting PHP_SAPI=cli and thus the "#define
ENABLE_CHROOT_FUNC 1" is never written to the output file. I have been
able to manually enable it by adding the define to the main/php_config.h
after running configure. The issue seems to be a line: if test
"program" = "program". This comparison being true is what causes the
configure script to add "cli" to the PHP_BINARIES variable instead of
setting the PHP_SAPI variable. The other prerequisites (HAVE_CHROOT and
ZTS) are all at the required settings. It is only the
ENABLE_CHROOT_FUNC which is causing the function to not be compiled into
the resulting binary. Any information or explanation would be very helpful.
For the record, I know what the chroot() function does and does not
do. I am experimenting with using chroot() to isolate an already
running script to a particular subset of the filesystem for file operations.
--
- Aaron
--- End Message ---
--- Begin Message ---
Hi Aaron,
It's better if you ask this question on the PHP internals list, there's
hardly anyone compiling it's own PHP here.
- Matijn
On Thu, Jun 13, 2013 at 9:55 AM, Aaron Stephens
<aaron.t.steph...@gmail.com>wrote:
> Hi All,
>
> Does anybody know how to enable the chroot() function in PHP 5.4? It
> was easy in PHP 5.3 as long as you were building the CLI by itself. In the
> PHP 5.4 configure script there is a new PHP_BINARIES variable being used
> instead of setting PHP_SAPI=cli and thus the "#define ENABLE_CHROOT_FUNC 1"
> is never written to the output file. I have been able to manually enable
> it by adding the define to the main/php_config.h after running configure.
> The issue seems to be a line: if test "program" = "program". This
> comparison being true is what causes the configure script to add "cli" to
> the PHP_BINARIES variable instead of setting the PHP_SAPI variable. The
> other prerequisites (HAVE_CHROOT and ZTS) are all at the required settings.
> It is only the ENABLE_CHROOT_FUNC which is causing the function to not be
> compiled into the resulting binary. Any information or explanation would
> be very helpful.
>
> For the record, I know what the chroot() function does and does not
> do. I am experimenting with using chroot() to isolate an already running
> script to a particular subset of the filesystem for file operations.
>
> --
>
> - Aaron
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
Hi all,
I want to start a discussion about a PHP behaviour that drives me crazy for
years. For the beginning I would like you to guess what the result of the
following snippet will be:
var_dump('PHP' == 0);
I know the difference of == and === but the result was unexcpected for me. And
I hope it is also for you. The result is simply "true". Why is it true? I guess
this happens because of the conversion from 'PHP' to a number which will be 0
in PHP. And of course 0 equals 0. There are several points that I just want to
drop into this mailinglist to discuss about:
1. Why? :)
2. Why is PHP converting the String into a Number instead of converting the
Number into a String? (If my guess concerning the behaviour is correct)
3. Why is PHP throwing data away which has the developer explicit given to the
interpreter?
4. Why does var_dump(0 == 'PHP'); has the same result as the snippet above?
This meens that the equal operator is not explictly implemented in the string
or integer?
5. Thats a bug I have opend: https://bugs.php.net/bug.php?id=51739 where I also
had the same problems because "8315e839da08e2a7afe6dd12ec58245d" was converted
into float(INF) by throwing everything starting from "da08.." away.
I am using PHP since the year 2000. This means I have 13 years of experience in
PHP and I really would like you to NOT just answer "works as designed". I know
it works as designed but I want to discuss the design. Also I know that the
"fuzzy" behaviour of type conversion is a main feature of PHP. I guess this is
one point which makes PHP that successfull. But - in my opinion - the described
behaviour is to fuzzy and just confuses developers.
Best Regards
Daniel Buschke
--- End Message ---
--- Begin Message ---
Sorry missed to post list as well
Hi Daniel,
here is wild goose
i assume you have 3 x =
in your "problem" formulation
which could possibly result in the akward standard C mixup;
the rightmost = first parsed and resulting in an ASSIGMENT to the variable
with that value,
the comes the parsing of == which is the equivalence test, and see; the
variable is
the same since it was just assigned that value; if this theory is correct
you would
get TRUE regardless what number is following :)
/g
----- Original Message -----
From: "BUSCHKE Daniel" <daniel.busc...@nextiraone.eu>
To: <php-gene...@lists.php.net>
Sent: Thursday, June 13, 2013 9:59 AM
Subject: [PHP] PHP is Zero
Hi all,
I want to start a discussion about a PHP behaviour that drives me crazy
for years. For the beginning I would like you to guess what the result of
the following snippet will be:
var_dump('PHP' == 0);
I know the difference of == and === but the result was unexcpected for
me. And I hope it is also for you. The result is simply "true". Why is it
true? I guess this happens because of the conversion from 'PHP' to a
number which will be 0 in PHP. And of course 0 equals 0. There are
several points that I just want to drop into this mailinglist to discuss
about:
1. Why? :)
2. Why is PHP converting the String into a Number instead of converting
the Number into a String? (If my guess concerning the behaviour is
correct)
3. Why is PHP throwing data away which has the developer explicit given
to the interpreter?
4. Why does var_dump(0 == 'PHP'); has the same result as the snippet
above? This meens that the equal operator is not explictly implemented in
the string or integer?
5. Thats a bug I have opend: https://bugs.php.net/bug.php?id=51739 where
I also had the same problems because "8315e839da08e2a7afe6dd12ec58245d"
was converted into float(INF) by throwing everything starting from
"da08.." away.
I am using PHP since the year 2000. This means I have 13 years of
experience in PHP and I really would like you to NOT just answer "works
as designed". I know it works as designed but I want to discuss the
design. Also I know that the "fuzzy" behaviour of type conversion is a
main feature of PHP. I guess this is one point which makes PHP that
successfull. But - in my opinion - the described behaviour is to fuzzy
and just confuses developers.
Best Regards
Daniel Buschke
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
Hi,
I used 2 x =. Using 3 x = would not result in that behaviour because string is
not equal to number. I am fine === here. I explicitly talk about the 2 x =
variant.
BTW:
# php -r 'var_dump("PHP" == 0);'
bool(true)
# php -r 'var_dump("PHP" == 1);'
bool(false)
regards
Daniel
-----Ursprüngliche Nachricht-----
Von: georg [mailto:georg.chamb...@telia.com]
Gesendet: Donnerstag, 13. Juni 2013 10:35
An: BUSCHKE Daniel
Cc: php-gene...@lists.php.net
Betreff: Re: [PHP] PHP is Zero
Sorry missed to post list as well
> Hi Daniel,
> here is wild goose
>
> i assume you have 3 x =
> in your "problem" formulation
> which could possibly result in the akward standard C mixup; the
> rightmost = first parsed and resulting in an ASSIGMENT to the variable
> with that value, the comes the parsing of == which is the equivalence
> test, and see; the variable is the same since it was just assigned
> that value; if this theory is correct you would get TRUE regardless
> what number is following :) /g
>
> ----- Original Message -----
> From: "BUSCHKE Daniel" <daniel.busc...@nextiraone.eu>
> To: <php-gene...@lists.php.net>
> Sent: Thursday, June 13, 2013 9:59 AM
> Subject: [PHP] PHP is Zero
>
>
>> Hi all,
>> I want to start a discussion about a PHP behaviour that drives me
>> crazy for years. For the beginning I would like you to guess what the
>> result of the following snippet will be:
>>
>> var_dump('PHP' == 0);
>>
>> I know the difference of == and === but the result was unexcpected
>> for me. And I hope it is also for you. The result is simply "true".
>> Why is it true? I guess this happens because of the conversion from
>> 'PHP' to a number which will be 0 in PHP. And of course 0 equals 0.
>> There are several points that I just want to drop into this
>> mailinglist to discuss
>> about:
>>
>> 1. Why? :)
>> 2. Why is PHP converting the String into a Number instead of
>> converting the Number into a String? (If my guess concerning the
>> behaviour is
>> correct)
>> 3. Why is PHP throwing data away which has the developer explicit
>> given to the interpreter?
>> 4. Why does var_dump(0 == 'PHP'); has the same result as the snippet
>> above? This meens that the equal operator is not explictly
>> implemented in the string or integer?
>> 5. Thats a bug I have opend: https://bugs.php.net/bug.php?id=51739
>> where I also had the same problems because "8315e839da08e2a7afe6dd12ec58245d"
>> was converted into float(INF) by throwing everything starting from
>> "da08.." away.
>>
>> I am using PHP since the year 2000. This means I have 13 years of
>> experience in PHP and I really would like you to NOT just answer
>> "works as designed". I know it works as designed but I want to
>> discuss the design. Also I know that the "fuzzy" behaviour of type
>> conversion is a main feature of PHP. I guess this is one point which
>> makes PHP that successfull. But - in my opinion - the described
>> behaviour is to fuzzy and just confuses developers.
>>
>> Best Regards
>> Daniel Buschke
>>
>> --
>> PHP General Mailing List (http://www.php.net/) To unsubscribe, visit:
>> http://www.php.net/unsub.php
>>
>
--- End Message ---
--- Begin Message ---
On 13/06/13 08:59, BUSCHKE Daniel wrote:
Hi all,
I want to start a discussion about a PHP behaviour that drives me crazy for
years. For the beginning I would like you to guess what the result of the
following snippet will be:
var_dump('PHP' == 0);
I know the difference of == and === but the result was unexcpected for me. And I hope it
is also for you. The result is simply "true". Why is it true? I guess this
happens because of the conversion from 'PHP' to a number which will be 0 in PHP. And of
course 0 equals 0. There are several points that I just want to drop into this
mailinglist to discuss about:
1. Why? :)
42
2. Why is PHP converting the String into a Number instead of converting the
Number into a String? (If my guess concerning the behaviour is correct)
Since PHP is a weakly-typed language, it has to choose one way or the
other. The behaviour *is* predictable if you know what the rule is (I'm
sure the order of conversion is documented somewhere).
3. Why is PHP throwing data away which has the developer explicit given to the
interpreter?
Because PHP is weakly-typed, the developer is not being sufficiently
explicit. Try
php -r 'var_dump(intval('PHP') == 0);'
and
php -r 'var_dump('PHP' == strval(0));'
to see explicit code. Anything less is implicit.
4. Why does var_dump(0 == 'PHP'); has the same result as the snippet above?
This meens that the equal operator is not explictly implemented in the string
or integer?
The rule is consistent: it always converts the string to an integer
whatever the order.
5. Thats a bug I have opend: https://bugs.php.net/bug.php?id=51739 where I also had the same
problems because "8315e839da08e2a7afe6dd12ec58245d" was converted into float(INF) by
throwing everything starting from "da08.." away.
That's a very different proposition, and probably has more to do with
word size: float is 32-bit, so only the first 32 bits are used and if
anything else is found the conversion falls back to INF. To handle
really big integers like 8315e839da08e2a7afe6dd12ec58245d you probably
need a more specialist library (or language)
I am using PHP since the year 2000. This means I have 13 years of experience in PHP and I really
would like you to NOT just answer "works as designed". I know it works as designed but I
want to discuss the design. Also I know that the "fuzzy" behaviour of type conversion is
a main feature of PHP. I guess this is one point which makes PHP that successfull. But - in my
opinion - the described behaviour is to fuzzy and just confuses developers.
The weak typing *is* a feature of PHP: other languages are more suitable
when you need more enforcement of types: Java, for example.
With all due respect to an experience programmer, years of experience do
not make up for a limited tool set.
Best Regards
Daniel Buschke
Cheers
Pete
--- End Message ---
--- Begin Message ---
Hi,
thanks for your answer. Especially the answer "42" made me laughing :)
My "Why" questions should be understand as "Why must it be like that" questions.
>> On 13/06/13 08:59, BUSCHKE Daniel wrote:
>> 5. Thats a bug I have opend: https://bugs.php.net/bug.php?id=51739 where I
>> also had the same problems because "8315e839da08e2a7afe6dd12ec58245d" was
>> converted into float(INF) by throwing everything starting from "da08.." away.
>>
> That's a very different proposition, and probably has more to do with word
> size: float is 32-bit, so only the first 32 bits are used and if anything
> else is found the conversion falls back to INF. To handle really big integers
> like 8315e839da08e2a7afe6dd12ec58245d you probably need a more specialist
> library (or language)
For me it is not. PHP throws things away during conversion. In my opinion a
language (compiler, interpreter whatever) should not do that. Never ever!
Either it is able to convert the value or it is not.
What about of returning "null" instead of "0" if the conversion is not perfect?
So intval('F') could return NULL and intval('0') could return 0.
Regards
Daniel
--- End Message ---
--- Begin Message ---
On 13/06/2013 11:44, BUSCHKE Daniel wrote:
Hi,
thanks for your answer. Especially the answer "42" made me laughing :)
My "Why" questions should be understand as "Why must it be like that" questions.
On 13/06/13 08:59, BUSCHKE Daniel wrote:
5. Thats a bug I have opend: https://bugs.php.net/bug.php?id=51739 where I also had the same
problems because "8315e839da08e2a7afe6dd12ec58245d" was converted into float(INF) by
throwing everything starting from "da08.." away.
That's a very different proposition, and probably has more to do with word
size: float is 32-bit, so only the first 32 bits are used and if anything else
is found the conversion falls back to INF. To handle really big integers like
8315e839da08e2a7afe6dd12ec58245d you probably need a more specialist library
(or language)
For me it is not. PHP throws things away during conversion. In my opinion a
language (compiler, interpreter whatever) should not do that. Never ever!
Either it is able to convert the value or it is not.
What about of returning "null" instead of "0" if the conversion is not perfect?
So intval('F') could return NULL and intval('0') could return 0.
Regards
Daniel
I think you will have to live with this or use another language for
development - IMO it will never change because of the massive BC break
that would be produced by changing the type juggling behaviour... of
course you could always post an RFC to the dev/internals list if you
want to take this further... good luck with that!
Cheers
Rich
--- End Message ---
--- Begin Message ---
On 13/06/13 10:44, BUSCHKE Daniel wrote:
Hi,
thanks for your answer. Especially the answer "42" made me laughing :)
My "Why" questions should be understand as "Why must it be like that" questions.
On 13/06/13 08:59, BUSCHKE Daniel wrote:
5. Thats a bug I have opend: https://bugs.php.net/bug.php?id=51739 where I also had the same
problems because "8315e839da08e2a7afe6dd12ec58245d" was converted into float(INF) by
throwing everything starting from "da08.." away.
That's a very different proposition, and probably has more to do with word
size: float is 32-bit, so only the first 32 bits are used and if anything else
is found the conversion falls back to INF. To handle really big integers like
8315e839da08e2a7afe6dd12ec58245d you probably need a more specialist library
(or language)
For me it is not. PHP throws things away during conversion. In my opinion a
language (compiler, interpreter whatever) should not do that. Never ever!
Either it is able to convert the value or it is not.
What about of returning "null" instead of "0" if the conversion is not perfect?
So intval('F') could return NULL and intval('0') could return 0.
Regards
Daniel
I've had a bit of a play with your big hex number, and the problem is
much more subtle: floatval("8315e839da08e2a7afe6dd12ec58245d") is
truncated at 8315e839 because it tries to parse it as an exponential
float: floatval("8315e83") becomes 8.315 x 10^86, but 8.315e839 is 8.315
x 10^842 which is (as far as PHP is concerned) an infinitely large number!
So we try replacing that first 'e' with a 'd' (for example) and then
php -r 'var_dump(floatval("8315d839da08e2a7afe6dd12ec58245d"));'
returns
float(8315)
It gives up when it finds a non-numeric character (as the documentation
would tell you)
Perhaps what you need is
php -r 'var_dump(floatval(0x8315e839da08e2a7afe6dd12ec58245d));'
float(1.7424261578436E+38)
In other words, you need to tell the interpreter that you have a number
(in base-16) rather than a string.
A proper strongly-typed language would just tell you that it's nonsense...
Cheers
Pete
--- End Message ---
--- Begin Message ---
Hi,
> It gives up when it finds a non-numeric character (as the documentation would
> tell you)
Why is PHP doing that? I know it works as designed and I know it is documented
like this but that does not mean that it is a good feature, does it? So lets
talk about the question: Is that behaviour awaited by PHP software developers?
Is that really the way PHP should work here? May we should change that?!
BTW: I talked to some collegues and friends since my first post. They all
guessed that "'PHP' == 0" is false within a few seconds. I think the
weak-typed-PHP is a little to weak at this point.
Regards
Daniel
--- End Message ---
--- Begin Message ---
To be more technical:
If intval('8315e839da08e2a7afe6dd12ec58245d') would return NULL instead of 8315
then PHP would be still weak-typed and the developer could know that the
conversion failed. Good idea? Of course NULL should be transparent in
operations like +. So 0 + NULL should be still 0.
Regards
Daniel
-----Ursprüngliche Nachricht-----
Von: BUSCHKE Daniel
Gesendet: Donnerstag, 13. Juni 2013 13:28
An: 'Pete Ford'; php-gene...@lists.php.net
Betreff: AW: AW: [PHP] PHP is Zero
Hi,
> It gives up when it finds a non-numeric character (as the documentation would
> tell you)
Why is PHP doing that? I know it works as designed and I know it is documented
like this but that does not mean that it is a good feature, does it? So lets
talk about the question: Is that behaviour awaited by PHP software developers?
Is that really the way PHP should work here? May we should change that?!
BTW: I talked to some collegues and friends since my first post. They all
guessed that "'PHP' == 0" is false within a few seconds. I think the
weak-typed-PHP is a little to weak at this point.
Regards
Daniel
--- End Message ---
--- Begin Message ---
I agree with you that this is a confusing and error-prone behavior, but I
also agree with Richard Gray, I wouldn't try to change this for the same
reason that a "1+1=3" shouldn't be touched if it's "correct" on a huge
amount of existing codebases...
On Thu, Jun 13, 2013 at 8:49 AM, BUSCHKE Daniel <
daniel.busc...@nextiraone.eu> wrote:
> To be more technical:
>
> If intval('8315e839da08e2a7afe6dd12ec58245d') would return NULL instead of
> 8315 then PHP would be still weak-typed and the developer could know that
> the conversion failed. Good idea? Of course NULL should be transparent in
> operations like +. So 0 + NULL should be still 0.
>
> Regards
> Daniel
>
> -----Ursprüngliche Nachricht-----
> Von: BUSCHKE Daniel
> Gesendet: Donnerstag, 13. Juni 2013 13:28
> An: 'Pete Ford'; php-gene...@lists.php.net
> Betreff: AW: AW: [PHP] PHP is Zero
>
> Hi,
>
> > It gives up when it finds a non-numeric character (as the documentation
> would tell you)
>
> Why is PHP doing that? I know it works as designed and I know it is
> documented like this but that does not mean that it is a good feature, does
> it? So lets talk about the question: Is that behaviour awaited by PHP
> software developers? Is that really the way PHP should work here? May we
> should change that?!
>
> BTW: I talked to some collegues and friends since my first post. They all
> guessed that "'PHP' == 0" is false within a few seconds. I think the
> weak-typed-PHP is a little to weak at this point.
>
> Regards
> Daniel
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
On 13 Jun 2013, at 12:27, BUSCHKE Daniel <daniel.busc...@nextiraone.eu> wrote:
> Hi,
>
>> It gives up when it finds a non-numeric character (as the documentation
>> would tell you)
>
> Why is PHP doing that? I know it works as designed and I know it is
> documented like this but that does not mean that it is a good feature, does
> it? So lets talk about the question: Is that behaviour awaited by PHP
> software developers? Is that really the way PHP should work here? May we
> should change that?!
>
> BTW: I talked to some collegues and friends since my first post. They all
> guessed that "'PHP' == 0" is false within a few seconds. I think the
> weak-typed-PHP is a little to weak at this point.
I don't know what the actual reasoning is; if you want that I suggest you ask
on the internals list, but be careful how you phrase the question. If it's pure
curiosity then that's fine, but whether you agree with the reasoning or not
it's gone way past the point where it can be changed.
My take it that the behaviour is perfectly reasonable. When you compare two
different types it has to convert one of them. If you're comparing a string to
a number it seems logical to me that the number should be the preferred type,
so the string gets converted. What would you expect array(5) == 5 to give you?
Would you expect the 5 to be converted in to an array? No. The reason it looks
odd for "PHP" == 0 is that there's no reason why the 0 should not be converted
to "0", except that strings and numbers are not the only types available and
there has to be an order of precedence. And consistency is key.
As for how strings get converted to numbers I have no idea why it will take
everything up to the first non-e|E|. character. The documentation[1] simply
states the behaviour and doesn't go in to why. However, I have to ask why it
matters? Why would you want to convert '8315e839da08e2a7afe6dd12ec58245d' to an
integer? If you have code that's juggling it automatically, be more explicit.
It's fine to be interested in the reasons why it does what it does, but if it's
causing you problems then the issue is with your code not being explicit
enough, not PHP.
-Stuart
[1] http://php.net/language.types.string#language.types.string.conversion
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
Just found out that MySQL uses the same implicit conversion precedence on
SQL clauses. That shows me that possibly exists some "higher order" rule
that states this consistency, and changing that is outside the scope of PHP.
On Thu, Jun 13, 2013 at 9:20 AM, Stuart Dallas <stu...@3ft9.com> wrote:
> On 13 Jun 2013, at 12:27, BUSCHKE Daniel <daniel.busc...@nextiraone.eu>
> wrote:
>
> > Hi,
> >
> >> It gives up when it finds a non-numeric character (as the documentation
> would tell you)
> >
> > Why is PHP doing that? I know it works as designed and I know it is
> documented like this but that does not mean that it is a good feature, does
> it? So lets talk about the question: Is that behaviour awaited by PHP
> software developers? Is that really the way PHP should work here? May we
> should change that?!
> >
> > BTW: I talked to some collegues and friends since my first post. They
> all guessed that "'PHP' == 0" is false within a few seconds. I think the
> weak-typed-PHP is a little to weak at this point.
>
> I don't know what the actual reasoning is; if you want that I suggest you
> ask on the internals list, but be careful how you phrase the question. If
> it's pure curiosity then that's fine, but whether you agree with the
> reasoning or not it's gone way past the point where it can be changed.
>
> My take it that the behaviour is perfectly reasonable. When you compare
> two different types it has to convert one of them. If you're comparing a
> string to a number it seems logical to me that the number should be the
> preferred type, so the string gets converted. What would you expect
> array(5) == 5 to give you? Would you expect the 5 to be converted in to an
> array? No. The reason it looks odd for "PHP" == 0 is that there's no reason
> why the 0 should not be converted to "0", except that strings and numbers
> are not the only types available and there has to be an order of
> precedence. And consistency is key.
>
> As for how strings get converted to numbers I have no idea why it will
> take everything up to the first non-e|E|. character. The documentation[1]
> simply states the behaviour and doesn't go in to why. However, I have to
> ask why it matters? Why would you want to convert
> '8315e839da08e2a7afe6dd12ec58245d' to an integer? If you have code that's
> juggling it automatically, be more explicit. It's fine to be interested in
> the reasons why it does what it does, but if it's causing you problems then
> the issue is with your code not being explicit enough, not PHP.
>
> -Stuart
>
> [1] http://php.net/language.types.string#language.types.string.conversion
>
> --
> Stuart Dallas
> 3ft9 Ltd
> http://3ft9.com/
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
Il Thu, 13 Jun 2013 13:27:51 +0200, BUSCHKE Daniel ha scritto:
> Why is PHP doing that?
Because a decision had to be made, and they chose to do it that way.
> I know it works as designed and I know it is
> documented like this but that does not mean that it is a good feature,
> does it?
It is a political decision. In a weakly typed language (by design) you
have to decide how to convert types. it is documented:
http://www.php.net/manual/en/language.types.type-juggling.php
http://www.php.net/manual/en/
language.types.string.php#language.types.string.conversion
If you need stricter conversions, you can cast whatever you want to
whatever else, and use ===
> So lets talk about the question: Is that behaviour awaited by
> PHP software developers?
Yes. At least for me.
> Is that really the way PHP should work here?
Yes. By design.
> May we should change that?!
No. It would break backwards compatibility. A lot. And it would make PHP
a strongly typed language.
> BTW: I talked to some collegues and friends since my first post. They
> all guessed that "'PHP' == 0" is false within a few seconds. I think the
> weak-typed-PHP is a little to weak at this point.
Maybe because they are used to other languages.
Javascript has similar rules, but Python has different ones, as it is NOT
weakly typed, just dinamically typed.
You just have to enter a different mindset. PHP is not Java or Python. It
is PHP. You should use the way it was designed, not by any other
languages rules.
One of the reasons I prefer PHP over Python is because it is weakly typed
(another is the spaces-tab-madness)
Bye.
--- End Message ---
--- Begin Message ---
On Thu, Jun 13, 2013 at 1:49 PM, BUSCHKE Daniel <
daniel.busc...@nextiraone.eu> wrote:
> To be more technical:
>
> If intval('8315e839da08e2a7afe6dd12ec58245d') would return NULL instead of
> 8315 then PHP would be still weak-typed and the developer could know that
> the conversion failed. Good idea? Of course NULL should be transparent in
> operations like +. So 0 + NULL should be still 0.
>
> Regards
> Daniel
>
>
It would just break too much. I see lots of scripts that have things like
this:
$var = '12 beers';
echo $var + 4;
and they expect it to be 16 of course.
Or what about badly trimmed strings, when reading from a file it can
include extra line endings and it's so much easier to just ignore that
because PHP will convert it just fine.
- Matijn
--- End Message ---
--- Begin Message ---
Hi,
On Thu, Jun 13, 2013 at 1:19 AM, dealTek <deal...@gmail.com> wrote:
> Hi all,
>
> I'm curious of a simple, common, universal way to detect a mobile user so
> I can redirect them to a mobile directory...
>
> What is best for this: Javascript - CSS - PHP?
>
> I think for my purposes if I can detect screen size or mobile browser
> agent - that would be good enough for what I need right now.
>
> Thanks in advance - Dave
>
>
In my personnal experiences, I've used varnish (for caching mainly) and
for mobile redirection purpose. A few line in your vcl configuration and
there you go. You can even put a rules to indicate that if there is a GET
parameter or a cookie, you don't redirect the user.
It means that you can simply add a link on your mobile website to send
the user back on the desktop website if he prefers.
I like this approach as it is directly on your first frontend (or load
balancer) and you don't even need to load you php app to redirect the
user.
Regards,
--
bacardi55 (bacardi55.org)
--- End Message ---
--- Begin Message ---
On Thu, Jun 13, 2013 at 3:17 AM, Paul M Foster <pa...@quillandmouse.com>wrote:
> On Wed, Jun 12, 2013 at 04:19:50PM -0700, dealTek wrote:
>
> > Hi all,
> >
> > I'm curious of a simple, common, universal way to detect a mobile user
> so I can redirect them to a mobile directory...
> >
> > What is best for this: Javascript - CSS - PHP?
> >
> > I think for my purposes if I can detect screen size or mobile browser
> agent - that would be good enough for what I need right now.
>
> This is not really a PHP question. I understand your asking it, though.
> Does anyone know of a better list or whatever for generic web designer
> questions?
>
> To your question, there are two problems: 1) Looking for a browser
> signature is a needle/haystack proposition, and the haystack is
> enormous, and it gets bigger every time a new phone/tablet model comes
> out; 2) Screen size used to be a good indicator, but as I feared when
> people first started using screen resolution as the main indicator, the
> screens on mobile devices have become progressively more and more
> capable. Some of them are better than many desktops I've seen.
>
> So I'd be interested in the answer to the question myself.
>
> Paul
>
>
HI,
Even though the list gets bigger, there aren't that many mobile operating
systems. Any Android device will have Android in it's user agent, and
iPhone as iPhone in the User Agent string.
If you want to check for tablets, you can check for iPad specifically (it
is in the user agent), and for Android, I believe that mobile devices have
'Mobile' in the user agent string, and tablets don't.
Then there is ofcourse the small 1 percent or so Blackberry & WP users,
which can probably be detected easily too with their user agent.
Cheers,
Matijn
--- End Message ---
--- Begin Message ---
On Thu, Jun 13, 2013 at 3:20 PM, Matijn Woudt <tijn...@gmail.com> wrote:
>
>
>
> On Thu, Jun 13, 2013 at 3:17 AM, Paul M Foster <pa...@quillandmouse.com>wrote:
>
>> On Wed, Jun 12, 2013 at 04:19:50PM -0700, dealTek wrote:
>>
>> > Hi all,
>> >
>> > I'm curious of a simple, common, universal way to detect a mobile user
>> so I can redirect them to a mobile directory...
>> >
>> > What is best for this: Javascript - CSS - PHP?
>> >
>> > I think for my purposes if I can detect screen size or mobile browser
>> agent - that would be good enough for what I need right now.
>>
>> This is not really a PHP question. I understand your asking it, though.
>> Does anyone know of a better list or whatever for generic web designer
>> questions?
>>
>> To your question, there are two problems: 1) Looking for a browser
>> signature is a needle/haystack proposition, and the haystack is
>> enormous, and it gets bigger every time a new phone/tablet model comes
>> out; 2) Screen size used to be a good indicator, but as I feared when
>> people first started using screen resolution as the main indicator, the
>> screens on mobile devices have become progressively more and more
>> capable. Some of them are better than many desktops I've seen.
>>
>> So I'd be interested in the answer to the question myself.
>>
>> Paul
>>
>>
> HI,
>
> Even though the list gets bigger, there aren't that many mobile operating
> systems. Any Android device will have Android in it's user agent, and
> iPhone as iPhone in the User Agent string.
> If you want to check for tablets, you can check for iPad specifically (it
> is in the user agent), and for Android, I believe that mobile devices have
> 'Mobile' in the user agent string, and tablets don't.
>
> Then there is ofcourse the small 1 percent or so Blackberry & WP users,
> which can probably be detected easily too with their user agent.
>
> Cheers,
>
> Matijn
>
I forgot to mention, in PHP the user agent string is in
$_SERVER['HTTP_USER_AGENT'], and in javascript you can find it in
navigator.userAgent.
Where you want to redirect, it's up to you. If you want it to do on first
attempt, better go with PHP so you can use Header("Location: ...") to
redirect the user immediately so the user won't notice he is being
redirected.
--- End Message ---
--- Begin Message ---
Hello,
I stumbled upon this the other day :
http://mobiledetect.net/
I haven't tried it yet, since I have my own small user agent parser when I
need it, but it may help you if it's a pure php solution you're looking for.
Have a nice day
2013/6/13 dealTek <deal...@gmail.com>
> Hi all,
>
> I'm curious of a simple, common, universal way to detect a mobile user so
> I can redirect them to a mobile directory...
>
> What is best for this: Javascript - CSS - PHP?
>
> I think for my purposes if I can detect screen size or mobile browser
> agent - that would be good enough for what I need right now.
>
> Thanks in advance - Dave
>
>
> --
> Thanks,
> Dave - DealTek
> deal...@gmail.com
> [db-3]
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Camille Hodoul
http://camille-hodoul.com/
--- End Message ---
--- Begin Message ---
http://php.net/manual/en/misc.configuration.php#ini.browscap
http://tempdownloads.browserscap.com/
$browser = get_browser(null, TRUE);
if (isset($browser['ismobiledevice']) && ($browser['ismobiledevice'] == TRUE)) {
$isMobile = TRUE;
}
else {
$isMobile = FALSE;
}
unset($browser);
--- End Message ---
--- Begin Message ---
Hi.
I'm building a class which needs to have certain methods called by the
subclass, but the subclass can extend but not obscure/override the
behaviour.
So, for example, a method AuthRequestMade() will record the activity of
making an authorisation request. It cannot make the actual request as that
is the subclass's job, but, no matter what, I need to have this method
called with the result of the actual auth request.
I want to make building the subclasses as simple and as fool proof as
possible.
I think I have to do something like this ...
interface AuthEnforcer{
public function AuthRequestMade(&$i_State, &$s_Message);
}
abstract class Auth implements AuthEnforcer{
public method MakeAuthRequest(){
// Do my stuff before.
// Call the SpecificAuth class
$this->AuthRequestMade($i_State, $s_Message);
// Do my stuff after with state and message.
}
}
class SpecificAuth extends Auth{
public function AuthRequestMade(&$i_State, &$s_Message){
// Do my specific stuff, setting state and message.
}
}
But a couple of things I don't like (and don't know how to avoid).
1 - The SpecificAuth::AuthRequestMade is public and I want it protected as
it shouldn't be called from the public scope.
2 - The response is by ref, but I think having a AuthResponse class
containing $i_State and $s_Message should be enough there, but no way to
enforce return types in PHP.
Any ideas?
Thank you.
--
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY
--- End Message ---
--- Begin Message ---
Hi Richard,
On Thu, Jun 13, 2013 at 10:16 AM, Richard Quadling <rquadl...@gmail.com>wrote:
> I'm building a class which needs to have certain methods called by the
> subclass, but the subclass can extend but not obscure/override the
> behaviour.
>
This is the Template Method pattern, though in this case you could use a
Strategy where the specific authentication implementation is in a separate
class that gets injected into the Auth class. As for your example there a a
few things I would change.
* The template method that the subclass must implement should not be
declared by an interface. Interfaces are for declaring public contracts.
You can simply declare an abstract, protected method in Auth. This is the
contract that every subclass must fulfill.
* I would avoid reference variables as you've indicated. If you don't want
to build a data-holder class yet, simply return an array for now. While you
cannot enforce the return type at parse time, they should be verified with
unit tests. Unit tests are critical with dynamic languages like PHP and
Python since runtime is the only way to verify behavior.
Otherwise, your example is spot on, though the name AuthRequestMade implies
the request has already been made yet I think from your description that
this method should *make* the actual request. Here's how I would write it
with the above in place.
class Auth {
public function MakeAuthRequest() {
// before
$this->MakeAuthRequestImpl(); // Adding "Impl" suffix is a
common convention
// after
}
/**
* Make the actual authentication request.
*
* @return array Must contain keys "state" and "message" to hold
the result
*/
protected abstract function MakeAuthRequestImpl();
}
Peace,
David
--- End Message ---
