date:20120227

On Sat, Feb 25, 2012 at 3:27 PM, Olivier Doucet webmas...@ajeux.com wrote:

 Hello everyone,

 By reading run-tests.php source code, I can see that a JUNIT XML file can
 be easily built in 'make test'.
 This contains all succeeded, failed and skipped tests with diffs.


Yep, we even have an improved version (running on ci.qa.php.net currently)
thanks to Shein (
https://github.com/Tyrael/ci.qa.php.net/commits/master/run-tests.php) which
still needs to be merged to the svn.



 I wondered if we can modify run-tests.php to automatically build this file
 each time, and when the user is asked to send report, send this XML report
 as well to QA report interface. This would give us the following :
 - list of succeeded tests (to know if one test is 100% failing or not)
 - better diff parsing (some glitches in current implementation due to email
 format when you send a qa-report).


we could, but I think that would require a clear consensus from the
qa/internals group.
I remember we also had some problems with the diffs (having whitespace
chars not allowed in CDATA, or something like that)




 I also would like to add a special env variable to be able to send the QA
 report automatically : we would be able to have more QA reports this way
 (and also add ci.qa.php.net reports too in qa.php.net/reports/ interface
 easily).


this would be also easy(setting the email sending on by default), but I
remember somebody mentioning that we don't want to be spammed with the
reports, and it would create some problem, as the current report contains
sensitive system specific informations.

ps: you can currently grab the junit.xml's from ci.qa.php.net if you want (
http://ci.qa.php.net/job/php-src-5.3-matrix-build/344/architecture=x86,os=bsd-freebsd-8.2/artifact/junit.xml
for
example)

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache

2012-02-27 Thread jpauli

PHP through mod_php on Linux should compile without ZTS.

configure script searches for apxs binary and tries to invoque apxs -q
MPM to figure out what MPM has been compiled in Apache for the TS flag to
be defined or not (thus, activating PHP ZTS, or not).

Mainly on Linux, Apache should have been installed with prefork MPM ans
apxs -q should return that, then configure should not define
PHP_BUILD_THREAD_SAFE.

Recently we had a bug with the new Apache 2.4 API where apxs doesn't answer
about the MPM configuration anymore, leading to a ZTS build by default.
This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172.

I dont know anything about windows, sorry

Julien.Pauli

On Fri, Feb 24, 2012 at 10:04 PM, Richard Lynch c...@l-i-e.com wrote:

 On Fri, February 24, 2012 1:52 pm, Tom Boutell wrote:
  2. Why does php turn on thread-safety for mod_php at all on Linux,
  given that it apparently still doesn't work very well with various
  extensions in a genuinely multithreaded situation, slows things down,
  takes more memory, and leads to problems like this one?

 I can't recall who, but I have heard people who claim to run
 multi-threaded on Linux, but with a heck of a lot of stress testing,
 and a rigid control on minimal extensions added...

 So apparently *somebody* uses it.

 --
 brain cancer update:
 http://richardlynch.blogspot.com/search/label/brain%20tumor
 Donate:

 https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] APXS LoadModule Option in configure

2012-02-27 Thread jpauli

On Mon, Feb 27, 2012 at 2:27 AM, Kris Craig kris.cr...@gmail.com wrote:

 Ok, I've updated the RFC based on input received here.  I also made a
 decision on the APXS vs. APXS2 question; please refer to the RFC for
 details.  If anybody has any objections to this decision, now would be the
 time to say something!

 I've targetted this for 5.4.1 so this won't have any bearing on the
 upcoming 5.4.0 release.  If I don't hear any new objections, I plan to
 initiate the vote sometime early this week.


 https://wiki.php.net/rfc/apxs-loadmodule

 --Kris

 Heh, I like the idea the RFC is about.
Having one or several configuration files is just a matter of taste and
should be decided by distros package maintainers.
This RFC is about easing their lives, which is a good idea :)

I'm +1 for not supporting Apache1.x anymore, as it's been EOL'd anyway
(like th eRFC says).

Julien.P



 On Fri, Feb 24, 2012 at 4:44 PM, Kris Craig kris.cr...@gmail.com wrote:

  Oh ok, I think I see where you're getting confused.
 
  This problem occurs when your LoadModule statement is in a
 *separate*.conf file; i.e. using the Include statement.  APXS cannot
 detect this
  and just sticks a LoadModule into the main .conf file.  This is what
 causes
  the duplication.  It's a very common issue as many people (myself
 included)
  prefer to keep their PHP configurations separate.
 
  --Kris
 
 
 
  On Fri, Feb 24, 2012 at 4:42 PM, Christopher Jones 
  christopher.jo...@oracle.com wrote:
 
 
 
  On 02/24/2012 04:14 PM, Kris Craig wrote:
 
  No, it happens and it's even clearly documented in APXS.
 
  Basically, if you specify the -a option in APXS, it overwrites your
  httpd.conf (or apache.conf or whatever it is on your system) and adds
 the
  LoadModule line to it.  In PHP's configure script, you'll notice that
  -a
  is always specified; there's no option to use APXS without it.  As a
  result, make install will always overwrite your LoadModule entry in
  httpd.conf if APXS is enabled.  The problem occurs when you have
  LoadModule
  in an included .conf file already; APXS does not have the ability to
  detect
  that.  Therefore, a duplicate LoadModule entry is added to httpd.conf
  by
  APXS, and thus the clash occurs.  This behavior has been reproduced
  numerous times.
 
 
  I can start with a LoadModule line, run the exact apxs command that
  the PHP Makefile executes and I still have only one LoadModule in the
  file.  Note the time stamp of the file changes.
 
   cjones:~/phpbuild/php53 $ ls -l /home/cjones/apache22/conf/**httpd.conf
   -rw-r--r-- 1 cjones cjones 13998 2012-02-24 16:30
  /home/cjones/apache22/conf/**httpd.conf
 
   cjones:~/phpbuild/php53 $ grep libphp5 /home/cjones/apache22/conf/**
  httpd.conf
   LoadModule php5_modulemodules/libphp5.so
 
   cjones:~/phpbuild/php53 $ /home/cjones/apache22/bin/apxs -S
  LIBEXECDIR=/home/cjones/**apache22/modules -S
 SYSCONFDIR=/home/cjones/**apache22/conf
  -i -a -n php5 libphp5.la
   /home/cjones/apache22/build/**instdso.sh
 SH_LIBTOOL='/home/cjones/**apache22/build/libtool'
  libphp5.la /home/cjones/apache22/modules
   /home/cjones/apache22/build/**libtool --mode=install cp
 libphp5.la/home/cjones/apache22/modules/
   cp .libs/libphp5.so /home/cjones/apache22/modules/**libphp5.so
   cp .libs/libphp5.lai /home/cjones/apache22/modules/**libphp5.la
 http://libphp5.la
   libtool: install: warning: remember to run `libtool --finish
  /home/cjones/phpbuild/php53 /libs'
   chmod 755 /home/cjones/apache22/modules/**libphp5.so
   [activating module `php5' in /home/cjones/apache22/conf/**httpd.conf]
 
   cjones:~/phpbuild/php53 $ ls -l /home/cjones/apache22/conf/**httpd.conf
   -rw-r--r-- 1 cjones cjones 13998 2012-02-24 16:33
  /home/cjones/apache22/conf/**httpd.conf
 
   cjones:~/phpbuild/php53 $ grep libphp5 /home/cjones/apache22/conf/**
  httpd.conf
   LoadModule php5_modulemodules/libphp5.so
 
  I could interpolate the apxs -a documentation that says or by
  enabling it if it already exists to support what I see.
 
  Good luck with your RFC,
 
  Chris
 
 
  --
  Email: christopher.jo...@oracle.com
  Tel:  +1 650 506 8630
  Blog:  http://blogs.oracle.com/opal/
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

2012-02-27 Thread Michael Morris

What I've wanted for awhile, but don't know what the implementation
problems would be, is to allow for two new variable types to solve
this problem - Strict and tolerant variables.  Both of these must be
declared formally (otherwise PHP assumes scalar) and the datatype must
be included. The syntax

// A tolerant variable.
integer $a = 3;

// A strict variable
strict integer $b = 2;

Tolerant variables silently cast values to their declared datatype.
Maybe they should raise E_NOTICE?
Strict variables refuse to be assigned a value with an incorrect
datatype.  Raise E_WARNING?

A strict function would have the current behavior of kicking a warning
when the type hinting fails.  Otherwise, functions should be tolerant
-

function foo ( integer $a, string $b, $c ) {}

strict function foo ( integer $a, $string $b, $c ) {}

A function parameter without a datatype would be ignored.

This does open the door to function overloading, but the engine
problems of this are well documented and have been discussed.  Still,
I don't think it's a bad thing to have a syntax that allows for method
overloading in the future.

On Sun, Feb 26, 2012 at 10:52 PM, Kris Craig kris.cr...@gmail.com wrote:
 I'll try to find some time tonight to create that for ya.

 Once this discussion comes together a little bit more and we have at least
 a vague-ish idea what direction we're moving in, I'll also go ahead and
 create an RFC as well so we have a conceptual product to build on.

 --Kris


 On Sun, Feb 26, 2012 at 6:27 PM, Samuel Deal samuel.d...@gmail.com wrote:

 Hi,

 I create a new thread to discuss about Scalar type hinting.

 Following the John Crenshaw proposed terminology:
  - Strict Typing means the super strict old C style typing that has
 been proven to be ridiculous in this environment because of the obvious
 problems inherent in the fact that almost every input is a string.
  - Weak Typing means types in the same sense that the PHP documentation
 uses types (for example, the docs indicate substr(string, integer), and
 substr(12345, 2) == 345.)
  - No Scalar Typing should be used to indicate the current system
 (where there is no provision for hinting at scalar types.)

 Previous weak typing proposal could be found here :
 https://wiki.php.net/rfc/typechecking

 I have no rights to edit the wiki and make a summary of previous
 arguments, so if someone could create it...


 --
 Samuel DEAL
 samuel.d...@gmail.com



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting

On Sun, February 26, 2012 9:48 am, Anthony Ferrara wrote:

I have to say that no matter how much a luv my OOP, turning every
built-in type into an Object is just a Bad Idea...

It's a form of bloat on RAM and CPU with minimal added value, imho.

No matter which way you twist this pretzel:

-1

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting

On Sun, February 26, 2012 8:45 pm, Anthony Ferrara wrote:
 Or operator-overlading to the rescue? :-)

 Not quite.  Especially because with operator overloading done at this
 level (how it would be implemented in PHP) it's almost impossible to
 make it consistent:

 class string {
 public function overload+($mixed) {
 return $this-value + $mixed;

I think you meant '.' here instead of '+'

Otherwise, PHP type juggling will make it be 10 as well.

 }
 }
 class Integer {
 public function overload+($mixed) {
 return $this-value + $mixed;
 }
 }

 $int = new Integer(5);
 $string = new String(5);

 echo $int + $string; // 10
 echo $string + $int; // 55

 While I like the concept of overloading, I don't really think it's
 solvable in a consistent enough manner that it would work here.

That said, there is no inconsistency.

If what you want to do is overload + on strings to do concatenation,
then it's on you to typecast everything to (string) for it to make
sense.

Oh, and string is a reserved word, so this won't work as-is, though
that's obviously picuyane.


-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bugs.php.net php 6

On Sun, February 26, 2012 2:03 am, Stas Malyshev wrote:
 Just discovered that our stock php 4 support discontinued message in
 bugs looks like:

 We are sorry, but we can not support PHP 4 related problems anymore.
 Momentum is gathering for PHP 6, and we think supporting PHP 4 will
 lead to a waste of resources which we want to put into getting PHP 6
 ready.

 Unless I've missed something, the momentum for php 6 is very much
 nonexistent, so we probably want to fix that message :)

Isn't the emotional scarring of PHP 6 == Unicode far enough in the
past to start some momentum for PHP 6?

I sure core Devs have thought about this, and have gone so far as to
make statements for what should be in PHP 6...

PS
If it isn't already, I want to write an RFC to change the default
error_reporting to include E_NOTICE.

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting

 I have to say that no matter how much a luv my OOP, turning every
 built-in type into an Object is just a Bad Idea...

 It's a form of bloat on RAM and CPU with minimal added value, imho.

 No matter which way you twist this pretzel:

 -1

Re-read what I had written.  I never said to turn every built-in type
into an object.  In fact, what I was talking about was keeping and
preserving the base types as-is.  All that I was proposing was adding
the ability to cast from and to the primitives.  That way you could
silently convert back and forth as needed (transparently when
possible).

So what it sounds like you're -1ing to, is not actually what was proposed...

I'm starting to work on a patch for this as a proof of concept...

Anthony

On Mon, Feb 27, 2012 at 10:08 AM, Richard Lynch c...@l-i-e.com wrote:
 On Sun, February 26, 2012 9:48 am, Anthony Ferrara wrote:

 I have to say that no matter how much a luv my OOP, turning every
 built-in type into an Object is just a Bad Idea...

 It's a form of bloat on RAM and CPU with minimal added value, imho.

 No matter which way you twist this pretzel:

 -1

 --
 brain cancer update:
 http://richardlynch.blogspot.com/search/label/brain%20tumor
 Donate:
 https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/Zend/zend_API.c trunk/NEWS trunk/Zend/zend_API.c

On Mon, February 27, 2012 2:31 am, Laruence wrote:
 On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov dmi...@zend.com
 wrote:
 Hi Laruence,

 The attached patch looks wired. The patch on top of it (r323563)
 makes it
 better. However, in my opinion it fixes a common problem just in a
 single
 place. Each call to __toString() that makes side effects may cause
 the
 similar problem. It would be great to make a right fix in
 zend_std_cast_object_tostring() itself, but probably it would
 require API
 Hi:
before this fix, I thought about the same idea of that.

but,  you know,  such change will need all exts who implmented
 their own cast_object handler change there codes too.

for now,  I exam the usage of std_cast_object_tostring,  most of
 them do the similar things like this fix to avoid this issues(like
 ZEND_CAST handler).

so I think,  maybe it's okey for a temporary fix :)

Perhaps a better solution would be to make a NEW function that uses
zval** and deprecate the old one with memory leaks.

Old extensions remain functional, new extension consume less memory.

(This presumes I actually understand the issue, which is questionable.)

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

2012-02-27 Thread Arvids Godjuks

Michael Morris,

Type hinting means that we have hints when declaring function/method
signatures, example:

functiion do(int $someVal) {}
function doOther(string $str, mixed $pos = null) {}

As I remember, there was never a discussion about adding type hints
when declaring vars. The original discussion was and is about
finishing the support for type hints because PHP allready has
typehinting for arrays and objects. Additionaly there was launched a
discussion about function/method return typehints.
I do think the variable declaration type hints are pointless because
variables are chaning their types on the fly. But mostly it will
polute current discussion even more and adds a whole new super-global
level of thinking through and implementation details. It's just too
much.
We had type hinting  discussions for a few years now and never reached
any conclusion and patches that have been made still had lots of
problems. We should really focus on param type hints and maybe on
return type hints for now and see where it takes us.

Because the new thread has been created, I will leave my arguments
here for the record.

I, as a user land developer, would like the weak type hinting, which
takes care of transparent conversions where no data loss is happening.
I would like to get a E_NOTICE or E_WARNING when some loss is
happening (for example I pass a string aaa, but function expects an
integer or double. It would convert it to 1, but also will emit the
warning/notice for me to inspect what went wrong). And fatal errors on
serious type miss match like it is now done with objects and arrays.
This way is 100% backwards compatible, it does not add a ton of new
rules to remember when write code and is based on the mechanics PHP
already has, just extended a little. Same goes for the return type
hints.
The only case I do not remember being discussed in detail (maybe it
was and I somehow missed that part) is when we accept (and return for
return type hints) a mixed type param. Is it somehow described or we
just leave out the type hints at all. It's not so rare to see
something like this: function do(string $str = null). By logic it
accepts 2 types - null and string, but type hint says it accepts only
string and doing a call do(null) should work despite the type hint.

My 2 cents.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bugs.php.net php 6

2012-02-27 Thread Simon Schick

Hi, Richard

The development of the unicode-as-default-charset should really be done
within the next release coming after 5.4
I heared somewhere that it's nearly done ...
I would have happily seen it in 5.4 but as this release is late right now
we have to wait ;)

Bye
Simon

p.s. *
http://www.php.net/manual/en/function.error-reporting.php#refsect1-function.error-reporting-changelog
*http://www.php.net/manual/en/function.error-reporting.php#refsect1-function.error-reporting-changelog


2012/2/27 Richard Lynch c...@l-i-e.com

 On Sun, February 26, 2012 2:03 am, Stas Malyshev wrote:
  Just discovered that our stock php 4 support discontinued message in
  bugs looks like:
 
  We are sorry, but we can not support PHP 4 related problems anymore.
  Momentum is gathering for PHP 6, and we think supporting PHP 4 will
  lead to a waste of resources which we want to put into getting PHP 6
  ready.
 
  Unless I've missed something, the momentum for php 6 is very much
  nonexistent, so we probably want to fix that message :)

 Isn't the emotional scarring of PHP 6 == Unicode far enough in the
 past to start some momentum for PHP 6?

 I sure core Devs have thought about this, and have gone so far as to
 make statements for what should be in PHP 6...

 PS
 If it isn't already, I want to write an RFC to change the default
 error_reporting to include E_NOTICE.

 --
 brain cancer update:
 http://richardlynch.blogspot.com/search/label/brain%20tumor
 Donate:

 https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

Hi,

PHP is no strickt-typed language. Changing this is a massive change, if
you want to go there: There are plenty of other languages.

If you want this to be an optional feature:
a) It's not optional (one has to maintain code written by others, uses
libraries, frameworks, ...)
b) It causes a hell lot of trouble with copy-on-write. going from
fixed-typed to non-fixed-typed variables (in a funciton call or
assignment or such) will always have to cause a copy. This will hurt the
performance in hardly predictable ways.

johannes

On Mon, 2012-02-27 at 09:29 -0500, Michael Morris wrote:
 What I've wanted for awhile, but don't know what the implementation
 problems would be, is to allow for two new variable types to solve
 this problem - Strict and tolerant variables.  Both of these must be
 declared formally (otherwise PHP assumes scalar) and the datatype must
 be included. The syntax
 
 // A tolerant variable.
 integer $a = 3;
 
 // A strict variable
 strict integer $b = 2;
 
 Tolerant variables silently cast values to their declared datatype.
 Maybe they should raise E_NOTICE?
 Strict variables refuse to be assigned a value with an incorrect
 datatype.  Raise E_WARNING?
 
 A strict function would have the current behavior of kicking a warning
 when the type hinting fails.  Otherwise, functions should be tolerant
 -
 
 function foo ( integer $a, string $b, $c ) {}
 
 strict function foo ( integer $a, $string $b, $c ) {}
 
 A function parameter without a datatype would be ignored.
 
 This does open the door to function overloading, but the engine
 problems of this are well documented and have been discussed.  Still,
 I don't think it's a bad thing to have a syntax that allows for method
 overloading in the future.
 
 On Sun, Feb 26, 2012 at 10:52 PM, Kris Craig kris.cr...@gmail.com wrote:
  I'll try to find some time tonight to create that for ya.
 
  Once this discussion comes together a little bit more and we have at least
  a vague-ish idea what direction we're moving in, I'll also go ahead and
  create an RFC as well so we have a conceptual product to build on.
 
  --Kris
 
 
  On Sun, Feb 26, 2012 at 6:27 PM, Samuel Deal samuel.d...@gmail.com wrote:
 
  Hi,
 
  I create a new thread to discuss about Scalar type hinting.
 
  Following the John Crenshaw proposed terminology:
   - Strict Typing means the super strict old C style typing that has
  been proven to be ridiculous in this environment because of the obvious
  problems inherent in the fact that almost every input is a string.
   - Weak Typing means types in the same sense that the PHP documentation
  uses types (for example, the docs indicate substr(string, integer), and
  substr(12345, 2) == 345.)
   - No Scalar Typing should be used to indicate the current system
  (where there is no provision for hinting at scalar types.)
 
  Previous weak typing proposal could be found here :
  https://wiki.php.net/rfc/typechecking
 
  I have no rights to edit the wiki and make a summary of previous
  arguments, so if someone could create it...
 
 
  --
  Samuel DEAL
  samuel.d...@gmail.com
 
 
 



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

2012-02-27 Thread Paul Dragoonis

2012/2/27 Johannes Schlüter johan...@schlueters.de

 Hi,

 PHP is no strickt-typed language. Changing this is a massive change, if
 you want to go there: There are plenty of other languages.

 If you want this to be an optional feature:
 a) It's not optional (one has to maintain code written by others, uses
 libraries, frameworks, ...)
 b) It causes a hell lot of trouble with copy-on-write. going from
 fixed-typed to non-fixed-typed variables (in a funciton call or
 assignment or such) will always have to cause a copy. This will hurt the
 performance in hardly predictable ways.

 johannes


Big +1 from me. Thanks for the post Johannes!

It makes sense to have a type hint for the different type of data
structures.
1) array
2) object ( class name for OOP ).

The scalar values (int, string, double) are type-less, flexible and should
remain that way. If you want strict typehinting then move to another
language.



 On Mon, 2012-02-27 at 09:29 -0500, Michael Morris wrote:
  What I've wanted for awhile, but don't know what the implementation
  problems would be, is to allow for two new variable types to solve
  this problem - Strict and tolerant variables.  Both of these must be
  declared formally (otherwise PHP assumes scalar) and the datatype must
  be included. The syntax
 
  // A tolerant variable.
  integer $a = 3;
 
  // A strict variable
  strict integer $b = 2;
 
  Tolerant variables silently cast values to their declared datatype.
  Maybe they should raise E_NOTICE?
  Strict variables refuse to be assigned a value with an incorrect
  datatype.  Raise E_WARNING?
 
  A strict function would have the current behavior of kicking a warning
  when the type hinting fails.  Otherwise, functions should be tolerant
  -
 
  function foo ( integer $a, string $b, $c ) {}
 
  strict function foo ( integer $a, $string $b, $c ) {}
 
  A function parameter without a datatype would be ignored.
 
  This does open the door to function overloading, but the engine
  problems of this are well documented and have been discussed.  Still,
  I don't think it's a bad thing to have a syntax that allows for method
  overloading in the future.
 
  On Sun, Feb 26, 2012 at 10:52 PM, Kris Craig kris.cr...@gmail.com
 wrote:
   I'll try to find some time tonight to create that for ya.
  
   Once this discussion comes together a little bit more and we have at
 least
   a vague-ish idea what direction we're moving in, I'll also go ahead and
   create an RFC as well so we have a conceptual product to build on.
  
   --Kris
  
  
   On Sun, Feb 26, 2012 at 6:27 PM, Samuel Deal samuel.d...@gmail.com
 wrote:
  
   Hi,
  
   I create a new thread to discuss about Scalar type hinting.
  
   Following the John Crenshaw proposed terminology:
- Strict Typing means the super strict old C style typing that has
   been proven to be ridiculous in this environment because of the
 obvious
   problems inherent in the fact that almost every input is a string.
- Weak Typing means types in the same sense that the PHP
 documentation
   uses types (for example, the docs indicate substr(string, integer),
 and
   substr(12345, 2) == 345.)
- No Scalar Typing should be used to indicate the current system
   (where there is no provision for hinting at scalar types.)
  
   Previous weak typing proposal could be found here :
   https://wiki.php.net/rfc/typechecking
  
   I have no rights to edit the wiki and make a summary of previous
   arguments, so if someone could create it...
  
  
   --
   Samuel DEAL
   samuel.d...@gmail.com
  
  
 



 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting

On 27/02/12 16:12, Richard Lynch wrote:
 Oh, and string is a reserved word, so this won't work as-is, though
 that's obviously picuyane. 
It's not, you can perfectly define your own class called 'string'. I'd
be much easier if it were, though.



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

2012-02-27 Thread Arvids Godjuks

But what about optional weak (auto-convert) type hints? They should
make life if not easier, definitively a little richer when writing
API's and internal stuff, where some additional strictness and
warnings generated make sense.
And it definitively makes IDE's more happy and easier to generate
PHPDoc blocks, not to mention Reflection stuff can be added and find
it's uses pretty fast.
I see it as anonymous functions - you can definitively live without
them, but they are wonderful and made some functionality better (for
example Yii Framework used eval for many things and with PHP 5.3 we
just started to use anonymous functions instead - the support was
build in before the 5.3 even started) - same I see happening here in
the future.
But yes, any major work that changes things a lot will just make a
mess and many BC issues.

2012/2/27 Paul Dragoonis dragoo...@gmail.com:
 2012/2/27 Johannes Schlüter johan...@schlueters.de

 Hi,

 PHP is no strickt-typed language. Changing this is a massive change, if
 you want to go there: There are plenty of other languages.

 If you want this to be an optional feature:
 a) It's not optional (one has to maintain code written by others, uses
 libraries, frameworks, ...)
 b) It causes a hell lot of trouble with copy-on-write. going from
 fixed-typed to non-fixed-typed variables (in a funciton call or
 assignment or such) will always have to cause a copy. This will hurt the
 performance in hardly predictable ways.

 johannes


 Big +1 from me. Thanks for the post Johannes!

 It makes sense to have a type hint for the different type of data
 structures.
 1) array
 2) object ( class name for OOP ).

 The scalar values (int, string, double) are type-less, flexible and should
 remain that way. If you want strict typehinting then move to another
 language.



 On Mon, 2012-02-27 at 09:29 -0500, Michael Morris wrote:
  What I've wanted for awhile, but don't know what the implementation
  problems would be, is to allow for two new variable types to solve
  this problem - Strict and tolerant variables.  Both of these must be
  declared formally (otherwise PHP assumes scalar) and the datatype must
  be included. The syntax
 
  // A tolerant variable.
  integer $a = 3;
 
  // A strict variable
  strict integer $b = 2;
 
  Tolerant variables silently cast values to their declared datatype.
  Maybe they should raise E_NOTICE?
  Strict variables refuse to be assigned a value with an incorrect
  datatype.  Raise E_WARNING?
 
  A strict function would have the current behavior of kicking a warning
  when the type hinting fails.  Otherwise, functions should be tolerant
  -
 
  function foo ( integer $a, string $b, $c ) {}
 
  strict function foo ( integer $a, $string $b, $c ) {}
 
  A function parameter without a datatype would be ignored.
 
  This does open the door to function overloading, but the engine
  problems of this are well documented and have been discussed.  Still,
  I don't think it's a bad thing to have a syntax that allows for method
  overloading in the future.
 
  On Sun, Feb 26, 2012 at 10:52 PM, Kris Craig kris.cr...@gmail.com
 wrote:
   I'll try to find some time tonight to create that for ya.
  
   Once this discussion comes together a little bit more and we have at
 least
   a vague-ish idea what direction we're moving in, I'll also go ahead and
   create an RFC as well so we have a conceptual product to build on.
  
   --Kris
  
  
   On Sun, Feb 26, 2012 at 6:27 PM, Samuel Deal samuel.d...@gmail.com
 wrote:
  
   Hi,
  
   I create a new thread to discuss about Scalar type hinting.
  
   Following the John Crenshaw proposed terminology:
- Strict Typing means the super strict old C style typing that has
   been proven to be ridiculous in this environment because of the
 obvious
   problems inherent in the fact that almost every input is a string.
- Weak Typing means types in the same sense that the PHP
 documentation
   uses types (for example, the docs indicate substr(string, integer),
 and
   substr(12345, 2) == 345.)
- No Scalar Typing should be used to indicate the current system
   (where there is no provision for hinting at scalar types.)
  
   Previous weak typing proposal could be found here :
   https://wiki.php.net/rfc/typechecking
  
   I have no rights to edit the wiki and make a summary of previous
   arguments, so if someone could create it...
  
  
   --
   Samuel DEAL
   samuel.d...@gmail.com
  
  
 



 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] RFC: PHP 6 include E_NOTICE in default php.ini

As promised in another thread, I have created a formal RFC on the
topic of including E_NOTICE in the default php.ini.* files.

Please note that I am specifically not proposing E_STRICT nor
E_DEPRECATED in this RFC, as I believe the each need to be considered
on their own merits, and not lumped into one decision nor even
conversation.

https://wiki.php.net/rfc/error_reporting_e_notice

My first formal RFC, so please be gentle :-)

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Enum proposal (yet another)

On 27/02/12 01:33, Kris Craig wrote:
 Exactly, hence why I'm still on the fence with that.  I was hoping for some
 further discussion though to see if anyone can think of a way around that,
 though admittedly nothing comes to my mind.

 --Kris
That's why I mentioned the possibility of having such option per file.

declare(stricttypes=1) {
// Code here
}

Or just
declare(stricttypes=1);
to apply to the whole file

Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/Zend/zend_API.c trunk/NEWS trunk/Zend/zend_API.c

Out of curiosity, why are you changing it to copy the object for the
result of the cast operation?  cast_object should init the result
zval, so why go through the step of copying the starting object to it?
 Wouldn't it be easier just to do:

if (Z_OBJ_HANDLER_PP(arg, cast_object)) {
zval *result;
ALLOC_ZVAL(result);
if (Z_OBJ_HANDLER_P(*arg, cast_object)(*arg, result, type 
TSRMLS_CC)
== SUCCESS) {
zval_ptr_dtor(arg);
*pl = Z_STRLEN_PP(result);
*p = Z_STRVAL_PP(result);
zval_ptr_dtor(result);
return SUCCESS;
}
zval_ptr_dtor(result);
}

Keeping both completely separate, and not having the possibility of
corrupting the arg object pointer?  As it is right now (with the patch
in the first mail), wouldn't the possibility still exist of nuking the
arg object pointer which could be used elsewhere (and hence cause the
memory leak and segfault when that variable is referenced again)?

(Un tested as of yet, just throwing it out there as it seems kind of
weird to overwrite the arg pointer for what seems like no reason)...

Anthony



On Mon, Feb 27, 2012 at 10:22 AM, Richard Lynch c...@l-i-e.com wrote:
 On Mon, February 27, 2012 2:31 am, Laruence wrote:
 On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov dmi...@zend.com
 wrote:
 Hi Laruence,

 The attached patch looks wired. The patch on top of it (r323563)
 makes it
 better. However, in my opinion it fixes a common problem just in a
 single
 place. Each call to __toString() that makes side effects may cause
 the
 similar problem. It would be great to make a right fix in
 zend_std_cast_object_tostring() itself, but probably it would
 require API
 Hi:
    before this fix, I thought about the same idea of that.

    but,  you know,  such change will need all exts who implmented
 their own cast_object handler change there codes too.

    for now,  I exam the usage of std_cast_object_tostring,  most of
 them do the similar things like this fix to avoid this issues(like
 ZEND_CAST handler).

    so I think,  maybe it's okey for a temporary fix :)

 Perhaps a better solution would be to make a NEW function that uses
 zval** and deprecate the old one with memory leaks.

 Old extensions remain functional, new extension consume less memory.

 (This presumes I actually understand the issue, which is questionable.)

 --
 brain cancer update:
 http://richardlynch.blogspot.com/search/label/brain%20tumor
 Donate:
 https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bugs.php.net php 6

On Mon, February 27, 2012 9:37 am, Simon Schick wrote:
 The development of the unicode-as-default-charset should really be
 done
 within the next release coming after 5.4
 I heared somewhere that it's nearly done ...
 I would have happily seen it in 5.4 but as this release is late right
 now
 we have to wait ;)

I was off on medical leave for awhile, but last I heard, the one (1)
guy who cared enough to work hard-core on a Unicode PHP realized just
how terribly difficult it was, and just how many irreconcilable issues
it raised, and he stopped working on it.

Nobody else has taken up the banner, and PHP 6 trunk was moth-balled
and started over, or so I heard...

That sums up, even over-simplifies, a whole mess of threads,
discussions at conferences, and IRC discussion in a couple
sentences... I apologize to all for the over-simplification, and
possibly outright errors.

While I understand the allure of writing code in one's native
language, and the ease of having one's native language supported out
of the box in the string built-in type...

There are mechanisms available in PHP now, which are more cumbersome,
but they work without the very complex issues alluded to in paragraph
1..

Other languages may have this feature, but they were included from the
beginning.  Grafting them on to PHP at this point was attempted, and,
as far as I know, failed.  It was an ambitious attempt, and the issues
could not have easily been foreseen, so it's probably very
disheartening to have failed just short of the goal line.

That's the way the ball bounces sometimes.

Again, please forgive me if I have completely failed to catch
something here, especially as I'm just getting back into the flow of
things.

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

2012-02-27 Thread Michael Morris

So the official response is get lost?

I don't know about the internals implications.  But from an external
API standpoint I see no problem in allowing programmers who want to
strictly enforce a variable's datatype to do so.  Legacy code would
not be affected unless it was trying to use the new reserved word
strict

2012/2/27 Johannes Schlüter johan...@schlueters.de:
 Hi,

 PHP is no strickt-typed language. Changing this is a massive change, if
 you want to go there: There are plenty of other languages.

 If you want this to be an optional feature:
 a) It's not optional (one has to maintain code written by others, uses
 libraries, frameworks, ...)
 b) It causes a hell lot of trouble with copy-on-write. going from
 fixed-typed to non-fixed-typed variables (in a funciton call or
 assignment or such) will always have to cause a copy. This will hurt the
 performance in hardly predictable ways.

 johannes

 On Mon, 2012-02-27 at 09:29 -0500, Michael Morris wrote:
 What I've wanted for awhile, but don't know what the implementation
 problems would be, is to allow for two new variable types to solve
 this problem - Strict and tolerant variables.  Both of these must be
 declared formally (otherwise PHP assumes scalar) and the datatype must
 be included. The syntax

 // A tolerant variable.
 integer $a = 3;

 // A strict variable
 strict integer $b = 2;

 Tolerant variables silently cast values to their declared datatype.
 Maybe they should raise E_NOTICE?
 Strict variables refuse to be assigned a value with an incorrect
 datatype.  Raise E_WARNING?

 A strict function would have the current behavior of kicking a warning
 when the type hinting fails.  Otherwise, functions should be tolerant
 -

 function foo ( integer $a, string $b, $c ) {}

 strict function foo ( integer $a, $string $b, $c ) {}

 A function parameter without a datatype would be ignored.

 This does open the door to function overloading, but the engine
 problems of this are well documented and have been discussed.  Still,
 I don't think it's a bad thing to have a syntax that allows for method
 overloading in the future.

 On Sun, Feb 26, 2012 at 10:52 PM, Kris Craig kris.cr...@gmail.com wrote:
  I'll try to find some time tonight to create that for ya.
 
  Once this discussion comes together a little bit more and we have at least
  a vague-ish idea what direction we're moving in, I'll also go ahead and
  create an RFC as well so we have a conceptual product to build on.
 
  --Kris
 
 
  On Sun, Feb 26, 2012 at 6:27 PM, Samuel Deal samuel.d...@gmail.com wrote:
 
  Hi,
 
  I create a new thread to discuss about Scalar type hinting.
 
  Following the John Crenshaw proposed terminology:
   - Strict Typing means the super strict old C style typing that has
  been proven to be ridiculous in this environment because of the obvious
  problems inherent in the fact that almost every input is a string.
   - Weak Typing means types in the same sense that the PHP documentation
  uses types (for example, the docs indicate substr(string, integer), and
  substr(12345, 2) == 345.)
   - No Scalar Typing should be used to indicate the current system
  (where there is no provision for hinting at scalar types.)
 
  Previous weak typing proposal could be found here :
  https://wiki.php.net/rfc/typechecking
 
  I have no rights to edit the wiki and make a summary of previous
  arguments, so if someone could create it...
 
 
  --
  Samuel DEAL
  samuel.d...@gmail.com
 
 




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Enum proposal (yet another)

On 27/02/12 02:44, John Crenshaw wrote:
 If we can agree on some basic terminology I think it would move things 
 forward considerably. I propose these terms:
 - Strict Typing means the super strict old C style typing that has been 
 proven to be ridiculous in this environment because of the obvious problems 
 inherent in the fact that almost every input is a string.
 - Weak Typing means types in the same sense that the PHP documentation uses 
 types (for example, the docs indicate substr(string, integer), and 
 substr(12345, 2) == 345.)
 - No Scalar Typing should be used to indicate the current system (where 
 there is no provision for hinting at scalar types.)
I'd add a fourth class, in between weak and strict typing, where a
diagnostic is issued when the requested conversion doesn't make sense.
Let's call it sane weak typing. The following would work:

function score(int $number) {
 global $points, $total;
  $points += $number;
  $total++;
}

score(42);
score(1.0);
score(7);


but these would generate a diagnostic:
score( Mary had a little lamb);
score( array(3, 27, 45) );
score( new stdclass );
score( fopen(myfile.txt, w) );

(note that in some of these cases, the += operator would already produce
a fatal error)

Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/Zend/zend_API.c trunk/NEWS trunk/Zend/zend_API.c

2012-02-27 Thread Xinchen Hui

Sent from my iPad

在 2012-2-28，0:10，Anthony Ferrara ircmax...@gmail.com 写道：

 Out of curiosity, why are you changing it to copy the object for the
 result of the cast operation?  cast_object should init the result
 zval, so why go through the step of copying the starting object to
plz look at the final fix： r323563

thanks
 r323563
 Wouldn't it be easier just to do:

if (Z_OBJ_HANDLER_PP(arg, cast_object)) {
zval *result;
ALLOC_ZVAL(result);
if (Z_OBJ_HANDLER_P(*arg, cast_object)(*arg, result, type TSRMLS_CC)
 == SUCCESS) {
zval_ptr_dtor(arg);
*pl = Z_STRLEN_PP(result);
*p = Z_STRVAL_PP(result);
zval_ptr_dtor(result);
return SUCCESS;
}
zval_ptr_dtor(result);
}

 Keeping both completely separate, and not having the possibility of
 corrupting the arg object pointer?  As it is right now (with the patch
 in the first mail), wouldn't the possibility still exist of nuking the
 arg object pointer which could be used elsewhere (and hence cause the
 memory leak and segfault when that variable is referenced again)?

 (Un tested as of yet, just throwing it out there as it seems kind of
 weird to overwrite the arg pointer for what seems like no reason)...

 Anthony



 On Mon, Feb 27, 2012 at 10:22 AM, Richard Lynch c...@l-i-e.com wrote:
 On Mon, February 27, 2012 2:31 am, Laruence wrote:
 On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov dmi...@zend.com
 wrote:
 Hi Laruence,

 The attached patch looks wired. The patch on top of it (r323563)
 makes it
 better. However, in my opinion it fixes a common problem just in a
 single
 place. Each call to __toString() that makes side effects may cause
 the
 similar problem. It would be great to make a right fix in
 zend_std_cast_object_tostring() itself, but probably it would
 require API
 Hi:
before this fix, I thought about the same idea of that.

but,  you know,  such change will need all exts who implmented
 their own cast_object handler change there codes too.

for now,  I exam the usage of std_cast_object_tostring,  most of
 them do the similar things like this fix to avoid this issues(like
 ZEND_CAST handler).

so I think,  maybe it's okey for a temporary fix :)

 Perhaps a better solution would be to make a NEW function that uses
 zval** and deprecate the old one with memory leaks.

 Old extensions remain functional, new extension consume less memory.

 (This presumes I actually understand the issue, which is questionable.)

 --
 brain cancer update:
 http://richardlynch.blogspot.com/search/label/brain%20tumor
 Donate:
 https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

On 27/02/12 17:19, Richard Lynch wrote:
 PRESUMPTION:

 *ANY* strict datatype could also be NULL, to represent a failure
 condition...

 Otherwise, when you are out of RAM:
 strict $o = new Object(); //violates strict, because Object HAS to be
 NULL, as there is no RAM left for it to be an object.
Uh? No. You would get a fatal error because PHP exceeded maximum
allowed memory.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Cannot build ext/intl on Fedora 15

On Sun, February 26, 2012 1:19 pm, Tom Boutell wrote:
 Bump - this is still a live issue on Ubuntu 11.10, for instance.

 I just hacked my Ubuntu PHP-from-source installer to touch up the
 Makefile by prepending -lstdc++ to EXTRA_LIBS. That does the job.

 Which I knew more about autoconf, I'd like to help figure this out
 properly so everyone doesn't wind up maintaining hacks to compile PHP
 from source. It discourages a very large community from trying new
 releases.

 Is this perhaps because some of the code being included in the PHP
 build happens to be C++ code? (Not readily apparent from the outside
 of course.)

I believe core PHP is all in C.

Extensions, however, could be in C++

And if one extension has forgotten to edit the Makefiles to do
-lstdc++ I presume that it could be the cause.

I'd even hazard a guess that it would only surface if one disabled
other extensions that generally PRECEDE it in the configure / make
process, as once the -lstdc++ is in there, it remains for the rest of
the build process.  This is just a guess, however...

At any rate, if you could eliminate each extension, one by one, you
might find the culprit, assuming my guesses are valid.

No promises anything I have said is even correct in any way.

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Cannot build ext/intl on Fedora 15

2012-02-27 Thread Hannes Magnusson

On Mon, Feb 27, 2012 at 17:43, Richard Lynch c...@l-i-e.com wrote:
 On Sun, February 26, 2012 1:19 pm, Tom Boutell wrote:
 Bump - this is still a live issue on Ubuntu 11.10, for instance.

 I just hacked my Ubuntu PHP-from-source installer to touch up the
 Makefile by prepending -lstdc++ to EXTRA_LIBS. That does the job.

 Which I knew more about autoconf, I'd like to help figure this out
 properly so everyone doesn't wind up maintaining hacks to compile PHP
 from source. It discourages a very large community from trying new
 releases.

 Is this perhaps because some of the code being included in the PHP
 build happens to be C++ code? (Not readily apparent from the outside
 of course.)

 I believe core PHP is all in C.

 Extensions, however, could be in C++


ext/intl contains one or two c++ files.

-Hannes

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

On 27/02/12 16:47, Paul Dragoonis wrote:
 2012/2/27 Johannes Schlüter johan...@schlueters.de
 Hi,

 PHP is no strickt-typed language. Changing this is a massive change, if
 you want to go there: There are plenty of other languages.

 If you want this to be an optional feature:
 a) It's not optional (one has to maintain code written by others, uses
 libraries, frameworks, ...)
 b) It causes a hell lot of trouble with copy-on-write. going from
 fixed-typed to non-fixed-typed variables (in a funciton call or
 assignment or such) will always have to cause a copy. This will hurt the
 performance in hardly predictable ways.

 johannes

 Big +1 from me. Thanks for the post Johannes!
I also agree with Johannes, that would be too much trouble.

 It makes sense to have a type hint for the different type of data
 structures.
 1) array
 2) object ( class name for OOP ).

 The scalar values (int, string, double) are type-less, flexible and should
 remain that way. If you want strict typehinting then move to another
 language.
But I disagree with you in that string is always a scalar.

int and double being the same thing, that's ok, even though I usually have
to deal and verify for just natural numbers, but the consideration that it's
a variable of numeric type which could hold many types of numbers is
acceptable. Both are also implemented inside the zval.

Now strings. There are two different kinds of strings.
The first one $age = $_POST['age'] is the kind of string that you want to
treat as a number. And that's fine.

But you also have $name = $_POST['name'] // 'John Doe' which is wrong
to treat as a the same as $age.



---
Hello, I see you were born in ?= $thisyear - $name ?. You look older.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

On Mon, Feb 27, 2012 at 5:16 PM, Michael Morris dmgx.mich...@gmail.comwrote:

 So the official response is get lost?


no, it is: come back after you did your homework, and you can provide new
arguments to the discussion



 I don't know about the internals implications.  But from an external
 API standpoint I see no problem in allowing programmers who want to
 strictly enforce a variable's datatype to do so.  Legacy code would
 not be affected unless it was trying to use the new reserved word
 strict


it was discussed before, strict typing tends to be viral, in the sense
that the developer using a lib which enforces method signatures using type
hinting can either:
- write a lot of boiler plate code to make sure that he/she is passing the
expected types (notice that strict typing would pass that burden to the api
consumer, which is against the Generous on input, strict on output
paradigm, plus it would generate much more work, as there are always more
consumers than producers)
- or simply passing those requirements up in the call chain, which is less
work, but affects even more code, and in the end, turns the whole app into
strict typing.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC] APXS LoadModule Option in configure

On Fri, February 24, 2012 6:14 pm, Kris Craig wrote:
 No, it happens and it's even clearly documented in APXS.

 Basically, if you specify the -a option in APXS, it overwrites your
 httpd.conf (or apache.conf or whatever it is on your system) and adds
 the
 LoadModule line to it.  In PHP's configure script, you'll notice that
 -a
 is always specified; there's no option to use APXS without it.  As a
 result, make install will always overwrite your LoadModule entry in
 httpd.conf if APXS is enabled.  The problem occurs when you have
 LoadModule
 in an included .conf file already; APXS does not have the ability to
 detect
 that.  Therefore, a duplicate LoadModule entry is added to
 httpd.conf by
 APXS, and thus the clash occurs.  This behavior has been reproduced
 numerous times.


 I think the RFC is pretty clear on how this works.  Nobody else has
 expressed confusion thus far.  I could clarify further but I'm not
 sure
 how; it's pretty straight-forward, really.  I'm not sure what may have
 been
 happening in your case or if perhaps you misunderstood what this RFC
 is
 about.  Either way, I would recommend you create a fresh Linux-based
 build
 environment, build Apache 2.2 and PHP 5.3.10 yourself (i.e. stay away
 from
 yum/apt-get), then attempt to generate an APXS-enabled Makefile using
 PHP's
 configure script that does not activate APXS with the -a option.  It
 might also be a good idea for you to check-out the APXS documentation
 (I
 included a link to it on the RFC).

 Those steps should enable you to reproduce this.  =)

Once upon a time, a lonng time ago, I read through the configure /
make process, and I *thought* there was logic there to try to detect
if your httpd.conf diverged significantly from the default, and, if
so, it would choose NOT to add the LoadModule line, assuming you were
a power user who had it somewhere else...

I could be mis-remembering. This logic could have been removed. I
could be hallucinating.  The logic I saw could have been doing
something entirely difference, as I have only a vague notion of how
configure/make works in the first place.  It could have been some
other project.

Or this could account for your different experiences, based on whether
you hacked httpd.conf enough or started with a fresh out of the
box one and didn't touch it until after installing PHP.

ymmv
ianal

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting



 Now strings. There are two different kinds of strings.
 The first one $age = $_POST['age'] is the kind of string that you want to
 treat as a number. And that's fine.

 But you also have $name = $_POST['name'] // 'John Doe' which is wrong
 to treat as a the same as $age.


php doesn't have the necessary information to tell whether your input
variable is a number, or only looks like a number.
how would you define what is an int? what type would the following input
variables have?
- 1
- 1.1
- 1.0
- .5
- 0777

I think it is better to populate everything as string, and let the
application developer to parse the inputs as he knows what should they
represent.

Btw. there was a discussion about raising a warning (somebody even
suggested creating an E_TYPE level) when data loss occurs on a type
juggling.
I would support that, as people tend to be surprised when they realize the
first time that 123 == '123 apples' evaluates to true in php.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/Zend/zend_API.c trunk/NEWS trunk/Zend/zend_API.c

I initially looked at the final fix when I discovered the issue.
Follow me out on this.  This is the current code as-implemented in
r323563:

265 zval *obj;
266 MAKE_STD_ZVAL(obj);
267 if (Z_OBJ_HANDLER_P(*arg, cast_object)(*arg, obj, type
TSRMLS_CC) == SUCCESS) {
268 zval_ptr_dtor(arg);
269 *arg = obj;
270 *pl = Z_STRLEN_PP(arg);
271 *p = Z_STRVAL_PP(arg);
272 return SUCCESS;
273 }
274 efree(obj);

The issue that I originally identified (overwriting the argument
pointer) is still happening.  Is there any reason for overwriting the
arg pointer?  Wouldn't it be better to just do the Z_STRLEN_PP and
Z_STRVAL_PP operations on obj instead, and zval_ptr_dtor it as well
(instead of efree, as that way if a reference is stored somewhere it
won't result in a double free, or a segfault for accessing freed
memory)?

Thanks,

Anthony

On Mon, Feb 27, 2012 at 11:39 AM, Xinchen Hui larue...@gmail.com wrote:
 Sent from my iPad

 在 2012-2-28，0:10，Anthony Ferrara ircmax...@gmail.com 写道：

 Out of curiosity, why are you changing it to copy the object for the
 result of the cast operation?  cast_object should init the result
 zval, so why go through the step of copying the starting object to
 plz look at the final fix： r323563

 thanks
 r323563
 Wouldn't it be easier just to do:

    if (Z_OBJ_HANDLER_PP(arg, cast_object)) {
        zval *result;
        ALLOC_ZVAL(result);
        if (Z_OBJ_HANDLER_P(*arg, cast_object)(*arg, result, type TSRMLS_CC)
 == SUCCESS) {
            zval_ptr_dtor(arg);
            *pl = Z_STRLEN_PP(result);
            *p = Z_STRVAL_PP(result);
            zval_ptr_dtor(result);
            return SUCCESS;
        }
        zval_ptr_dtor(result);
    }

 Keeping both completely separate, and not having the possibility of
 corrupting the arg object pointer?  As it is right now (with the patch
 in the first mail), wouldn't the possibility still exist of nuking the
 arg object pointer which could be used elsewhere (and hence cause the
 memory leak and segfault when that variable is referenced again)?

 (Un tested as of yet, just throwing it out there as it seems kind of
 weird to overwrite the arg pointer for what seems like no reason)...

 Anthony



 On Mon, Feb 27, 2012 at 10:22 AM, Richard Lynch c...@l-i-e.com wrote:
 On Mon, February 27, 2012 2:31 am, Laruence wrote:
 On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov dmi...@zend.com
 wrote:
 Hi Laruence,

 The attached patch looks wired. The patch on top of it (r323563)
 makes it
 better. However, in my opinion it fixes a common problem just in a
 single
 place. Each call to __toString() that makes side effects may cause
 the
 similar problem. It would be great to make a right fix in
 zend_std_cast_object_tostring() itself, but probably it would
 require API
 Hi:
    before this fix, I thought about the same idea of that.

    but,  you know,  such change will need all exts who implmented
 their own cast_object handler change there codes too.

    for now,  I exam the usage of std_cast_object_tostring,  most of
 them do the similar things like this fix to avoid this issues(like
 ZEND_CAST handler).

    so I think,  maybe it's okey for a temporary fix :)

 Perhaps a better solution would be to make a NEW function that uses
 zval** and deprecate the old one with memory leaks.

 Old extensions remain functional, new extension consume less memory.

 (This presumes I actually understand the issue, which is questionable.)

 --
 brain cancer update:
 http://richardlynch.blogspot.com/search/label/brain%20tumor
 Donate:
 https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] $_PARAMETERS Super Global Object

On Fri, February 24, 2012 4:40 pm, Larry Garfield wrote:
 On 2/24/12 4:34 PM, Richard Lynch wrote:
 On Fri, February 24, 2012 4:16 pm, Larry Garfield wrote:
 On 2/24/12 3:28 PM, Richard Lynch wrote:

 Except that per HTTP, GET and POST are completely different
 operations.
   One is idempotent and cacheable, the other is not idempotent and not
 cacheable.  I very much care which someone is using.

If all my operations are idempotent, regardless of the request method,
I can and will cache the POST operations, because I know I can do so.

In other words: The HTTP spec specifically requires GET to be
idempotent, and that implies it is cacheable.

Nowhere in the HTTP spec can I find a REQUIREMENT for POST to not be
idempotent, or to NOT be cached if it happens to BE idempotent.

If I'm wrong please cite your reference.

 As Will said in the other reply, there's security implications.  (I
 don't know who suggested that POST is more secure than GET.  I
 certainly
 didn't.)

I know you wouldn't say that.

Only total newbies think POST is more secure because they just don't
understand how they work.

 You want your login form operating over POST, not GET, in
 large part for the reasons above.

Obviously login MUST be POST. It's not idempotent.

Authentication to receive the content would also have to be POST, as
it's not idempotent.

But there is no reason to REQUIRE idempotent requests to be GET, and
no specification that I can find that states that it is.

The only requirement is that NON-idempotent must *NOT* be GET.

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] $_PARAMETERS Super Global Object

On Fri, February 24, 2012 4:48 pm, Ronald Chmara wrote:
 On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield
 la...@garfieldtech.com wrote:
 To me, it's just a request for some content, and in a REST API
 that's
 read-only, I just don't care if the consumer sends their request as
 GET or POST.  I'll cheerfully give them what they wanted.
 Except that per HTTP, GET and POST are completely different
 operations.  One
 is idempotent and cacheable, the other is not idempotent and not
 cacheable.
  I very much care which someone is using.

 People exploiting security would *never* think of
 caching/replaying/modifying  a POST request, that's just totally
 unimaginable! It would take, like HUGE computational effort to like,
 cURL it or just type it out!

You missed the totally newbie way, or at least a way to demonstrate
the issue to somebody who simply doesn't understand the issue:
   Save the HTML form to your hard drive.
   Edit it in Notepad (et al) to make up whatever value=xyz you want.
   Open it in your browser using Open File... and pick the file.
   Submit the FORM.

I had to do this several times for non-technical bosses or students
who simply refused to believe that it was TRIVIAL to forge POST
requests...

Once they saw it in action, the light bulb goes on and you can say:
I can also script this to repeat the same thing a million times with
form-letter substitution, and then they understand it *is* trivial.

Maybe I just had dense bosses/students, or I was bad at explaining the
idea, but it worked for me...

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Enum proposal (yet another)

On Fri, February 24, 2012 4:33 pm, Kris Craig wrote:
 I hear that a lot; i.e. If you want static typing, use Java.

 Unfortunately, that dismissive answer has not worked too well over the
 years, has it?  People are still clamoring for this, and I think
 making
 some very valid arguments that shouldn't be so derisively and
 flippantly
 brushed aside.

I did not mean to be flippant, and was quite sincere, so allow me to
restate it:

This idea has been floated many times.

Sometimes, it even came with initial patches to prove it could be
done, and was feasible.

Every time, eventually, non-trivial issues were raised by Core Devs
that could simply NOT be addressed by the proposer, and they realized
that changing PHP at such a fundamental level was, indeed, a
non-starter. Or at least a non-finisher. :-)

I only meant to suggest that if you seriously WANT these features in
your language, switching to Java and JSP will give them to you,
without the pain and suffering of a TON of work that history has shown
will 99.% sure end in failure.

I am, again, not being flippant, nor trying to claim that PHP is not
an evolving language.

I am, still, stating that the probability of it evolving in this
direction, after it has been tried and failed so MANY times in the
past, is incredibly unlikely.

Examine the historical record, and the many proposed patches / changes
/ ideas, and I sincerely believe you will come to the same conclusion.

If you really think you can pull it off, despite the historical
evidence, I suggest you start to make a patch to do so, and find out
just how much you are biting off to chew.

In essence, you will effectively be re-writing Java / JSP or something
similar, while trying to maintain compatibility with PHP and PHP
internals that rely extensively on dynamic typing.

To bowlderize Clemens (?) with regard to typing:

Strict is strict, and dynamic is dynamic, and never the twain shall
meet.

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] $_PARAMETERS Super Global Object

On Mon, Feb 27, 2012 at 6:17 PM, Richard Lynch c...@l-i-e.com wrote:

 On Fri, February 24, 2012 4:48 pm, Ronald Chmara wrote:
  On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield
  la...@garfieldtech.com wrote:
  To me, it's just a request for some content, and in a REST API
  that's
  read-only, I just don't care if the consumer sends their request as
  GET or POST.  I'll cheerfully give them what they wanted.
  Except that per HTTP, GET and POST are completely different
  operations.  One
  is idempotent and cacheable, the other is not idempotent and not
  cacheable.
   I very much care which someone is using.
 
  People exploiting security would *never* think of
  caching/replaying/modifying  a POST request, that's just totally
  unimaginable! It would take, like HUGE computational effort to like,
  cURL it or just type it out!

 You missed the totally newbie way, or at least a way to demonstrate
 the issue to somebody who simply doesn't understand the issue:
   Save the HTML form to your hard drive.
   Edit it in Notepad (et al) to make up whatever value=xyz you want.
   Open it in your browser using Open File... and pick the file.
   Submit the FORM.

 I had to do this several times for non-technical bosses or students
 who simply refused to believe that it was TRIVIAL to forge POST
 requests...

 Once they saw it in action, the light bulb goes on and you can say:
 I can also script this to repeat the same thing a million times with
 form-letter substitution, and then they understand it *is* trivial.

 Maybe I just had dense bosses/students, or I was bad at explaining the
 idea, but it worked for me...


changing the method in curl is even easier.

you both missed the fact that Larry is aware of the fact that POST
is forge-able.

there are cases when you can improve your security model (even by a little
bit) if you don't allow the method to be interchangeable.

for example: if I have an XSS vulnerability on bugs.php.net, it is much
easier for me to trick the devs clicking on the link if the said vuln is
exploitable through GET.
if it can only be exploited through POST, I have to set up a page somewhere
with a POST form, pointing to the vulnerable url, and ask the said devs to
visit that url and submit the form (or have javascript enabled, so that I
can submit if for them).
exploiting the reflected vulnerabilities is much easier if you can do it
through GET.

ps: if you don't know what did Larry mean by the Idempotent method, see
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Scalar type hinting

 no, it is: come back after you did your homework, and you can provide new
 arguments to the discussion


To be completely fair, I did homework on this.  I went back to 2000 on
marc.info's archives and read almost all of the 400 posts matching the
search http://marc.info/?l=php-internalsw=2r=13s=strict+typingq=b
and a bunch of the posts on
http://marc.info/?l=php-internalsw=2r=54s=type+hintingq=b

The vast majority of what I found were quite good arguments for
including the feature.  I found quite a bit of this was discussed to
death, do your homework and provide new arguments.  What's odd, is
that one of the earliest on-topic threads that I found (2007:
http://marc.info/?l=php-internalsm=119514660125258w=2 ) had this as
the third reply.  The only on-topic discussion that I found prior to
that was in 2006 (almost exactly 1 year prior:
http://marc.info/?l=php-internalsm=116257685415135w=2 ).

Discussed to death.  Yet only one time before (discussing a specific patch)...

And the opponents still said no...

There were also quite a few problems identified with scalar hinting
and auto-casting vs strict erroring.  However, there were also
solutions proposed to nearly each and every one of them.

And the opponents still said no...

It has been brought up time and time again.  Solutions have been
proposed which have no fundimental issues (inconsistencies,
problematic operations - such as references, etc)...

And the opponents instead said this has been discussed to death, no...

Please can you stop saying this has been discussed to death.  To be
frank, don't stop the discussion because you don't like the idea.  It
has been discussed to death.  But the discussion has only really ever
involved people who are for it.  The opponents by and large have used
two arguments: It has been discussed already, so no and don't make
PHP into Java.

There has been some discussion of technical merit and problem
resolution by opponents, but finding it is VERY difficult among all
the down trodding commentary.

So let me make a plea:

If you don't like this feature, and you can explain from a TECHNICAL
perspective why, please do so!  If you don't like the feature, and are
going to lean on It's not Java, or We've discussed this to death
already, please don't...



And to be fair: and you can provide new arguments to the discussion
has already happened quite a bit (dating back the past 5 years), but
those arguments were ignored or overruled for political reasons.


Anthony


On Mon, Feb 27, 2012 at 11:55 AM, Ferenc Kovacs tyr...@gmail.com wrote:
 On Mon, Feb 27, 2012 at 5:16 PM, Michael Morris dmgx.mich...@gmail.comwrote:

 So the official response is get lost?


 no, it is: come back after you did your homework, and you can provide new
 arguments to the discussion



 I don't know about the internals implications.  But from an external
 API standpoint I see no problem in allowing programmers who want to
 strictly enforce a variable's datatype to do so.  Legacy code would
 not be affected unless it was trying to use the new reserved word
 strict


 it was discussed before, strict typing tends to be viral, in the sense
 that the developer using a lib which enforces method signatures using type
 hinting can either:
 - write a lot of boiler plate code to make sure that he/she is passing the
 expected types (notice that strict typing would pass that burden to the api
 consumer, which is against the Generous on input, strict on output
 paradigm, plus it would generate much more work, as there are always more
 consumers than producers)
 - or simply passing those requirements up in the call chain, which is less
 work, but affects even more code, and in the end, turns the whole app into
 strict typing.

 --
 Ferenc Kovács
 @Tyr43l - http://tyrael.hu

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Enum proposal (yet another)

On Sat, February 25, 2012 7:58 pm, Kris Craig wrote:
 On Sat, Feb 25, 2012 at 4:54 PM, Stas Malyshev
 smalys...@sugarcrm.comwrote:

 Hi!


  I'm well aware that this has been discussed before, Stas.  However,
 you're mischaracterizing those previous conversations.  It has
 never
 been proven that optional strict typing doesn't work.  You've made
 the
 same arguments against it, but those arguments have
 counter-arguments
 that are also viable.


 I'm not sure what you mean by proven. You expect rigorous
 mathematical
 proof? You're not getting one. If you have something new to say with
 regard
 to the arguments that were brought up 10 times already - ok, go
 ahead. But
 please read them first.


 Another logical fallacy.  Cognitive dissonance.  Either there is
 rigorous
 mathematical proof or a statement is completely unproven (and/or
 cannot be
 proven).

Are you going to completely dismiss statistical probability somewhere
in the middle of the two?

People a whole lot smarter than I, and, forgive me, but *some* of them
probably smarter than you, have tried this again and again and again.

They all failed.

They failed exactly for the reasons Stas pointed out:

You can't change just one thing.

The changes have repercussions, and in this particular instance, those
repercussions dig into the heart and soul of PHP, to the point where
you would, quite literally, have to change PHP *INTO* JSP or similar.

 In fact, you haven't proven your point by any standard, rigorous or
 otherwise.  There is no basis for suggesting that it cannot be done.
  You've clearly stated that you don't think it *should* be done, but
 you
 haven't viably demonstrated that it *can't* be done, or that it would
 break PHP as we know it.

The problem is probably NP-incomplete, though I have no proof for even
that statement, other than my gut telling me it is so.

I certainly have not the time nor inclination to prove the
completeness or lack thereof for adding static typing to PHP.

Perhaps a trained mathematician (like me) who has kept his skills up
(unlike me) would take a go at it. :-)

  people keep asking for it.  It keeps coming up because, despite
 belittling and dismissive comments made by yourself and a few
 others,
 people continue to see that there is, in fact, a valid argument for
 implementing this.  It shows that you have never been able to
 convince
 those who don't already agree with you that this is impossible.


 Or it's coming up because people don't bother to read past
 discussions and
 think they are first who thought let's put strict typing in PHP
 and only
 reason why it's not there because nobody was smart enough to think
 about
 it. It's not so. It was repeatedly discussed and rediscussed. If you
 have
 new argument - fine, we'd all be happy to hear it. So far I didn't
 hear one
 though. Please let us hear it.


 No, it's coming up because people have read these past discussions and
 still think it's a reasonable goal that deserves further
 consideration.

In the abstract ideal, it's quite reasonable.

The devil is in the details. It can't be done, without completely
re-writing PHP into something akin to a different language.

This conclusion has been reached multiple times, with multiple
proposals and attempts, including a lot of patches, some that went
very far down the path before they failed, and were abandoned.

 On the
 contrary, it looks to me more like it either fizzled or was punted
 each
 time, but no consensus was ever reached.  Therefore, further
 discussion is
 warranted.  The fact that this was discussed previously does not make
 this
 topic any less legitimate.

They all fizzled or punted because the enormity of the problem space
turned out to be insurmountable.

This is not to say you CANNOT succeed: Only that every attempt before,
and they are legion, has failed.

 It doesn't work that way. Language is a complex construct, with all
 parts
 influencing each other, thinking you can just add strict typing
 somewhere
 in the corner and nothing changes is a dangerous illusion. It would
 not
 work. If you type function arguments, you should also type all the
 variables that could end up as the function arguments, all the
 functions
 returning into those arguments and all the operators and functions
 that do
 any transformations over those things. Otherwise it is guaranteed to
 blow
 up in runtime. After doing that, you've got yourself a strictly
 typed
 language. Absent compiler, though, such language would be quite hard
 to
 operate - how do you know your code correctly uses all the types
 some
 library wants? How do you know next version doesn't change any types
 without you noticing? etc., etc.


 You're operating on a number of unfounded assumptions here (a house
 of
 cards if you will).  First, nobody is saying that this wouldn't be a
 significant undertaking at the core development level.  We all agree
 that
 it would be.  However, you're once again introducing cognitive
 dissonance
 into this.

Re: [PHP-DEV] Cannot build ext/intl on Fedora 15

On Mon, 2012-02-27 at 10:43 -0600, Richard Lynch wrote:
 I believe core PHP is all in C.

Correct.

 Extensions, however, could be in C++

Correct.

 And if one extension has forgotten to edit the Makefiles to do
 -lstdc++ I presume that it could be the cause.

Nobody should directly link -lstdc++, that name is compiler-specific.
Instead a C++ compiler has to be used in this case for the final
linkage, so instead of linking using gcc one has to use g++ when using a
gcc chain.

For shared builds the build system has a flag to switch this. When
building PHP itself the build system ignores that flag. (that's where
the tip to build it shared came from)

 I'd even hazard a guess that it would only surface if one disabled
 other extensions that generally PRECEDE it in the configure / make
 process, as once the -lstdc++ is in there, it remains for the rest of
 the build process.  This is just a guess, however...

No, as no extension should refer to libstdc++ (see above) this is not
the case. 
A reason one one might not see it is that PHP is linked against a
library which was linked using libstdc++ and therefore pulls it in.
(So if ext/foo was a wrapper around libfoo.so and libfoo.so would be
linked using a C++ compiler this would work)

 At any rate, if you could eliminate each extension, one by one, you
 might find the culprit, assuming my guesses are valid.

There are two possible solutions:

  * change the build system to link php using the C++ compiler to
pull in the C++ standard lib. This might have some issues on
portability of the binary, make the process larger, etc.
  * figure out which C++ things are being used that require the C++
standard library and get rid of them. I didn't look into this
but it seems libintl doesn't need the C++ standard lib (else it
should pull it in) and the error message refering to
__gxx_personality_v0 sounds like a compiler feature which might
be controlled by using some compiler flags. My guess is that
this is part of gcc's exception or RTTI implementation which can
be disabled (try -fno-rtti or -fno-exception in CXXFLAGS) ... if
this is the case disabling these features for these files would
be the fest thing to do. (while it causes trouble if it is done
for other [future or pecl?]) files which might need these
features

johannes



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Enum proposal (yet another)

 I'm not so sure about that. In a well-written web application, you
 would
 typically convert them on the first layer, when receiving from the
 web.
 On next usages, your int variables are usually ints already.

Afraid not.

It turns out that PHP, on 32-bit hardware, converting large BIGINT
using (int) $ID ends up as a negative number, and then when you pass
it in to the database if a string query, you get a negative ID, not at
all what was intended.

(Been there, done that, got burned)

At least, that's been my experience with some versions of PHP and some
database drivers.

So at least the database IDs have to remain as strings, if you are
using BIGINT.

You could, of course, only convert the values known to be in range of
PHPs positive integers, and leave the others as strings.

This is just a simple example of how the super strict typing simply
doesn't work out too well in PHP.

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] $_PARAMETERS Super Global Object

On Fri, February 24, 2012 5:15 pm, Larry Garfield wrote:
 On 2/24/12 4:55 PM, Jeremiah Dodds wrote:

 Except that per HTTP, GET and POST are completely different
 operations.  One
 is idempotent and cacheable, the other is not idempotent and not
 cacheable.
   I very much care which someone is using.

 Correct me if I'm wrong, but you're referring to the HTTP *method*
 used. A POST can be made to a URL that includes a query-string, but
 what that means as far as interpreting the variables is undefined as
 far as I know.

 Because of that, I think it's a bad idea to either treat them as the
 same thing, or rely on both $_POST and $_GET parameters being
 present.

 The underlying problem is that HTTP has a URI query string, and a
 body.
   In a typical GET request there is no body.

Nitpick: I think a body is explicitly NOT supposed to exist in a GET
request, and not just typically.   It's been a long time since I
read the HTTP spec though...

  In a typical POST the
 body
 is a query string in similar format to the URI's query string, plus
 possibly other stuff.  In other request methods the body may be
 something else entirely.

 PHP's superglobals make the (wrong) assumption that the URI query
 string
 comes from a GET query (hence $_GET) and body comes from a POST query
 string ($_POST), because that matches up with the default method=
 attribute of HTML forms.  That assumption is limiting and misleading,
 and made worse by the existence of $_REQUEST, but is the assumption
 that
 PHP makes.

Unless I am very much mistaken, the HTTP spec explicitly states that
parameters in the URL with a POST request are completely kosher.

Separating those two sources in a single request, by placing the
URL-specified input as $_GET makes perfect sense to most PHP
developers, even though, strictly speaking, the are part of the POST
request.

I don't know if the HTTP spec even addresses the question of having a
URL-specified and a POST-body specified parameter of the same name.

However, given that it explicitly allows a URL with
?foo=barfoo=12foo=whatever, I can't see how it would ban the
duplicity of POST data and GET data having the same parameter name,
once it allows URL-specified and POST-body specified parameters.

I have certainly always enjoyed PHP's extension of the spec to create
an array for multiple params ending in [].  Trying to do the same sort
of thing in old-school ASP made me tear my hair out...

I like the way PHP handles $_GET $_POST and $_REQUEST, and you don't.

Neither is right or wrong

Sometimes I find $_REQUEST useful, sometimes I don't.

I have presented at least one use case where I do not *care* where the
input comes from, because the operations are all idempotent, and
nothing in the spec says POST has to be NON-idempotent.

Another use-case, back before CSS let you change presentation of
buttons and links, and javascript was just a nightmare of
incompatibilities in even the most simple scripts, was a case where
the look and feel dictated links (GET) on one page, and buttons (POST)
on the other page.  I simply used $_REQUEST in the processing page,
which was just a read-only filter to idempotent requests.

I believe one was a search FORM that was POST, and the other was just
pagination with filters.

Perhaps, in retrospect, the FORM should have used method=GET (the
preferred capitalization in those days).  But it may have set some
session-preferences, and therefore not been strictly idempotent, while
the GET did not set preferences...  It's been a long time...

At any rate, I still contend that when the server just doesn't care
what method of request comes in, because they are all idempotent,
there is no need to insist that GET be used if the consumer of the
service finds POST more convenient.

GET must be idempotent.  The converse is not true. An idempotent
request does not HAVE to be a GET.

In other words, POST is not required to be NON-idempotent, even if GET
cannot be NON-idempotent.

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

2012-02-27 Thread Daniel Macedo

Anthony,

Remember you're dealing with the internals list. :)
I kind of like the idea of having long proper discussions on a
particular topic. But let's face it, that's an utopic view (at best)!

Even if optional, and even if backwards compatible, there are a number
of things that will be quite hard to change, ranging from it's very
difficult/impossible to implement properly, to this isn't the PHP
way...

Just check out the discussions regarding function naming and/or
parameter order and you'll understand, some things will remain; but
remember the golden rule:
?php echo 'PHP ' . (PHP_MAJOR_VERSION + 1) . ' will fix it!'; ?

Cheers,
~ Daniel

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

+1 what Anthony said.

Guys, seriously.  Some of these responses have been downright rude and
inappropriate for a constructive dialogue.  Please do not pollute this
thread with cliche, Just find another language and get out! posts.  It
doesn't add anything to the conversation and instead just creates needless
anger and animosity.  It's immature and just makes it look like we're
incapable of having a rational discussion.

So, let me outline a list of arguments that will carry ZERO weight on
this thread:

   - If you don't like PHP as it is, goto Java (or some other language)!
   - We've already talked about this before.  Therefore, we must never
   speak of it again.
   - This is impossible.  Why?  Because I said so.  You want evidence?
   Fuck you.
   - But this would require significant changes to the core source code!
   We'd never be able to find enough sacrificial penguins to appease the gods!
   - Anyone who likes this idea is either stupid or not a 'true' PHP
   developer.
   - If you disagree with me, it means you haven't done your homework
   because I'm always right.
   - Strict typing would break everything!  What?  You're not talking
   about C-like strict typing?  Sorry, I didn't catch that.  Strict typing
   would break everything!
   - I don't care if you've already countered my argument.  I'll just keep
   repeating myself as if you didn't.


Variations of the above statements have been posted ad nauseum.  They're
all based on logical fallacies and are not constructive.

I'm putting this out there:  If anyone posts one or more of the above
arguments yet again on this topic, I will personally extract one of your
kidneys and sell it to a questionable dog food company in Shanghai.  I
will then openly mock your intellectual laziness and encourage people to
ignore you.  ;P


I'd love to prove Daniel wrong, but I think he may be on to something
:\

--Kris


On Mon, Feb 27, 2012 at 9:38 AM, Anthony Ferrara ircmax...@gmail.comwrote:

  no, it is: come back after you did your homework, and you can provide
 new
  arguments to the discussion


 To be completely fair, I did homework on this.  I went back to 2000 on
 marc.info's archives and read almost all of the 400 posts matching the
 search http://marc.info/?l=php-internalsw=2r=13s=strict+typingq=b
 and a bunch of the posts on
 http://marc.info/?l=php-internalsw=2r=54s=type+hintingq=b

 The vast majority of what I found were quite good arguments for
 including the feature.  I found quite a bit of this was discussed to
 death, do your homework and provide new arguments.  What's odd, is
 that one of the earliest on-topic threads that I found (2007:
 http://marc.info/?l=php-internalsm=119514660125258w=2 ) had this as
 the third reply.  The only on-topic discussion that I found prior to
 that was in 2006 (almost exactly 1 year prior:
 http://marc.info/?l=php-internalsm=116257685415135w=2 ).

 Discussed to death.  Yet only one time before (discussing a specific
 patch)...

 And the opponents still said no...

 There were also quite a few problems identified with scalar hinting
 and auto-casting vs strict erroring.  However, there were also
 solutions proposed to nearly each and every one of them.

 And the opponents still said no...

 It has been brought up time and time again.  Solutions have been
 proposed which have no fundimental issues (inconsistencies,
 problematic operations - such as references, etc)...

 And the opponents instead said this has been discussed to death, no...

 Please can you stop saying this has been discussed to death.  To be
 frank, don't stop the discussion because you don't like the idea.  It
 has been discussed to death.  But the discussion has only really ever
 involved people who are for it.  The opponents by and large have used
 two arguments: It has been discussed already, so no and don't make
 PHP into Java.

 There has been some discussion of technical merit and problem
 resolution by opponents, but finding it is VERY difficult among all
 the down trodding commentary.

 So let me make a plea:

 If you don't like this feature, and you can explain from a TECHNICAL
 perspective why, please do so!  If you don't like the feature, and are
 going to lean on It's not Java, or We've discussed this to death
 already, please don't...



 And to be fair: and you can provide new arguments to the discussion
 has already happened quite a bit (dating back the past 5 years), but
 those arguments were ignored or overruled for political reasons.


 Anthony


 On Mon, Feb 27, 2012 at 11:55 AM, Ferenc Kovacs tyr...@gmail.com wrote:
  On Mon, Feb 27, 2012 at 5:16 PM, Michael Morris dmgx.mich...@gmail.com
 wrote:
 
  So the official response is get lost?
 
 
  no, it is: come back after you did your homework, and you can provide
 new
  arguments to the discussion
 
 
 
  I don't know about the internals implications.  But from an external
  API standpoint I see no problem in allowing programmers who want to
  strictly enforce a

Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting

On Mon, February 27, 2012 9:20 am, Anthony Ferrara wrote:
 I have to say that no matter how much a luv my OOP, turning every
 built-in type into an Object is just a Bad Idea...

 It's a form of bloat on RAM and CPU with minimal added value, imho.

 Re-read what I had written.  I never said to turn every built-in type
 into an object.  In fact, what I was talking about was keeping and
 preserving the base types as-is.  All that I was proposing was adding
 the ability to cast from and to the primitives.  That way you could
 silently convert back and forth as needed (transparently when
 possible).


I apologize that my brevity has been misconstrued.

You are certainly free, even with the tools available in PHP, to
wrap an object around integers, strings, and so on.

There may even be occasions where I think that would be a Good Idea (tm).

What I object to is building such a facility into core PHP, because:

1) You can already do it in userland, and I believe that's where it
belongs.

2) It unnecessarily [see 1] complicates core PHP, whose major
strengths that drive its success includes its simplicity.

 No matter which way you twist this pretzel:

I had hoped that this bit would hint that all the proposals along
these lines, including yours, are proposals I would vote against, even
though I did over-blow your actual proposal.

 -1

 So what it sounds like you're -1ing to, is not actually what was
 proposed...

 I'm starting to work on a patch for this as a proof of concept...

Please do so!

I'll still vote -1, but obviously others will vote as they see fit.

All these ideas are welcome.  The ones with complete patches even more
so, as they allow a true idea of what the change would mean.

Unfortunately, however, I must repeat that, so far, the idea has
always fallen flat on its face when the proposer actually attempts to
put action into deed, making a patch that fully meets their proposal.

That doesn't mean you can't succeed, if you are more skilled than all
your predecessors.

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

On Mon, February 27, 2012 10:45 am, Ángel González wrote:
 On 27/02/12 17:19, Richard Lynch wrote:
 PRESUMPTION:

 *ANY* strict datatype could also be NULL, to represent a failure
 condition...

 Otherwise, when you are out of RAM:
 strict $o = new Object(); //violates strict, because Object HAS to
 be
 NULL, as there is no RAM left for it to be an object.
 Uh? No. You would get a fatal error because PHP exceeded maximum
 allowed memory.

You are correct.

I'd have to come up with some OTHER scenario not involving fatal
error, such as:

strict $db = new DB();

and your database being down, unavailable, or connection parameters
being wrong.

The principle remains.

You probably still want $db to be NULL in that situation, rather than
an unusable DB object.

Otherwise, you'll have to write a lot more sanity checking code
elsewhere, which is what you are trying to avoid in the first place...

Or, perhaps not.

Perhaps you really do want this case to just plain bomb out with a
failure that the $db is not strictly an object, with no recourse to
try again, or deal with the error in application logic...

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting

2012-02-27 Thread Matthew Weier O'Phinney

On 2012-02-27, Richard Lynch c...@l-i-e.com wrote:
 On Mon, February 27, 2012 9:20 am, Anthony Ferrara wrote:
   I have to say that no matter how much a luv my OOP, turning every
   built-in type into an Object is just a Bad Idea...
  
   It's a form of bloat on RAM and CPU with minimal added value, imho.
 
  Re-read what I had written.  I never said to turn every built-in type
  into an object.  In fact, what I was talking about was keeping and
  preserving the base types as-is.  All that I was proposing was adding
  the ability to cast from and to the primitives.  That way you could
  silently convert back and forth as needed (transparently when
  possible).
 

 I apologize that my brevity has been misconstrued.

 You are certainly free, even with the tools available in PHP, to
 wrap an object around integers, strings, and so on.

 There may even be occasions where I think that would be a Good Idea (tm).

 What I object to is building such a facility into core PHP, because:

 1) You can already do it in userland, and I believe that's where it
 belongs.

Actually, you can't. The point of Anthony's proposal is that while we
_can_ wrap scalar types in objects, that fails for the instances where
you need to perform operations with them. This is why he's proposing the
ability to cast to and from these scalar objects, and have calls in
the engine that would do the casting on-demand.

 2) It unnecessarily [see 1] complicates core PHP, whose major
 strengths that drive its success includes its simplicity.

The flip-side of the argument is that if many developers are doing code
like this over and over again:

public function setNumber($number)
{
if (!is_scalar($number)) {
throw new InvalidArgumentException('Need a number!');
}
$this-number = (int) $number;
}

... then it may be time for the language to make this easier.

(And just because _you_ or a subset of developers on internals don't
write code this way does not mean a _majority_ of developers do not.)

-- 
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework  | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

Now, to rewind a bit past the latest chunk of I hate this idea posts

I'd like to suggest a new term:  strong.

This term would be similar to weak, except with a few key differences:

   - Weak would behave very much like Arvids suggested in his earlier post;
   i.e. if the variable is an integer but you pass a string (like aaa) to
   it, a warning would be thrown and PHP would attempt to convert it (i.e. it
   would become 1).
   - Strong, on the other hand, would throw a fatal error if you attempted
   to pass an incompatible value to an array.  Or, to put it another way, if
   the converted value does not match the original value.  For example, if
   we're assigning aaa to an integer, that would convert to 1; and, since
   1 != aaa, a fatal error would be thrown.  On the other hand, if you
   were to pass the string 1 to that integer variable, it would convert to
   1; and, since 1 == 1, there wouldn't be a problem.
   - In both instances, if the converted value matches the original (i.e.
   1 == 1), no warning error would be displayed.  Should it perhaps display
   a notice though?  Or no error at all?  I can think of reasonable arguments
   on both sides of that question.

This new term would also make it easier for us to avoid using the term
strict, which would explode even in the case of 1 == 1.

Whether this should be done at the function level, the variable level, or
both is an open-ended question.


Some possible examples of how this would look:

weak int $i = aaa;  // Converts to 1 and throws a warning.
strong int $ii = aaa; // Throws a fatal error.
weak int $i = 1; // Converts to 1.
strong int $ii = 1; // Converts to 1.


--Kris


On Mon, Feb 27, 2012 at 10:53 AM, Kris Craig kris.cr...@gmail.com wrote:

 +1 what Anthony said.

 Guys, seriously.  Some of these responses have been downright rude and
 inappropriate for a constructive dialogue.  Please do not pollute this
 thread with cliche, Just find another language and get out! posts.  It
 doesn't add anything to the conversation and instead just creates needless
 anger and animosity.  It's immature and just makes it look like we're
 incapable of having a rational discussion.

 So, let me outline a list of arguments that will carry ZERO weight on
 this thread:

- If you don't like PHP as it is, goto Java (or some other language)!
- We've already talked about this before.  Therefore, we must never
speak of it again.
- This is impossible.  Why?  Because I said so.  You want evidence?
Fuck you.
- But this would require significant changes to the core source
code!  We'd never be able to find enough sacrificial penguins to appease
the gods!
- Anyone who likes this idea is either stupid or not a 'true' PHP
developer.
- If you disagree with me, it means you haven't done your homework
because I'm always right.
- Strict typing would break everything!  What?  You're not talking
about C-like strict typing?  Sorry, I didn't catch that.  Strict typing
would break everything!
- I don't care if you've already countered my argument.  I'll just
keep repeating myself as if you didn't.


 Variations of the above statements have been posted ad nauseum.  They're
 all based on logical fallacies and are not constructive.

 I'm putting this out there:  If anyone posts one or more of the above
 arguments yet again on this topic, I will personally extract one of your
 kidneys and sell it to a questionable dog food company in Shanghai.  I
 will then openly mock your intellectual laziness and encourage people to
 ignore you.  ;P


 I'd love to prove Daniel wrong, but I think he may be on to something
 :\

 --Kris



 On Mon, Feb 27, 2012 at 9:38 AM, Anthony Ferrara ircmax...@gmail.comwrote:

  no, it is: come back after you did your homework, and you can provide
 new
  arguments to the discussion


 To be completely fair, I did homework on this.  I went back to 2000 on
 marc.info's archives and read almost all of the 400 posts matching the
 search http://marc.info/?l=php-internalsw=2r=13s=strict+typingq=b
 and a bunch of the posts on
 http://marc.info/?l=php-internalsw=2r=54s=type+hintingq=b

 The vast majority of what I found were quite good arguments for
 including the feature.  I found quite a bit of this was discussed to
 death, do your homework and provide new arguments.  What's odd, is
 that one of the earliest on-topic threads that I found (2007:
 http://marc.info/?l=php-internalsm=119514660125258w=2 ) had this as
 the third reply.  The only on-topic discussion that I found prior to
 that was in 2006 (almost exactly 1 year prior:
 http://marc.info/?l=php-internalsm=116257685415135w=2 ).

 Discussed to death.  Yet only one time before (discussing a specific
 patch)...

 And the opponents still said no...

 There were also quite a few problems identified with scalar hinting
 and auto-casting vs strict erroring.  However, there were also
 solutions proposed to nearly each and every one of

Re: [PHP-DEV] Scalar type hinting

On Mon, February 27, 2012 11:38 am, Anthony Ferrara wrote:
 Discussed to death.  Yet only one time before (discussing a specific
 patch)...

Did you go back to the old, old, old PHP list (and was it PHP-dev back
then?), before it split into php-general and php-internals and php-*,
back when there weren't enough users to warrant more than two lists?

You may find more fruitful results there, I think.

Or not.

Did you check the wiki and RFCs that came out of those discussions?

Those are the places where the really serious proposals with patches
developed after the mailing list wrangling.

They all failed, in the end, but those are the ones that actually got
taken seriously, because they had enough specificity to discuss for or
against for technical merit.

The idea has always always had some technical merit.  The
implementation, however, has always failed.

The very strict typing usually failed quickly.

The not so strict typing either failed after a lot of effort, and edge
cases kept cropping up, or ended up being so weak as to not provide
any additional value over the original dynamic typing.

The patches are out there.  The conclusions and technical issues are
out there.  They may be lost in the sea of flame-wars, but they do
exist.

 If you don't like this feature, and you can explain from a TECHNICAL
 perspective why, please do so!  If you don't like the feature, and are
 going to lean on It's not Java, or We've discussed this to death
 already, please don't...

Stas has already stated that you can't do what you want and have it
mean anything without changing the very nature of PHP.

I said the same, poorly, and invite you to TRY with a patch instead of
discussing it endlessly here.

 And to be fair: and you can provide new arguments to the discussion
 has already happened quite a bit (dating back the past 5 years), but
 those arguments were ignored or overruled for political reasons.

Write the proof of concept patch, please.

Then we can discuss the technical merits or prove why it won't work.

Otherwise, it really is an endless discussion of a dead horse.

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

Err typo correction:  Strong, on the other hand, would throw a fatal error
if you attempted to pass an incompatible value to *a variable. (not an
array)

--Kris


On Mon, Feb 27, 2012 at 11:15 AM, Kris Craig kris.cr...@gmail.com wrote:

 Now, to rewind a bit past the latest chunk of I hate this idea posts

 I'd like to suggest a new term:  strong.

 This term would be similar to weak, except with a few key differences:

- Weak would behave very much like Arvids suggested in his earlier
post; i.e. if the variable is an integer but you pass a string (like aaa)
to it, a warning would be thrown and PHP would attempt to convert it (i.e.
it would become 1).
- Strong, on the other hand, would throw a fatal error if you
attempted to pass an incompatible value to an array.  Or, to put it another
way, if the converted value does not match the original value.  For
example, if we're assigning aaa to an integer, that would convert to 1;
and, since 1 != aaa, a fatal error would be thrown.  On the other hand,
if you were to pass the string 1 to that integer variable, it would
convert to 1; and, since 1 == 1, there wouldn't be a problem.
- In both instances, if the converted value matches the original (i.e.
1 == 1), no warning error would be displayed.  Should it perhaps display
a notice though?  Or no error at all?  I can think of reasonable arguments
on both sides of that question.

 This new term would also make it easier for us to avoid using the term
 strict, which would explode even in the case of 1 == 1.

 Whether this should be done at the function level, the variable level, or
 both is an open-ended question.


 Some possible examples of how this would look:

 weak int $i = aaa;  // Converts to 1 and throws a warning.
 strong int $ii = aaa; // Throws a fatal error.
 weak int $i = 1; // Converts to 1.
 strong int $ii = 1; // Converts to 1.


 --Kris



 On Mon, Feb 27, 2012 at 10:53 AM, Kris Craig kris.cr...@gmail.com wrote:

 +1 what Anthony said.

 Guys, seriously.  Some of these responses have been downright rude and
 inappropriate for a constructive dialogue.  Please do not pollute this
 thread with cliche, Just find another language and get out! posts.  It
 doesn't add anything to the conversation and instead just creates needless
 anger and animosity.  It's immature and just makes it look like we're
 incapable of having a rational discussion.

 So, let me outline a list of arguments that will carry ZERO weight on
 this thread:

- If you don't like PHP as it is, goto Java (or some other
language)!
- We've already talked about this before.  Therefore, we must never
speak of it again.
- This is impossible.  Why?  Because I said so.  You want evidence?
Fuck you.
- But this would require significant changes to the core source
code!  We'd never be able to find enough sacrificial penguins to appease
the gods!
- Anyone who likes this idea is either stupid or not a 'true' PHP
developer.
- If you disagree with me, it means you haven't done your homework
because I'm always right.
- Strict typing would break everything!  What?  You're not talking
about C-like strict typing?  Sorry, I didn't catch that.  Strict typing
would break everything!
- I don't care if you've already countered my argument.  I'll just
keep repeating myself as if you didn't.


 Variations of the above statements have been posted ad nauseum.  They're
 all based on logical fallacies and are not constructive.

 I'm putting this out there:  If anyone posts one or more of the above
 arguments yet again on this topic, I will personally extract one of your
 kidneys and sell it to a questionable dog food company in Shanghai.  I
 will then openly mock your intellectual laziness and encourage people to
 ignore you.  ;P


 I'd love to prove Daniel wrong, but I think he may be on to
 something  :\

 --Kris



 On Mon, Feb 27, 2012 at 9:38 AM, Anthony Ferrara ircmax...@gmail.comwrote:

  no, it is: come back after you did your homework, and you can provide
 new
  arguments to the discussion


 To be completely fair, I did homework on this.  I went back to 2000 on
 marc.info's archives and read almost all of the 400 posts matching the
 search http://marc.info/?l=php-internalsw=2r=13s=strict+typingq=b
 and a bunch of the posts on
 http://marc.info/?l=php-internalsw=2r=54s=type+hintingq=b

 The vast majority of what I found were quite good arguments for
 including the feature.  I found quite a bit of this was discussed to
 death, do your homework and provide new arguments.  What's odd, is
 that one of the earliest on-topic threads that I found (2007:
 http://marc.info/?l=php-internalsm=119514660125258w=2 ) had this as
 the third reply.  The only on-topic discussion that I found prior to
 that was in 2006 (almost exactly 1 year prior:
 http://marc.info/?l=php-internalsm=116257685415135w=2 ).

 Discussed to death.  Yet only

Re: [PHP-DEV] Scalar type hinting

On Mon, 2012-02-27 at 13:05 -0600, Richard Lynch wrote:
 
 I'd have to come up with some OTHER scenario not involving fatal
 error, such as:
 
 strict $db = new DB();

The example is wrong. The new operator will always return an instance of
the given class (or there will be an exception). Use

strict $db = DB::factory();

for your example instead.

johannes



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

Ok, fine.  We get it.  You don't think this can be done.  Duly noted.

Now that you've voiced your opposition, can we please dedicate this topic
to discussing how this can be done?  If you think we're wasting our time,
then ok; it's our time to waste.  I'd be happy to take you up on your
challenge to try to implement this, but first we have to brainstorm what
exactly we'll be doing.  And that'll be much easier if we don't have to
keep sifting through duplicate posts about why this is a bad idea.  Let's
just set that aside for now so we can brainstorm.


On that note, I would like to direct everyone's attention to my last post
where I suggested a new strong concept.

--Kris


On Mon, Feb 27, 2012 at 11:16 AM, Richard Lynch c...@l-i-e.com wrote:

 On Mon, February 27, 2012 11:38 am, Anthony Ferrara wrote:
  Discussed to death.  Yet only one time before (discussing a specific
  patch)...

 Did you go back to the old, old, old PHP list (and was it PHP-dev back
 then?), before it split into php-general and php-internals and php-*,
 back when there weren't enough users to warrant more than two lists?

 You may find more fruitful results there, I think.

 Or not.

 Did you check the wiki and RFCs that came out of those discussions?

 Those are the places where the really serious proposals with patches
 developed after the mailing list wrangling.

 They all failed, in the end, but those are the ones that actually got
 taken seriously, because they had enough specificity to discuss for or
 against for technical merit.

 The idea has always always had some technical merit.  The
 implementation, however, has always failed.

 The very strict typing usually failed quickly.

 The not so strict typing either failed after a lot of effort, and edge
 cases kept cropping up, or ended up being so weak as to not provide
 any additional value over the original dynamic typing.

 The patches are out there.  The conclusions and technical issues are
 out there.  They may be lost in the sea of flame-wars, but they do
 exist.

  If you don't like this feature, and you can explain from a TECHNICAL
  perspective why, please do so!  If you don't like the feature, and are
  going to lean on It's not Java, or We've discussed this to death
  already, please don't...

 Stas has already stated that you can't do what you want and have it
 mean anything without changing the very nature of PHP.

 I said the same, poorly, and invite you to TRY with a patch instead of
 discussing it endlessly here.

  And to be fair: and you can provide new arguments to the discussion
  has already happened quite a bit (dating back the past 5 years), but
  those arguments were ignored or overruled for political reasons.

 Write the proof of concept patch, please.

 Then we can discuss the technical merits or prove why it won't work.

 Otherwise, it really is an endless discussion of a dead horse.

 --
 brain cancer update:
 http://richardlynch.blogspot.com/search/label/brain%20tumor
 Donate:

 https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: PHP 6 include E_NOTICE in default php.ini

I think it's a good idea, though I'm not sure it should be done in the
production one as well.  I'm not sure, but I think these errors are
generally suppressed in production because of potential security concerns
involved in making those errors public.

I would suggest amending the RFC so that it only applies to
php.ini-development.  Other than that, I like it.

--Kris


On Mon, Feb 27, 2012 at 8:01 AM, Richard Lynch c...@l-i-e.com wrote:

 As promised in another thread, I have created a formal RFC on the
 topic of including E_NOTICE in the default php.ini.* files.

 Please note that I am specifically not proposing E_STRICT nor
 E_DEPRECATED in this RFC, as I believe the each need to be considered
 on their own merits, and not lumped into one decision nor even
 conversation.

 https://wiki.php.net/rfc/error_reporting_e_notice

 My first formal RFC, so please be gentle :-)

 --
 brain cancer update:
 http://richardlynch.blogspot.com/search/label/brain%20tumor
 Donate:

 https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

2012-02-27 Thread John LeSueur

On Mon, Feb 27, 2012 at 12:15 PM, Kris Craig kris.cr...@gmail.com wrote:

Now, to rewind a bit past the latest chunk of I hate this idea posts

I'd like to suggest a new term: strong.

This term would be similar to weak, except with a few key differences:

- Weak would behave very much like Arvids suggested in his earlier post;
i.e. if the variable is an integer but you pass a string (like aaa) to
it, a warning would be thrown and PHP would attempt to convert it (i.e.
it
would become 1).
- Strong, on the other hand, would throw a fatal error if you attempted
to pass an incompatible value to an array. Or, to put it another way, if
the converted value does not match the original value. For example, if
we're assigning aaa to an integer, that would convert to 1; and, since
1 != aaa, a fatal error would be thrown. On the other hand, if you
were to pass the string 1 to that integer variable, it would convert to
1; and, since 1 == 1, there wouldn't be a problem.
- In both instances, if the converted value matches the original (i.e.
1 == 1), no warning error would be displayed. Should it perhaps
display
a notice though? Or no error at all? I can think of reasonable
arguments
on both sides of that question.

This new term would also make it easier for us to avoid using the term
strict, which would explode even in the case of 1 == 1.

Whether this should be done at the function level, the variable level, or
both is an open-ended question.

Some possible examples of how this would look:

weak int $i = aaa; // Converts to 1 and throws a warning.
strong int $ii = aaa; // Throws a fatal error.
weak int $i = 1; // Converts to 1.
strong int $ii = 1; // Converts to 1.

--Kris

Maybe this discussion should start from the end of the last discussion on
non-strict type hints, where really smart people came up with some options
to handle the conversion:

https://wiki.php.net/rfc/typecheckingstrictandweak#option_1_current_type_juggeling_rules_with_e_strict_on_data_loss

The RFC talks about throwing E_STRICT or E_FATAL, and has a couple of
options for a matrix of conversion rules.

I don't think we need another name for weak type hints, since the name
covers anything less than strict, and anything more than none. There's been
enough confusion about the names of things without adding another name for
a variation of weak type hints.

If I recall, the previous effort died due to the emotional stress of
getting to the point where the differences between strict type hints and
non-strict type hints was well understood, and everyone's position on those
two points was crystallized. There were still a few proponents of strict
type hints, but it seemed they were willing to live with non-strict type
hints. At that point, everyone became more interested in having a 5.4, and
scalar type hints were left for a time.

Hopefully I haven't mischaracterized anyone's position, but I hope it helps
us move beyond previously trod ground.

John

Re: [PHP-DEV] Scalar type hinting

On Mon, February 27, 2012 1:15 pm, Kris Craig wrote:
 Now, to rewind a bit past the latest chunk of I hate this idea
 posts

 I'd like to suggest a new term:  strong.

 This term would be similar to weak, except with a few key
 differences:

- Weak would behave very much like Arvids suggested in his earlier
 post;
i.e. if the variable is an integer but you pass a string (like
 aaa) to
it, a warning would be thrown and PHP would attempt to convert it
 (i.e. it
would become 1).

Nitpick:
Two backwards compatibility breaks:
1) Throwing E_WARNING
2) aaa converted to (int) is 0.

- Strong, on the other hand, would throw a fatal error if you
 attempted
to pass an incompatible value to an array.  Or, to put it another
 way, if
the converted value does not match the original value.  For
 example, if
we're assigning aaa to an integer, that would convert to 1; and,
 since
1 != aaa, a fatal error would be thrown.  On the other hand, if
 you
were to pass the string 1 to that integer variable, it would
 convert to
1; and, since 1 == 1, there wouldn't be a problem.

Converting aaa to 1 causes the error...

Converting aaa to the backwards-compatible means aaa == 0 will
return TRUE, and your test for reverse engineering will not help.

This is still a nitpick, as I'm sure you could eventually come up with
some way to validate your strict-ness of conversion.

It would be more cumbersome and slower than using PCRE or ctype_* to
validate or === to guarantee the data types match.

But you can do it.

And I'd love to see an extensive patch in an RFC rather than this
endless back-and-forth.

Neither Stas nor I are saying it shouldn't be done.

We're saying it's been tried and failed, but if you want to be the
little engine that could, the proper place is in an RFC with a
community-drive patch that can be evaluated on technical merit.

- In both instances, if the converted value matches the original
 (i.e.
1 == 1), no warning error would be displayed.  Should it perhaps
 display
a notice though?  Or no error at all?  I can think of reasonable
 arguments
on both sides of that question.

I'm pretty sure backwards-compatibility is going to trump, and no
error at all will win out.

 This new term would also make it easier for us to avoid using the term
 strict, which would explode even in the case of 1 == 1.

This is a good idea to distinguish between strict typing throughout,
and judiciously applied strict typing.

I fully support calling it strong for clarity purposes.

 Whether this should be done at the function level, the variable level,
 or
 both is an open-ended question.

 weak int $i = aaa;  // Converts to 1 and throws a warning.

What purpose would 'weak' serve?

If you want the old default behavior, just leave out the 'weak'.

And we already have (int) $i = aaa // converts to 0 as ztype int.

Or perhaps I'm missing something where 'weak' is supposed to invert
the current logic of aaa - 0 and you actually want it to be 1 and
not backwards compatible?

I must be missing something here, then, because that just plain
doesn't make sense to me, personally.

 strong int $ii = aaa; // Throws a fatal error.

Okay.

E_FATAL seems drastic to me, but I'm not even going to use strong so
don't really care either way, I suppose.

I can always set my error handler to over-ride the level of your
error, and even pick out the specifics to change it to whatever I
want...

I respectfully suggest you'll want to discuss the actual level of
error among proponents of the strong typing, and put the consensus in
the RFC.

 weak int $i = 1; // Converts to 1.

Again, old-school (int) or set_type covers this.

Adding new keywords to fulfill the same purpose seems like bloat to me...

 strong int $ii = 1; // Converts to 1.

Okay.

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] APXS LoadModule Option in configure

@Richard I think, briefly, something like that was implemented.  However,
it was reverted soon after because it changed the default behavior of
configure.  This was discovered to be a problem after people realized that,
if -a is not specified, APXS will not only skip writing the LoadModule
line, but for some inexplicable reason it will also strip the existing
LoadModule line if it's already there.

I'm guessing that's probably what you're remembering.  This RFC differs in
that the default behavior of configure will remain unchanged.

@Lester Generally, this is a problem that surfaces in manual PHP builds.
You're correct in that the packaged repos tend to handle all that stuff for
you anyway.  However, these repos are rarely updated (I think CentOS and
Ubuntu are both still stuck on 5.1), so it's often necessary to build PHP
manually if you want to take advantage of the latest features.  In these
cases, being able to isolate the PHP configuration tends to make the most
sense, hence why this new option switch is necessary IMHO.

--Kris


On Mon, Feb 27, 2012 at 8:59 AM, Richard Lynch c...@l-i-e.com wrote:

 On Fri, February 24, 2012 6:14 pm, Kris Craig wrote:
  No, it happens and it's even clearly documented in APXS.
 
  Basically, if you specify the -a option in APXS, it overwrites your
  httpd.conf (or apache.conf or whatever it is on your system) and adds
  the
  LoadModule line to it.  In PHP's configure script, you'll notice that
  -a
  is always specified; there's no option to use APXS without it.  As a
  result, make install will always overwrite your LoadModule entry in
  httpd.conf if APXS is enabled.  The problem occurs when you have
  LoadModule
  in an included .conf file already; APXS does not have the ability to
  detect
  that.  Therefore, a duplicate LoadModule entry is added to
  httpd.conf by
  APXS, and thus the clash occurs.  This behavior has been reproduced
  numerous times.
 
 
  I think the RFC is pretty clear on how this works.  Nobody else has
  expressed confusion thus far.  I could clarify further but I'm not
  sure
  how; it's pretty straight-forward, really.  I'm not sure what may have
  been
  happening in your case or if perhaps you misunderstood what this RFC
  is
  about.  Either way, I would recommend you create a fresh Linux-based
  build
  environment, build Apache 2.2 and PHP 5.3.10 yourself (i.e. stay away
  from
  yum/apt-get), then attempt to generate an APXS-enabled Makefile using
  PHP's
  configure script that does not activate APXS with the -a option.  It
  might also be a good idea for you to check-out the APXS documentation
  (I
  included a link to it on the RFC).
 
  Those steps should enable you to reproduce this.  =)

 Once upon a time, a lonng time ago, I read through the configure /
 make process, and I *thought* there was logic there to try to detect
 if your httpd.conf diverged significantly from the default, and, if
 so, it would choose NOT to add the LoadModule line, assuming you were
 a power user who had it somewhere else...

 I could be mis-remembering. This logic could have been removed. I
 could be hallucinating.  The logic I saw could have been doing
 something entirely difference, as I have only a vague notion of how
 configure/make works in the first place.  It could have been some
 other project.

 Or this could account for your different experiences, based on whether
 you hacked httpd.conf enough or started with a fresh out of the
 box one and didn't touch it until after installing PHP.

 ymmv
 ianal

 --
 brain cancer update:
 http://richardlynch.blogspot.com/search/label/brain%20tumor
 Donate:

 https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE

Re: [PHP-DEV] Scalar type hinting

On Mon, February 27, 2012 1:22 pm, Kris Craig wrote:
 Now that you've voiced your opposition, can we please dedicate this
 topic
 to discussing how this can be done?  If you think we're wasting our
 time,
 then ok; it's our time to waste.  I'd be happy to take you up on your
 challenge to try to implement this, but first we have to brainstorm
 what
 exactly we'll be doing.  And that'll be much easier if we don't have
 to
 keep sifting through duplicate posts about why this is a bad idea.
 Let's
 just set that aside for now so we can brainstorm.

Last post on this topic:

Would you please consider creating a separate list or wiki page or
incomplete RFC, so that those of us who consider the discussion
fruitless from past experience can ignore it until it crystallizes a
bit more?

A weekly update to the list, or even daily, of the progress would be
quite reasonable, and keep everybody in the loop, without the details
and less flames.

I truly believe this will be a more constructive use of your time, and
ours, or I would not ask it of you.

Thanks!

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: PHP 6 include E_NOTICE in default php.ini

On Mon, February 27, 2012 1:33 pm, Kris Craig wrote:
 I think it's a good idea, though I'm not sure it should be done in the
 production one as well.  I'm not sure, but I think these errors are
 generally suppressed in production because of potential security
 concerns
 involved in making those errors public.

I would contend that if you have any errors at any level of E_* going
out over HTTP, you have done it wrong.

It is true that in the days of register_globals, the E_NOTICE going to
the HTML was a gold-mine for abusers of potential security threats.

But all of E_* messages are also goldmines of the same ilk.

That said,

 I would suggest amending the RFC so that it only applies to
 php.ini-development.  Other than that, I like it.

If most cheap webhosts chose php.ini-development, I'd be okay with
this, as it probably is not suitable for PRODUCTION environments for
the experts.

Unfortunately, most cheap webhosts go with php.ini-production, as they
are production environments, and the unwashed masses of users of said
cheap webhosts are the target audience of the proposal.

As stated in the RFC, the experts can and will change their php.ini to
their taste in each environment: It's the masses of users who don't
even know there is a choice that are being hurt by the current default
setting, writing bad code, asking questions of obvious typos that
E_NOTICE would catch, and remaining un-educated for too long that they
develop bad habits.

Not that I think this will eliminate newbie postings.  There will
always be those who don't even read or comprehend the most clear error
messages.

But I think it will reduce the number of postings by newbies who are
tripped up by the typical mistakes E_NOTICE exposes.


PS
I want to thank you for your reasoned response, especially given the
other thread we are involved in!

-- 
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

2012-02-27 Thread Gustavo Lopes

On Mon, 27 Feb 2012 20:09:08 +0100, Johannes Schlüter  
johan...@schlueters.de wrote:



On Mon, 2012-02-27 at 13:05 -0600, Richard Lynch wrote:


I'd have to come up with some OTHER scenario not involving fatal
error, such as:

strict $db = new DB();


The example is wrong. The new operator will always return an instance of
the given class (or there will be an exception).
[...]



This is not true. The new operator can return NULL. In fact, the intl  
extension uses this extensively:


$ php -d extension=intl.so -r 'var_dump(new Collator());'

Warning: Collator::__construct() expects exactly 1 parameter, 0 given in  
Command line code on line 1

NULL

(in fact, I think it's also leaking the object in this case as it should  
call zval_dtor before using RETURN_NULL, something I'll look closer to  
when I have the time)


Contrast with:

?php
class A {
function __construct($a) {}
}
var_dump(new A());

Warning: Missing argument 1 for A::__construct(), called in - on line 5  
and defined in - on line 3

object(A)#1 (0) {
}


--
Gustavo Lopes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

2012-02-27 Thread Gustavo Lopes

On Mon, 27 Feb 2012 20:09:08 +0100, Johannes Schlüter  
johan...@schlueters.de wrote:



On Mon, 2012-02-27 at 13:05 -0600, Richard Lynch wrote:


I'd have to come up with some OTHER scenario not involving fatal
error, such as:

strict $db = new DB();


The example is wrong. The new operator will always return an instance of
the given class (or there will be an exception). Use



This is not true. The new operator can return NULL. The intl extension  
uses this extensively:



--
Gustavo Lopes

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

On Mon, 2012-02-27 at 21:05 +0100, Gustavo Lopes wrote:
 On Mon, 27 Feb 2012 20:09:08 +0100, Johannes Schlüter  
 johan...@schlueters.de wrote:
 
  On Mon, 2012-02-27 at 13:05 -0600, Richard Lynch wrote:
 
  I'd have to come up with some OTHER scenario not involving fatal
  error, such as:
 
  strict $db = new DB();
 
  The example is wrong. The new operator will always return an instance of
  the given class (or there will be an exception).
  [...]
 
 
 This is not true. The new operator can return NULL. In fact, the intl  
 extension uses this extensively:

ok, internal stuff can do everything it wants. But it shouldn't. Doing
that is really bad and I wasn't aware of that case. :-)

And since it's bad another example should be used :-)

johannes


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: PHP 6 include E_NOTICE in default php.ini

2012-02-27 Thread Philip Olson

Hi Richard,

I'm a little confused. Showing E_NOTICE errors is already the default 
with both php.ini-* files. What does this RFC change? Are you proposing 
that the PHP default value (without a php.ini) be modified?

; error_reporting
;   Default Value: E_ALL  ~E_NOTICE  ~E_STRICT  ~E_DEPRECATED
;   Development Value: E_ALL
;   Production Value: E_ALL  ~E_DEPRECATED  ~E_STRICT

Regards,
Philip

Ref: 
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/php.ini-production?view=markup


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC: PHP 6 include E_NOTICE in default php.ini

2012-02-27 Thread Simon Schick

Hei, Richard

I've looked into the php.ini.* files of PHP 5.4 for windows and saw the
following line in *production*:
error_reporting = E_ALL ~E_DEPRECATED ~E_STRICT
display_errors = On
log_errors = On

and the following line in *development*:
error_reporting = E_ALL
display_errors = Off
log_errors = On

I also looked up the function error_reporting and came around that:
http://no.php.net/manual/en/errorfunc.configuration.php#ini.error-reporting
http://php.net/manual/en/function.error-reporting.php#refsect1-function.error-reporting-changelog

The first link seems to contain some out-dated information ... That was the
reason why you raised the RFC, right?

Here's how I understood the second link and the settings I found in the
windows version:
You'll get every message reported by the php-parser in your log by default
if you're working using the development version and won't get any
deprecated and strict messages in *production*. If this messages are
written into a log-file or passed to the output is up to the rest of the
settings where in both environments both they're written into the
error-log-file but only *development *it is additionally visible to the
user.

So for the windows environment (if you'd ask me) this seems solved. I have
not looked into the other environments yet.
If they are not the same we should work to keep the default-configuration
in one way, whatever OS you're working on.

Bye
Simon

2012/2/27 Richard Lynch c...@l-i-e.com

On Mon, February 27, 2012 1:33 pm, Kris Craig wrote:
I think it's a good idea, though I'm not sure it should be done in the
production one as well. I'm not sure, but I think these errors are
generally suppressed in production because of potential security
concerns
involved in making those errors public.

I would contend that if you have any errors at any level of E_* going
out over HTTP, you have done it wrong.

It is true that in the days of register_globals, the E_NOTICE going to
the HTML was a gold-mine for abusers of potential security threats.

But all of E_* messages are also goldmines of the same ilk.

That said,

I would suggest amending the RFC so that it only applies to
php.ini-development. Other than that, I like it.

If most cheap webhosts chose php.ini-development, I'd be okay with
this, as it probably is not suitable for PRODUCTION environments for
the experts.

Unfortunately, most cheap webhosts go with php.ini-production, as they
are production environments, and the unwashed masses of users of said
cheap webhosts are the target audience of the proposal.

As stated in the RFC, the experts can and will change their php.ini to
their taste in each environment: It's the masses of users who don't
even know there is a choice that are being hurt by the current default
setting, writing bad code, asking questions of obvious typos that
E_NOTICE would catch, and remaining un-educated for too long that they
develop bad habits.

Not that I think this will eliminate newbie postings. There will
always be those who don't even read or comprehend the most clear error
messages.

But I think it will reduce the number of postings by newbies who are
tripped up by the typical mistakes E_NOTICE exposes.

PS
I want to thank you for your reasoned response, especially given the
other thread we are involved in!

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:

https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting

Rich,

I appreciate the candid and honest nature of your reply, while
maintaining civility.  This list needs more of that. Further replies
inline:

On Mon, Feb 27, 2012 at 1:54 PM, Richard Lynch c...@l-i-e.com wrote:
 On Mon, February 27, 2012 9:20 am, Anthony Ferrara wrote:
 I have to say that no matter how much a luv my OOP, turning every
 built-in type into an Object is just a Bad Idea...

 It's a form of bloat on RAM and CPU with minimal added value, imho.

 Re-read what I had written.  I never said to turn every built-in type
 into an object.  In fact, what I was talking about was keeping and
 preserving the base types as-is.  All that I was proposing was adding
 the ability to cast from and to the primitives.  That way you could
 silently convert back and forth as needed (transparently when
 possible).


 I apologize that my brevity has been misconstrued.

 You are certainly free, even with the tools available in PHP, to
 wrap an object around integers, strings, and so on.

 There may even be occasions where I think that would be a Good Idea (tm).

Well, you can kind of do it now.  You can't directly operate on those
objects.  You need to first manually cast them back to the native
type.  Take a look at SplFixedArray (
http://www.php.net/manual/en/class.splfixedarray.php ).  It has a pair
of methods, a static fromArray(), and a instance toArray().  What I'm
talking about is adding the ability to push these conversions down to
the engine level.

 What I object to is building such a facility into core PHP, because:

 1) You can already do it in userland, and I believe that's where it
 belongs.

Actually, almost exactly the opposite.  You can't do it in userland,
but you can in a PECL extension (via cast_object(), get() and set()).
The first part of this proposal is basically just exposing those
methods (almost 1:1, only consolidating cast_object and get into a
single method with a parameter defining the difference).

 2) It unnecessarily [see 1] complicates core PHP, whose major
 strengths that drive its success includes its simplicity.

Actually, the first part of the proposal doesn't really change the
core that much.  All it does is add standard object handlers to expose
cast_object (which is already partially exposed via __toString), get
and set (which are currently null).  There shouldn't really be other
changes required to the core for the first part at least.

The second part of the proposal (the castFrom auto-casting) would
require some more changes to the core, and be much more significant.
To be honest, I think that would be a separate effort (and a separate
RFC) the more I think about it.

 No matter which way you twist this pretzel:

 I had hoped that this bit would hint that all the proposals along
 these lines, including yours, are proposals I would vote against, even
 though I did over-blow your actual proposal.

 -1

 So what it sounds like you're -1ing to, is not actually what was
 proposed...

 I'm starting to work on a patch for this as a proof of concept...

 Please do so!

 I'll still vote -1, but obviously others will vote as they see fit.

 All these ideas are welcome.  The ones with complete patches even more
 so, as they allow a true idea of what the change would mean.

 Unfortunately, however, I must repeat that, so far, the idea has
 always fallen flat on its face when the proposer actually attempts to
 put action into deed, making a patch that fully meets their proposal.

 That doesn't mean you can't succeed, if you are more skilled than all
 your predecessors.

I don't think skill has that much to do with it.  I think the real key
difference is what's being attempted...

Anthony

 --
 brain cancer update:
 http://richardlynch.blogspot.com/search/label/brain%20tumor
 Donate:
 https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE



 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

I'm not sure what the precedent is for creating a separate list fork for a
specific topic.  Can one of you who knows the answer to that respond to
Richard's suggestion?

As for an RFC, I completely agree.  However, it's still a bit too vague to
create an RFC that would be of any value.  We at least have to brainstorm
conceptually where we want to go before an RFC could serve any purpose IMHO.

--Kris


2012/2/27 Johannes Schlüter johan...@schlueters.de

 On Mon, 2012-02-27 at 21:05 +0100, Gustavo Lopes wrote:
  On Mon, 27 Feb 2012 20:09:08 +0100, Johannes Schlüter
  johan...@schlueters.de wrote:
 
   On Mon, 2012-02-27 at 13:05 -0600, Richard Lynch wrote:
  
   I'd have to come up with some OTHER scenario not involving fatal
   error, such as:
  
   strict $db = new DB();
  
   The example is wrong. The new operator will always return an instance
 of
   the given class (or there will be an exception).
   [...]
 
 
  This is not true. The new operator can return NULL. In fact, the intl
  extension uses this extensively:

 ok, internal stuff can do everything it wants. But it shouldn't. Doing
 that is really bad and I wasn't aware of that case. :-)

 And since it's bad another example should be used :-)

 johannes


 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] bugs.php.net php 6

Wait, is the default going to be Unicode (wide, always 2 bytes per char, I.E. 
more memory consumption) or UTF-8 (1 byte for the first 127, more bytes for 
wider text, mostly unchanged memory consumption)? I thought it was originally a 
conversion to Unicode, but that was scrapped? Can someone clarify?

John Crenshaw
Priacta, Inc.

-Original Message-
From: Simon Schick [mailto:simonsimc...@googlemail.com] 
Sent: Monday, February 27, 2012 10:38 AM
To: Richard Lynch
Cc: Stas Malyshev; PHP Internals
Subject: Re: [PHP-DEV] bugs.php.net  php 6

Hi, Richard

The development of the unicode-as-default-charset should really be done within 
the next release coming after 5.4 I heared somewhere that it's nearly done ...
I would have happily seen it in 5.4 but as this release is late right now we 
have to wait ;)

Bye
Simon

p.s. *
http://www.php.net/manual/en/function.error-reporting.php#refsect1-function.error-reporting-changelog
*http://www.php.net/manual/en/function.error-reporting.php#refsect1-function.error-reporting-changelog


2012/2/27 Richard Lynch c...@l-i-e.com

 On Sun, February 26, 2012 2:03 am, Stas Malyshev wrote:
  Just discovered that our stock php 4 support discontinued message 
  in bugs looks like:
 
  We are sorry, but we can not support PHP 4 related problems anymore.
  Momentum is gathering for PHP 6, and we think supporting PHP 4 will 
  lead to a waste of resources which we want to put into getting PHP 6 
  ready.
 
  Unless I've missed something, the momentum for php 6 is very much 
  nonexistent, so we probably want to fix that message :)

 Isn't the emotional scarring of PHP 6 == Unicode far enough in the 
 past to start some momentum for PHP 6?

 I sure core Devs have thought about this, and have gone so far as to 
 make statements for what should be in PHP 6...

 PS
 If it isn't already, I want to write an RFC to change the default 
 error_reporting to include E_NOTICE.

 --
 brain cancer update:
 http://richardlynch.blogspot.com/search/label/brain%20tumor
 Donate:

 https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=F
 S9NLTNEEKWBE



 --
 PHP Internals - PHP Runtime Development Mailing List To unsubscribe, 
 visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

On Mon, Feb 27, 2012 at 6:38 PM, Anthony Ferrara ircmax...@gmail.comwrote:

no, it is: come back after you did your homework, and you can provide
new
arguments to the discussion

To be completely fair, I did homework on this. I went back to 2000 on
marc.info's archives and read almost all of the 400 posts matching the
search http://marc.info/?l=php-internalsw=2r=13s=strict+typingq=b
and a bunch of the posts on
http://marc.info/?l=php-internalsw=2r=54s=type+hintingq=b

that's nice.
as I mentioned in my previous (and maybe in some other) mail, I think that
it would be __really__ nice to have those discussions summarized.
sorry for replying your mail later than some others, but I was afraid of
the wall of text. :)

The vast majority of what I found were quite good arguments for
including the feature. I found quite a bit of this was discussed to
death, do your homework and provide new arguments. What's odd, is
that one of the earliest on-topic threads that I found (2007:
http://marc.info/?l=php-internalsm=119514660125258w=2 ) had this as
the third reply. The only on-topic discussion that I found prior to
that was in 2006 (almost exactly 1 year prior:
http://marc.info/?l=php-internalsm=116257685415135w=2 ).

Discussed to death. Yet only one time before (discussing a specific
patch)...

I only joined the lists like 3 years ago, but I remember discussing this
idea more than that.
I can dig up the threads if you are interested, the biggest discussion was
after Derick commited the scalar typehint patch from Ilia to trunk and
after a pretty heated and long discussion and multiple alternative
proposals the patch was reverted and Derick implemented a Reflection based
infrastructure for checking the typehints.

some history:
2006
http://derickrethans.nl/typehints-for-scalar-types.html
http://php.markmail.org/message/nalhrp5n5p3srj7u#query:+page:1+mid:nalhrp5n5p3srj7u+state:results
2008
https://wiki.php.net/rfc/typehint
2009
http://ilia.ws/archives/205-Type-hinting-for-PHP-5.3.html
http://schlitt.info/opensource/blog/0712_scalar_type_hints_in_php.html
2010
http://ilia.ws/archives/217-Scalar-Type-Hints-are-Here!.html
http://schlueters.de/blog/archives/139-Scalar-type-hints-in-PHP-trunk.html
http://schlueters.de/blog/archives/148-More-on-scalar-type-hints-in-PHP-trunk.html

And the opponents still said no...

with the new RFC process there is a rule of thumb/gentlemen agreement that
if a large portion of the core devs are against a specific change, then it
shouldn't be added, or to form it otherwise consensus should be reached
instead of pushing through changes by 50%+1 (or 66%+1).
this specific change was such a controversial one that we couldn't reach
conclusion..

There were also quite a few problems identified with scalar hinting
and auto-casting vs strict erroring. However, there were also
solutions proposed to nearly each and every one of them.

There were ideas, but they didn't have enough traction.
IMO we can't have a proper solution without changing the existing behavior
for complex types, if you implement strict typing for scalars that turns
the language strict typed, if you add dynamic/weak typing for the scalars,
you will have an inconsistent implementation.

And the opponents still said no...

to tell the truth they said no, but it was the original commiter who
reverted the change.
(sorry Derick, I don't remember the details, feel free to correct me on
this.)

It has been brought up time and time again. Solutions have been
proposed which have no fundimental issues (inconsistencies,
problematic operations - such as references, etc)...

maybe I missed those, what are you referring to?
I see the ones that I linked + the following:
https://wiki.php.net/rfc/typechecking

https://wiki.php.net/rfc/autoboxing
https://wiki.php.net/rfc/boxingandunboxing
https://wiki.php.net/rfc/splweaktypehintingwithautoboxing

And the opponents instead said this has been discussed to death, no...

nope, they first discussed to death. then when people without much insight
or knowledge without the past discussion brought back the topic, some
people felt that it is too soon to discuss it again, as nothing new is on
the table.

Please can you stop saying this has been discussed to death. To be
frank, don't stop the discussion because you don't like the idea. It
has been discussed to death. But the discussion has only really ever
involved people who are for it. The opponents by and large have used
two arguments: It has been discussed already, so no and don't make
PHP into Java.

I don't mind what others do with their free time, so feel free to discuss
it, but somehow it seems for that some people are wasting their time
running the same circles others did years before, and yelling others for
not reading through 50 mails (from which maybe 5-10 has insightful
comments) or wanting to discuss the topic in detail.
I really think that after seeing this as a hot topic as it is,

Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache

2012-02-27 Thread William A. Rowe Jr.

On 2/27/2012 6:58 AM, jpauli wrote:
 PHP through mod_php on Linux should compile without ZTS.
 
 configure script searches for apxs binary and tries to invoque apxs -q
 MPM to figure out what MPM has been compiled in Apache for the TS flag to
 be defined or not (thus, activating PHP ZTS, or not).

Right...

 Mainly on Linux, Apache should have been installed with prefork MPM ans
 apxs -q should return that, then configure should not define
 PHP_BUILD_THREAD_SAFE.

No, 2.2 and 2.4 don't default to prefork, it's suboptimal, most linux
distros have moved away from it...

 Recently we had a bug with the new Apache 2.4 API where apxs doesn't answer
 about the MPM configuration anymore, leading to a ZTS build by default.
 This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172.

Wrong fix.  Out of the box you don't know which mpm may be loaded, because
the mpm is now loadable (although a full daemon stop/start is necessary).
The only mod_php loadable under any circumstance is TS enabled.

If you want php/linux single-child, fastcgi is the only rational approach.

 I dont know anything about windows, sorry

Always threaded.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

On Mon, Feb 27, 2012 at 7:53 PM, Kris Craig kris.cr...@gmail.com wrote:

 +1 what Anthony said.

 Guys, seriously.  Some of these responses have been downright rude and
 inappropriate for a constructive dialogue.  Please do not pollute this
 thread with cliche, Just find another language and get out! posts.  It
 doesn't add anything to the conversation and instead just creates needless
 anger and animosity.  It's immature and just makes it look like we're
 incapable of having a rational discussion.

 So, let me outline a list of arguments that will carry ZERO weight on
 this thread:

- If you don't like PHP as it is, goto Java (or some other language)!
- We've already talked about this before.  Therefore, we must never
speak of it again.
- This is impossible.  Why?  Because I said so.  You want evidence?
Fuck you.
- But this would require significant changes to the core source
code!  We'd never be able to find enough sacrificial penguins to appease
the gods!
- Anyone who likes this idea is either stupid or not a 'true' PHP
developer.
- If you disagree with me, it means you haven't done your homework
because I'm always right.
- Strict typing would break everything!  What?  You're not talking
about C-like strict typing?  Sorry, I didn't catch that.  Strict typing
would break everything!
- I don't care if you've already countered my argument.  I'll just
keep repeating myself as if you didn't.


 Variations of the above statements have been posted ad nauseum.  They're
 all based on logical fallacies and are not constructive.

 I'm putting this out there:  If anyone posts one or more of the above
 arguments yet again on this topic, I will personally extract one of your
 kidneys and sell it to a questionable dog food company in Shanghai.  I
 will then openly mock your intellectual laziness and encourage people to
 ignore you.  ;P


 I'd love to prove Daniel wrong, but I think he may be on to something
 :\


it is weird that you are calling others rude.
I'm sure you would feel hurt/personally attacked, if somebody would create
a similar list of the little bit twisted arguments of yours.
could we stay on the topic?
another 14 mails to read. :/

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Scalar type hinting

Lol be my guest.  You won't have much success though because I have not
relied upon hyperbole and logical fallacies to substantiate my arguments.
On the contrary, my argument thus far can be summarized thusly:


   - The issue of type hinting isn't going to go away, otherwise it would
   have by now.
   - This feature, if implemented correctly, won't break PHP or
   compromise backwards compatibility.
   - I will push back against any efforts to silence this discussion as has
   been done in the past.
   - If you can't disagree with someone without accusing them of being
   ill-informed, disloyal, or just plain dumb; then you're not contributing
   anything constructive to this discussion.


There, I just saved you the trouble.  =)

--Kris


On Mon, Feb 27, 2012 at 1:13 PM, Ferenc Kovacs tyr...@gmail.com wrote:



 On Mon, Feb 27, 2012 at 7:53 PM, Kris Craig kris.cr...@gmail.com wrote:

 +1 what Anthony said.

 Guys, seriously.  Some of these responses have been downright rude and
 inappropriate for a constructive dialogue.  Please do not pollute this
 thread with cliche, Just find another language and get out! posts.  It
 doesn't add anything to the conversation and instead just creates needless
 anger and animosity.  It's immature and just makes it look like we're
 incapable of having a rational discussion.

 So, let me outline a list of arguments that will carry ZERO weight on
 this thread:

- If you don't like PHP as it is, goto Java (or some other
language)!
- We've already talked about this before.  Therefore, we must never
speak of it again.
- This is impossible.  Why?  Because I said so.  You want evidence?
Fuck you.
- But this would require significant changes to the core source
code!  We'd never be able to find enough sacrificial penguins to appease
the gods!
- Anyone who likes this idea is either stupid or not a 'true' PHP
developer.
- If you disagree with me, it means you haven't done your homework
because I'm always right.
- Strict typing would break everything!  What?  You're not talking
about C-like strict typing?  Sorry, I didn't catch that.  Strict typing
would break everything!
- I don't care if you've already countered my argument.  I'll just
keep repeating myself as if you didn't.


 Variations of the above statements have been posted ad nauseum.  They're
 all based on logical fallacies and are not constructive.

 I'm putting this out there:  If anyone posts one or more of the above
 arguments yet again on this topic, I will personally extract one of your
 kidneys and sell it to a questionable dog food company in Shanghai.  I
 will then openly mock your intellectual laziness and encourage people to
 ignore you.  ;P


 I'd love to prove Daniel wrong, but I think he may be on to
 something  :\


 it is weird that you are calling others rude.
 I'm sure you would feel hurt/personally attacked, if somebody would create
 a similar list of the little bit twisted arguments of yours.
 could we stay on the topic?
 another 14 mails to read. :/

 --
 Ferenc Kovács
 @Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Scalar type hinting

On Mon, Feb 27, 2012 at 8:15 PM, Kris Craig kris.cr...@gmail.com wrote:

 Now, to rewind a bit past the latest chunk of I hate this idea posts

 I'd like to suggest a new term:  strong.


I think it would be better if we could not introduce terms for new
definition if that term is already used in the vocabulary for type systems:
http://en.wikipedia.org/wiki/Strong_typing



 This term would be similar to weak, except with a few key differences:

- Weak would behave very much like Arvids suggested in his earlier
post; i.e. if the variable is an integer but you pass a string (like aaa)
to it, a warning would be thrown and PHP would attempt to convert it (i.e.
it would become 1).

 why would aaa turn to 1? it would be 0 by the php type juggling rules.



- Strong, on the other hand, would throw a fatal error if you
attempted to pass an incompatible value to an array.  Or, to put it another
way, if the converted value does not match the original value.  For
example, if we're assigning aaa to an integer, that would convert to 1;
and, since 1 != aaa, a fatal error would be thrown.  On the other hand,
if you were to pass the string 1 to that integer variable, it would
convert to 1; and, since 1 == 1, there wouldn't be a problem.

 same error here, it seems that it isn't the typo. putting that aside: so
you say that the type checking would behave the same was as does currently
the == and === operator.


- In both instances, if the converted value matches the original (i.e.
1 == 1), no warning error would be displayed.  Should it perhaps display
a notice though?  Or no error at all?  I can think of reasonable arguments
on both sides of that question.


I remember seeing that suggestion before, I think that it was proposed more
than once, see
http://marc.info/?l=php-internalsm=128159992610321w=3
did you read that thread?

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC] APXS LoadModule Option in configure

2012-02-27 Thread Lester Caine


Kris Craig wrote:

@Lester Generally, this is a problem that surfaces in manual PHP builds.
You're correct in that the packaged repos tend to handle all that stuff for
you anyway.  However, these repos are rarely updated (I think CentOS and
Ubuntu are both still stuck on 5.1), so it's often necessary to build PHP
manually if you want to take advantage of the latest features.  In these
cases, being able to isolate the PHP configuration tends to make the most
sense, hence why this new option switch is necessary IMHO.


I've obviously been doing something wrong then :)
SUSE has been keeping my versions up to date quite happily even to the extent 
that I now have to make sure I DON'T get an update applied until I've had a 
chance to check the live sites!
But I still have to manually build the more useful extensions that are not 
included, and it's at this time that the build 'defaults' tends to screw with 
the SUSE configuration :(


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

Yeah again sorry about the 1.  Another dyslexic moment on this end lol.

I don't care about the specific terminology we use, just so long as it
makes sense and people aren't confusing it with something else.  I
differentiated between strong and weak in order to accommodate the looser
functionality that Arvids had suggested.  I'm fine with just going with the
stronger approach and calling that weak if that's what everyone wants.

--Kris


On Mon, Feb 27, 2012 at 1:24 PM, Ferenc Kovacs tyr...@gmail.com wrote:



 On Mon, Feb 27, 2012 at 8:15 PM, Kris Craig kris.cr...@gmail.com wrote:

 Now, to rewind a bit past the latest chunk of I hate this idea posts

 I'd like to suggest a new term:  strong.


 I think it would be better if we could not introduce terms for new
 definition if that term is already used in the vocabulary for type systems:
 http://en.wikipedia.org/wiki/Strong_typing



 This term would be similar to weak, except with a few key differences:

- Weak would behave very much like Arvids suggested in his earlier
post; i.e. if the variable is an integer but you pass a string (like 
 aaa)
to it, a warning would be thrown and PHP would attempt to convert it (i.e.
it would become 1).

 why would aaa turn to 1? it would be 0 by the php type juggling rules.



- Strong, on the other hand, would throw a fatal error if you
attempted to pass an incompatible value to an array.  Or, to put it 
 another
way, if the converted value does not match the original value.  For
example, if we're assigning aaa to an integer, that would convert to 1;
and, since 1 != aaa, a fatal error would be thrown.  On the other 
 hand,
if you were to pass the string 1 to that integer variable, it would
convert to 1; and, since 1 == 1, there wouldn't be a problem.

 same error here, it seems that it isn't the typo. putting that aside: so
 you say that the type checking would behave the same was as does currently
 the == and === operator.


- In both instances, if the converted value matches the original
(i.e. 1 == 1), no warning error would be displayed.  Should it perhaps
display a notice though?  Or no error at all?  I can think of reasonable
arguments on both sides of that question.


 I remember seeing that suggestion before, I think that it was proposed
 more than once, see
 http://marc.info/?l=php-internalsm=128159992610321w=3
 did you read that thread?

 --
 Ferenc Kovács
 @Tyr43l - http://tyrael.hu

Re: [PHP-DEV] bugs.php.net php 6

2012-02-27 Thread Lester Caine


John Crenshaw wrote:

Wait, is the default going to be Unicode (wide, always 2 bytes per char, I.E. more 
memory consumption) or UTF-8 (1 byte for the first 127, more bytes for wider text, 
mostly unchanged memory consumption)? I thought it was originally a conversion to Unicode, but that 
was scrapped? Can someone clarify?


I seem to recall that the original plan was along the lines of windows wide 
string? But it was the fact that unicode is wider then 16 bit that this was 
simply wrong? Trying to shoehorn things into the wrong structure was just not 
working and making the job more difficult?


Keeping things simple really requires 4 bytes per character, even if one of 
those is never used, but it does make sense when manipulating strings? However 
most of the time UTF8 works happily and only becomes a problem when a multibyte 
character gets cropped because the processing does not know about it?


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

Ferenc,

Thanks for the comments!

On Mon, Feb 27, 2012 at 4:09 PM, Ferenc Kovacs tyr...@gmail.com wrote:

On Mon, Feb 27, 2012 at 6:38 PM, Anthony Ferrara ircmax...@gmail.com
wrote:

no, it is: come back after you did your homework, and you can provide
new
arguments to the discussion

Without committing to anything, I will try to find time to do so...

Discussed to death. Yet only one time before (discussing a specific
patch)...

I only joined the lists like 3 years ago, but I remember discussing this
idea more than that.
I can dig up the threads if you are interested, the biggest discussion was
after Derick commited the scalar typehint patch from Ilia to trunk and after
a pretty heated and long discussion and multiple alternative proposals the
patch was reverted and Derick implemented a Reflection based infrastructure
for checking the typehints.

Well, that's absolutely relevant, but that was for one of the
possibilities on how to implement it. But worth bringing up...

That's quite helpful.

And the opponents still said no...

I have no problem with the maintainers/core devs saying no if they
really feel it's bad (in fact, I agree with it). What I do have a
problem with is them (or anyone) saying no without understanding what
they are saying no to (which is obvious by some of the comments, and
by some of the banter about PHP is not java).

There were also quite a few problems identified with scalar hinting
and auto-casting vs strict erroring. However, there were also
solutions proposed to nearly each and every one of them.

There were ideas, but they didn't have enough traction.
IMO we can't have a proper solution without changing the existing behavior
for complex types, if you implement strict typing for scalars that turns the
language strict typed, if you add dynamic/weak typing for the scalars, you
will have an inconsistent implementation.

What behavior would need to be changed for complex types? Adding the
ability to hint/cast between trees? I'm kind of confused by this
bit...

And the opponents still said no...

to tell the truth they said no, but it was the original commiter who
reverted the change.
(sorry Derick, I don't remember the details, feel free to correct me on
this.)

Sure, but again, that's talking about implementing very strict typing
(fatal on incorrect). Which to be perfectly honest, I would say no to
as well. But I think there's enough merit to continue the discussion,
and separate the concepts... But very fair point...

It has been brought up time and time again. Solutions have been
proposed which have no fundimental issues (inconsistencies,
problematic operations - such as references, etc)...

maybe I missed those, what are you referring to?
I see the ones that I linked + the following:
https://wiki.php.net/rfc/typechecking

https://wiki.php.net/rfc/autoboxing
https://wiki.php.net/rfc/boxingandunboxing

Re: [PHP-DEV] bugs.php.net php 6

On Mon, Feb 27, 2012 at 5:10 PM, Richard Lynch c...@l-i-e.com wrote:

On Mon, February 27, 2012 9:37 am, Simon Schick wrote:
The development of the unicode-as-default-charset should really be
done
within the next release coming after 5.4
I heared somewhere that it's nearly done ...
I would have happily seen it in 5.4 but as this release is late right
now
we have to wait ;)

I was off on medical leave for awhile, but last I heard, the one (1)
guy who cared enough to work hard-core on a Unicode PHP realized just
how terribly difficult it was, and just how many irreconcilable issues
it raised, and he stopped working on it.

Nobody else has taken up the banner, and PHP 6 trunk was moth-balled
and started over, or so I heard...

That sums up, even over-simplifies, a whole mess of threads,
discussions at conferences, and IRC discussion in a couple
sentences... I apologize to all for the over-simplification, and
possibly outright errors.

While I understand the allure of writing code in one's native
language, and the ease of having one's native language supported out
of the box in the string built-in type...

There are mechanisms available in PHP now, which are more cumbersome,
but they work without the very complex issues alluded to in paragraph
1..

Other languages may have this feature, but they were included from the
beginning. Grafting them on to PHP at this point was attempted, and,
as far as I know, failed. It was an ambitious attempt, and the issues
could not have easily been foreseen, so it's probably very
disheartening to have failed just short of the goal line.

That's the way the ball bounces sometimes.

Again, please forgive me if I have completely failed to catch
something here, especially as I'm just getting back into the flow of
things.

some more info
http://lwn.net/Articles/379909/
http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6
so yeah, the full unicode support happened to be too big to undertake (and
in retrospective it seems that the UTF-8 would have been a wiser choice
instead of UTF-16), and having to upgrade all of the extensions was also a
grand task.

so the unicode development got halted, which in turn made the whole php6
project into a death march.
after some marching 5.3 got branched from 5.2, the stuff ready in php 6 got
backported and released, then people realized that it is nowhere else to
go, moved trunk to branches/FIRST_UNICODE_IMPLEMENTATION/, and rebranched
trunk from 5.3, which in turn get turned into 5.4.

ps: and it was a big messy discussion about the namespace operator.
ps2: feel free to correct/extend my info. ^^

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC] APXS LoadModule Option in configure



 @Lester Generally, this is a problem that surfaces in manual PHP builds.
 You're correct in that the packaged repos tend to handle all that stuff for
 you anyway.  However, these repos are rarely updated (I think CentOS and
 Ubuntu are both still stuck on 5.1), so it's often necessary to build PHP
 manually if you want to take advantage of the latest features.  In these
 cases, being able to isolate the PHP configuration tends to make the most
 sense, hence why this new option switch is necessary IMHO.


AFAIR centos 5.7 provides php 5.2.1
(centos 4 has only Maintenance updates, for 2 more days)
the oldest ubuntu (8,04 lts) also have 5.2.4
so I think that the only distro with support that ships =5.2 is rhel 4
with the Extended life cycle.
but usually there are semi-official/community repos providing more
up-to-date versions for each distribution.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC] APXS LoadModule Option in configure

I've got a CentOS 5.7 VM running at work and the PHP package returned by
yum is 5.1.6.  Don't have my Ubuntu box with me at the moment but I'm
pretty sure it's 5.1.x as well.

You probably have rpmforge or CentALT enabled and that's where it's pulling
the newer build.  But even then, the latest one you'll get is 5.2.17.  I'm
not aware of any widely available repos that have 5.3.x.

--Kris


On Mon, Feb 27, 2012 at 2:11 PM, Ferenc Kovacs tyr...@gmail.com wrote:


 @Lester Generally, this is a problem that surfaces in manual PHP builds.
 You're correct in that the packaged repos tend to handle all that stuff
 for
 you anyway.  However, these repos are rarely updated (I think CentOS and
 Ubuntu are both still stuck on 5.1), so it's often necessary to build PHP
 manually if you want to take advantage of the latest features.  In these
 cases, being able to isolate the PHP configuration tends to make the most
 sense, hence why this new option switch is necessary IMHO.


 AFAIR centos 5.7 provides php 5.2.1
 (centos 4 has only Maintenance updates, for 2 more days)
 the oldest ubuntu (8,04 lts) also have 5.2.4
 so I think that the only distro with support that ships =5.2 is rhel 4
 with the Extended life cycle.
 but usually there are semi-official/community repos providing more
 up-to-date versions for each distribution.

 --
 Ferenc Kovács
 @Tyr43l - http://tyrael.hu

RE: [PHP-DEV] Scalar type hinting

 -Original Message-
 From: Kris Craig [mailto:kris.cr...@gmail.com] 
 
 Now, to rewind a bit past the latest chunk of I hate this idea posts
 
 I'd like to suggest a new term:  strong.
 
 This term would be similar to weak, except with a few key differences:

 ...

 Some possible examples of how this would look:
 
 weak int $i = aaa;  // Converts to 1 and throws a warning.
 strong int $ii = aaa; // Throws a fatal error.
 weak int $i = 1; // Converts to 1.
 strong int $ii = 1; // Converts to 1.
 

 --Kris

Can we use a different word (not strong) at least for just discussion 
purposes? I worry that strong will produce a feeling of intense fear and 
anxiety in people who have been burned out by strict typing debates. The words 
strong and strict are basically inflammatory at this point. In the interest 
of facilitating a reasonable discussion, I think we should avoid language that 
is likely to cause discussion to break down.

John Crenshaw
Priacta, Inc.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Scalar type hinting

 -Original Message-
 From: John LeSueur [mailto:john.lesu...@gmail.com] 
 
 Maybe this discussion should start from the end of the last discussion on 
 non-strict type hints, where really smart people came up with some options to 
 handle the conversion:
 
 https://wiki.php.net/rfc/typecheckingstrictandweak#option_1_current_type_juggeling_rules_with_e_strict_on_data_loss
 
 The RFC talks about throwing E_STRICT or E_FATAL, and has a couple of options 
 for a matrix of conversion rules.

I've actually read that proposal. To some level it is good, but I felt like 
there were too many problems. E_ERROR is overkill. For comparison, (function 
(array $bar) {})('a') generates a catchable fatal error (E_RECOVERABLE_ERROR) 
so that's the furthest this should go in any case, but when dealing with 
jugglable types and there's just some unexpected data loss even 
E_RECOVERABLE_ERROR is too much IMO; E_WARNING or E_NOTICE would be more 
appropriate. IIRC it also failed conversions too aggressively.

John Crenshaw
Priacta, Inc.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Scalar type hinting

Inline

 -Original Message-
 From: Richard Lynch [mailto:c...@l-i-e.com] 
 
 On Mon, February 27, 2012 1:15 pm, Kris Craig wrote:
  Now, to rewind a bit past the latest chunk of I hate this idea
  posts
 
  I'd like to suggest a new term:  strong.
 
  This term would be similar to weak, except with a few key
  differences:
 
 - Weak would behave very much like Arvids suggested in his earlier 
  post;
 i.e. if the variable is an integer but you pass a string (like
  aaa) to
 it, a warning would be thrown and PHP would attempt to convert it 
  (i.e. it
 would become 1).
 
 Nitpick:
 Two backwards compatibility breaks:
 1) Throwing E_WARNING
 2) aaa converted to (int) is 0.

Sorry, I don't understand the BC break on the warning. Old code doesn't have 
this anyway, so what exactly would break? Shouldn't all existing scripts 
continue to work exactly the same as before unless they add a type check?

(I'm sure the example was just wrong, aaa should convert to 0)

  strong int $ii = aaa; // Throws a fatal error.
 
 Okay.
 
 E_FATAL seems drastic to me, but I'm not even going to use strong so don't 
 really care either way, I suppose.

I totally agree. E_RECOVERABLE_ERROR is the most severe that this should be 
(also matches the behavior of current type hints).

  weak int $i = 1; // Converts to 1.
 
 Again, old-school (int) or set_type covers this.

Unfortunately it doesn't completely. Yes, behavior is the same so long as the 
conversion is good, but a cast will silently accept impossible conversions, 
which is not what you really want here.

John Crenshaw
Priacta, Inc.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

Would firm work better?

--Kris


On Mon, Feb 27, 2012 at 2:27 PM, John Crenshaw johncrens...@priacta.comwrote:

  -Original Message-
  From: Kris Craig [mailto:kris.cr...@gmail.com]
 
  Now, to rewind a bit past the latest chunk of I hate this idea
 posts
 
  I'd like to suggest a new term:  strong.
 
  This term would be similar to weak, except with a few key differences:
 
  ...
 
  Some possible examples of how this would look:
 
  weak int $i = aaa;  // Converts to 1 and throws a warning.
  strong int $ii = aaa; // Throws a fatal error.
  weak int $i = 1; // Converts to 1.
  strong int $ii = 1; // Converts to 1.
 
 
  --Kris

 Can we use a different word (not strong) at least for just discussion
 purposes? I worry that strong will produce a feeling of intense fear and
 anxiety in people who have been burned out by strict typing debates. The
 words strong and strict are basically inflammatory at this point. In
 the interest of facilitating a reasonable discussion, I think we should
 avoid language that is likely to cause discussion to break down.

 John Crenshaw
 Priacta, Inc.

Re: [PHP-DEV] Scalar type hinting

I think this is the main reason for differentiating between strong (or
whatever word is appropriate) and weak.  The developer may very well want
their script to blow-up in such a case.

I would liken this to the fact that we have both an include statement and
a require statement.  One is recoverable, the other is not.  I think the
same principle applies here.

--Kris


On Mon, Feb 27, 2012 at 2:31 PM, John Crenshaw johncrens...@priacta.comwrote:

 Inline

  -Original Message-
  From: Richard Lynch [mailto:c...@l-i-e.com]
 
  On Mon, February 27, 2012 1:15 pm, Kris Craig wrote:
   Now, to rewind a bit past the latest chunk of I hate this idea
   posts
  
   I'd like to suggest a new term:  strong.
  
   This term would be similar to weak, except with a few key
   differences:
  
  - Weak would behave very much like Arvids suggested in his earlier
   post;
  i.e. if the variable is an integer but you pass a string (like
   aaa) to
  it, a warning would be thrown and PHP would attempt to convert it
   (i.e. it
  would become 1).
 
  Nitpick:
  Two backwards compatibility breaks:
  1) Throwing E_WARNING
  2) aaa converted to (int) is 0.

 Sorry, I don't understand the BC break on the warning. Old code doesn't
 have this anyway, so what exactly would break? Shouldn't all existing
 scripts continue to work exactly the same as before unless they add a type
 check?

 (I'm sure the example was just wrong, aaa should convert to 0)

   strong int $ii = aaa; // Throws a fatal error.
 
  Okay.
 
  E_FATAL seems drastic to me, but I'm not even going to use strong so
 don't really care either way, I suppose.

 I totally agree. E_RECOVERABLE_ERROR is the most severe that this should
 be (also matches the behavior of current type hints).

   weak int $i = 1; // Converts to 1.
 
  Again, old-school (int) or set_type covers this.

 Unfortunately it doesn't completely. Yes, behavior is the same so long as
 the conversion is good, but a cast will silently accept impossible
 conversions, which is not what you really want here.

 John Crenshaw
 Priacta, Inc.

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Scalar type hinting

 Would firm work better?
 
 --Kris

As a working name that would be fine. Of course, if this discussion moves to a 
sub-group that becomes less critical since it would be less likely for people 
to jump in the middle and misunderstand the terms.

John Crenshaw
Priacta, Inc.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

2012-02-27 Thread Larry Garfield


That's going to get turned into the real name if used.  I suggest instead:

Gribblefritz.

Gribble typing: the type handling that PHP does today in 5.3/5.4 for 
scalar values.


Fritz typing: Some as-yet-undefined type handling that is pickier than 
Gribble typing, but how much pickier is unclear.


That, at least, no one has any pre-conceived definition of.

--Larry Garfield

On 2/27/12 4:31 PM, Kris Craig wrote:

Would firm work better?

--Kris


On Mon, Feb 27, 2012 at 2:27 PM, John Crenshawjohncrens...@priacta.comwrote:


-Original Message-
From: Kris Craig [mailto:kris.cr...@gmail.com]

Now, to rewind a bit past the latest chunk of I hate this idea

posts


I'd like to suggest a new term:  strong.

This term would be similar to weak, except with a few key differences:

...

Some possible examples of how this would look:

weak int $i = aaa;  // Converts to 1 and throws a warning.
strong int $ii = aaa; // Throws a fatal error.
weak int $i = 1; // Converts to 1.
strong int $ii = 1; // Converts to 1.


--Kris


Can we use a different word (not strong) at least for just discussion
purposes? I worry that strong will produce a feeling of intense fear and
anxiety in people who have been burned out by strict typing debates. The
words strong and strict are basically inflammatory at this point. In
the interest of facilitating a reasonable discussion, I think we should
avoid language that is likely to cause discussion to break down.

John Crenshaw
Priacta, Inc.





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] APXS LoadModule Option in configure

On Mon, Feb 27, 2012 at 11:16 PM, Kris Craig kris.cr...@gmail.com wrote:

 I've got a CentOS 5.7 VM running at work and the PHP package returned by
 yum is 5.1.6.  Don't have my Ubuntu box with me at the moment but I'm
 pretty sure it's 5.1.x as well.

 You probably have rpmforge or CentALT enabled and that's where it's
 pulling the newer build.  But even then, the latest one you'll get is
 5.2.17.  I'm not aware of any widely available repos that have 5.3.x.

 --Kris


just checked, centos 5 provides php53 packages, see
http://mirror.centos.org/centos/5/os/i386/CentOS/ .
and here is the semi-official centos repo that I mentioned:
http://dev.centos.org/centos/5/testing/i386/RPMS/
oldest ubuntu (hardy) provides 5.2.4: http://packages.ubuntu.com/hardy/php5

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Scalar type hinting

On 27/02/12 20:05, Richard Lynch wrote:
 You are correct.

 I'd have to come up with some OTHER scenario not involving fatal
 error, such as:

 strict $db = new DB();

 and your database being down, unavailable, or connection parameters
 being wrong.

 The principle remains.

 You probably still want $db to be NULL in that situation, rather than
 an unusable DB object.

 Otherwise, you'll have to write a lot more sanity checking code
 elsewhere, which is what you are trying to avoid in the first place...

 Or, perhaps not.

 Perhaps you really do want this case to just plain bomb out with a
 failure that the $db is not strictly an object, with no recourse to
 try again, or deal with the error in application logic...
It could be throwing an exception.
You usually want it to be just what you want. In some cases you may
want to accept NULLs. You should provide a different qualifier in that
case, such as strict?

Yes, you may end up with things like

nullable strict DB $db = DB::factory();


which doesn't look like PHP at all. But I suppose that's what you wanted?



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting

No that's like a million times worse, Larry!!  Gaylord T. Gribblefritz III
was a serial killer who terrorized the midwest for over 40 years!  That
monster murdered me and my entire family!  He would sell milk laced with
sleeping pills to school children then take them back to his secluded
ranch, where wealthy businessmen would hunt them for sport.  The
International Criminal Court has accused him of committing the worst crimes
against humanity in the last 10,000 years and the Aryan Nations has run
television ads saying this man proves that Hitler really wasn't all that
bad, after all.  The Israelis and Palestinians issued a joint statement
condemning this man's violence.  The Dalai Lama has gone on record, saying,
Shit, even I think we should kill this fucking asshole!

Also, Mr. Gribblefritz (or Satan's Evil Twin as they call him in Utah)
recently wrote an op-ed arguing that PHP should be re-written in Fortran
and that its syntax should be changed to resemble QBASIC.


How DARE you insult this list by suggesting THE MOST INFLAMMATORY WORD OF
ALL TIME?!?!  You should be Gribblefritzed (you don't want to know) for
even suggesting something so horrible!  It's like, FIFTY TRILLION TIMES
WORSE than strong!

Other than that, though, I think it's a good idea.  ;P

--Kris



On Mon, Feb 27, 2012 at 2:41 PM, Larry Garfield la...@garfieldtech.comwrote:

 That's going to get turned into the real name if used.  I suggest
 instead:

 Gribblefritz.

 Gribble typing: the type handling that PHP does today in 5.3/5.4 for
 scalar values.

 Fritz typing: Some as-yet-undefined type handling that is pickier than
 Gribble typing, but how much pickier is unclear.

 That, at least, no one has any pre-conceived definition of.

 --Larry Garfield


 On 2/27/12 4:31 PM, Kris Craig wrote:

 Would firm work better?

 --Kris


 On Mon, Feb 27, 2012 at 2:27 PM, John 
 Crenshawjohncrenshaw@priacta.**comjohncrens...@priacta.com
 wrote:

  -Original Message-
 From: Kris Craig [mailto:kris.cr...@gmail.com]

 Now, to rewind a bit past the latest chunk of I hate this idea

 posts


 I'd like to suggest a new term:  strong.

 This term would be similar to weak, except with a few key differences:

 ...

 Some possible examples of how this would look:

 weak int $i = aaa;  // Converts to 1 and throws a warning.
 strong int $ii = aaa; // Throws a fatal error.
 weak int $i = 1; // Converts to 1.
 strong int $ii = 1; // Converts to 1.


 --Kris


 Can we use a different word (not strong) at least for just discussion
 purposes? I worry that strong will produce a feeling of intense fear
 and
 anxiety in people who have been burned out by strict typing debates. The
 words strong and strict are basically inflammatory at this point. In
 the interest of facilitating a reasonable discussion, I think we should
 avoid language that is likely to cause discussion to break down.

 John Crenshaw
 Priacta, Inc.



 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] APXS LoadModule Option in configure

Yes but you have to download those RPM's manually.  If you just use the
default repo (i.e. yum install php) as most sysadmins do, you're gonna
get something MUCH older than that.  Plus there are still occasions where a
manual build is preferable to using an RPM.

--Kris


On Mon, Feb 27, 2012 at 2:46 PM, Ferenc Kovacs tyr...@gmail.com wrote:



 On Mon, Feb 27, 2012 at 11:16 PM, Kris Craig kris.cr...@gmail.com wrote:

 I've got a CentOS 5.7 VM running at work and the PHP package returned by
 yum is 5.1.6.  Don't have my Ubuntu box with me at the moment but I'm
 pretty sure it's 5.1.x as well.

 You probably have rpmforge or CentALT enabled and that's where it's
 pulling the newer build.  But even then, the latest one you'll get is
 5.2.17.  I'm not aware of any widely available repos that have 5.3.x.

 --Kris


 just checked, centos 5 provides php53 packages, see
 http://mirror.centos.org/centos/5/os/i386/CentOS/ .
 and here is the semi-official centos repo that I mentioned:
 http://dev.centos.org/centos/5/testing/i386/RPMS/
 oldest ubuntu (hardy) provides 5.2.4:
 http://packages.ubuntu.com/hardy/php5

 --
 Ferenc Kovács
 @Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC] Enum proposal (yet another)

On 27/02/12 19:22, Richard Lynch wrote:
 I'm not so sure about that. In a well-written web application, you
 would
 typically convert them on the first layer, when receiving from the
 web.
 On next usages, your int variables are usually ints already.
 Afraid not.

 It turns out that PHP, on 32-bit hardware, converting large BIGINT
 using (int) $ID ends up as a negative number, and then when you pass
 it in to the database if a string query, you get a negative ID, not at
 all what was intended.

 (Been there, done that, got burned)

 At least, that's been my experience with some versions of PHP and some
 database drivers.

 So at least the database IDs have to remain as strings, if you are
 using BIGINT.

 You could, of course, only convert the values known to be in range of
 PHPs positive integers, and leave the others as strings.

 This is just a simple example of how the super strict typing simply
 doesn't work out too well in PHP.
That's a good example from experience.
Although if you want to keep ids as strings, you can simply keep them as a
string type.
I was thinking on input coming from a web browser, btw.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Scalar type hinting