RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
You might consider those scripts poor programming practice. We all do. But PHP is the language of the unwashed masses, and that was, and is, part of why it is hugely popular. Somebody who barely understands programming can pound away at the keyboard and write a bloody useful web application, breaking 10,000 Computer Science rules along the way. And in 20 minutes I can hack into that application 20 different ways. This isn't really PHP's fault...or is it? By deliberately catering to the lowest possible denominator is it possible that PHP itself contributes to the proliferation of wildly insecure web sites? I do understand the unwashed masses argument, and yet, the security geek in me sometimes questions how good this is. (Before someone flames me, I'm not really saying that we should scrap any foundational principles or tell basic users to go hang themselves. This is mostly philosophical musing.) John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
Secure code is not about the instrument, it's about how you write it. Insecure spagetti code can be written in any language.
RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
From: Richard Lynch [mailto:c...@l-i-e.com]
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.
[short version]
One man's fixing is another man's feature :-)
Old hands can now hit delete while I wax philosophical.
The operative word was silent. The actual behavior is fine, but the silence
is unexpected. For example, PHP happily accepts substr('foo', 'bar') with no
complaint at all. From a purely philosophical perspective I think almost
everyone would expect *at least* a strict notice.
On a practical level, we have a major barrier and we'll have to decide how to
handle it. As I see it we could do one of the following:
1. Discard consistency (!!)
2. Try to convince people to make these bizarre conversions not silent (BC
break)
3. Try to find a creative solution to be consistent without changing anything
about the conversion behavior. (I'm not seeing a way to do this one, unless we
redefine consistent.)
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 Intentions
Hi, Adam I just get the feeling that this is exactly what we're currently discovered in some other threads in this mailing-list. We're now getting more and more closer to what we really want and a good way to write it the PHP-way. Please try to get a rough overview over the last messages we wrote on the following threads: * [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting) * RE: [PHP-DEV] Scalar type hinting The second one is quite big ;) and sometimes the messages contain only religious stuff like This will never be, go away - but that's just because we're in discussion. Like the wind blows. But I think we'll get to list of rock-solid possible solutions here. I think we'll soon create a RFC for that and discuss it after we have it on one paper. I would kind-of like the idea to add the *scalar *type in addition just to avoid objects or arrays in there, but let's look how the discussion goes. Bye Simon 2012/3/1 Adam Jon Richardson adamj...@gmail.com First, phpunit is a fantastic tool! I'm thankful for your contributions to all of the PHP community (especially with the code coverage capabilities.) I speak to your 2 points inline below: On Wed, Feb 29, 2012 at 9:36 PM, Sebastian Bergmann sebast...@php.net wrote: On 02/29/2012 09:01 PM, Adam Jon Richardson wrote: However, the aliases would allow developers to better communicate intentions AND provide more information for IDE's and static analyses tools. 1) You are trying to solve a social problem through technology. That usually does not work. I believe technology can provide effective tools for social problems, although I won't go so far as to say that it usually does work. More importantly, I believe programming is riddled with social problems: Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do. D. Knuth 2) What you want to achieve is already possible through docblocks. The greater part of the proposal rests on the general scalar hint. That said, I still believe the aliases for the scalars hold value. Sure, the communicative aspect of the aliases can be achieved through use of docblocks. However, in cognitive psychology and human factors research, proximity of relevant information plays a role in perception and processing, and I would posit that code with the type intentions displayed closer to the actual body of the function would hold benefits (this would be very testable, though, and research could prove me wrong.) When available, the scalar aliases could then be used to help auto-generate the docblocks. I would appreciate the scalar hinting, along with the aliases I outlined very much in my code. I believe that this form of hinting stays true to the PHP principles outlined in Richard's PHP Philosophy thread (a great read), and I believe it helps developers who want to better enforce (scalar hinting) and communicate (scalar aliases) the intentions of their code. Thank you for the feedback, Adam
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
Hi, John
Just to add an idea to yours ..
Do you think it's a compatibility-break if we'd decide to send a E_NOTICE
or E_WARNING if we f.e. try to give a string to a method that just allows
integer for this argument?
No break at all, just a E_NOTICE or E_WARNING as the script can succeed
anyways.
Bye
Simon
2012/3/1 John Crenshaw johncrens...@priacta.com
From: Richard Lynch [mailto:c...@l-i-e.com]
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.
[short version]
One man's fixing is another man's feature :-)
Old hands can now hit delete while I wax philosophical.
The operative word was silent. The actual behavior is fine, but the
silence is unexpected. For example, PHP happily accepts substr('foo',
'bar') with no complaint at all. From a purely philosophical perspective I
think almost everyone would expect *at least* a strict notice.
On a practical level, we have a major barrier and we'll have to decide how
to handle it. As I see it we could do one of the following:
1. Discard consistency (!!)
2. Try to convince people to make these bizarre conversions not silent (BC
break)
3. Try to find a creative solution to be consistent without changing
anything about the conversion behavior. (I'm not seeing a way to do this
one, unless we redefine consistent.)
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 Intentions
On Wed, Feb 29, 2012 at 09:01:05PM -0500, Adam Jon Richardson wrote:
However, the lack of scalar hinting does limit the ability of a developer
to declare his/her intentions for function/method parameters. A non-hinted
parameter expecting a scalar could be sent an object or an array, breaking
the expectations (and much of the time, the functionality) of the code.
That is to say, there is a value in declaring what the parameter IS NOT,
too.
+1
*What if PHP added the hint scalar?* The example could be rewritten as:
function foo(scalar $arg){
// $arg is supposed to be a scalar and will be used as an int
}
The idea is that the failure to send a valid scalar argument to the
function would result in the same feedback that currently occurs when array
or object hints are not heeded. Now, the expectations for each
function/method parameter can be explicitly declared (or, at least, more
explicitly.)
And, *what if PHP added the following aliases for the hint scalar*:
- bool
- int
- float
- string
The function could then be rewritten as below:
function foo(int $arg){
// $arg is supposed to be a scalar and will be used as an int
}
A nice compromise for a heated issue. This would also open the way to more
complete checking (as has been discussed) at some time in the future.
It would provide a better alternative to some of the ghastly pseudo comment
conventions that are currently used as means of documentations.
Programming is about communication of intent, not just with the computer
(compiler) but also with programmers who subsequently read the code.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
#include std_disclaimer.h
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
From: Simon Schick [mailto:simonsimc...@googlemail.com] Hi, John Just to add an idea to yours .. Do you think it's a compatibility-break if we'd decide to send a E_NOTICE or E_WARNING if we f.e. try to give a string to a method that just allows integer for this argument? No break at all, just a E_NOTICE or E_WARNING as the script can succeed anyways. Bye Simon That's what I was calling inconsistent, specifically because (int)'foo' == 0 with no warning whatsoever, but int $a = 'foo' would be 0 with an error of some sort. Behavior with respect to when an error is raised is inconsistent. In both cases there is a very lossy conversion, why is there an error in one case and not the other? Inconsistent. On the other hand if you add an error in the legacy case now that's a BC break. One might argue that it should always have given a notice, but it didn't, so it's a change, and a BC break. Pick your poison. John Crenshaw Priacta, Inc.
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
If any of you are interested in such change in PHP, please get
together and write a complete RFC. As I do not see any kind of
progress but, as you stated, some philosophical discussions. That's
all good but after 2 weeks, it is time to move forward (or stop).
Cheers,
On Thu, Mar 1, 2012 at 4:02 AM, Richard Lynch c...@l-i-e.com wrote:
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.
[short version]
One man's fixing is another man's feature :-)
Old hands can now hit delete while I wax philosophical.
[long version]
PHP does the type juggling because HTTP data is all string. It's a
feature, because PHP's main purpose was to process HTTP input.
[Yes, I know you did not dispute this. It's just foreshadowing...]
Once one accepts the premise that automatic type-juggling is good,
the idea that (int) 123 abc turns into 123 may seem incredibly
wrong or right depending on how useful one has found it.
I have found it useful, and others have as well, to the point that we
don't consider it something to fix but a feature
Obviously, others disagree. And that's okay. We get that some
disagree, and even why some disagree. We've all coded in C, C++, C#,
Forth, Modula 2, Lisp, PL/1, and many more, collectively.
We choose PHP, at times, because it is the way it is, as broken as
it may seem to others. And they are legion. One only needs to review
blogs and mailing lists of fans of other strictly-typed languages to
see this.
But Breaking Compatibility with something so deeply ingrained in the
culture and language, which goes back consistently at least to PHP3,
and probably PHP/FI, is a non-starter.
There are probably literally millions of scripts that will break out
there. That's simply unacceptable, and I trust you understand why
that is so.
You might consider those scripts poor programming practice. We all do.
But PHP is the language of the unwashed masses, and that was, and is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody useful
web application, breaking 10,000 Computer Science rules along the way.
It's duct tape and bailing wire. And we love it for that.
If the app is useful enough, it might even get cleaned up. Or just
more duct tape and bailing wire is applied, more likely. :-)
Even at a major release, PHP has, by and large, strived to remain
Backwards Compatible, unless a VERY compelling reason was presented.
A vocal minority, or even a majority, of developers does not qualify.
That's pretty much why the Core Devs' veto power exists.
Some of the proposals and ideas lately have adhered to that concept of
not breaking Backwards Compatibility. Others have not, and those are
just non-starters.
But PHP core has always had the mantra Keep It Simple, Stupid
If one wants a complex language, PHP is simply not going to be it, and
virtually all of these proposals do not fit the KISS principle, at a
fundamental level of Any idiot can read halfway decent code and
puzzle out what it does in less than a day.
This is a Religious Issue, a personal preference, a philosophical
ideal, etc. Right or wrong, it is what it is, by choice, by the core
developers who have put years worth of effort into it.
Please don't read this as go away or a restatement of the arguments
that have been labeled as circular before. I am merely trying to
explain why PHP is the way it is, at a 10,000 foot level, and why so
many core devs are resistant to the changes being proposed.
I highly respect all the efforts and the alternative philosophical
differences, and even the guiding principles of Computer Science
driving them. PHP is just not the language for Computer Science types,
for the most part. It's for the masses.
Some CS types like it in certain situations, which is all to the good,
or it would be a total mess :-) We embrace its flaws and ugly hacks
because, like it or not, it works for what it's designed to do.
--
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
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
Kris Craig wrote: With all due respect, it's a logical fallacy to draw a direct comparison between these two simply because they both happen to be uphill battles. There is a direct comparison between the two. Both provide something that a large number of people did not or do not want anything to do with. Namespace was forced on us in much the same way you are currently trying to force this on us. Many people who were pursuaded that namespace was a good idea are now realising that it wasn't and was the thin end of wedge which this discussion is once again trying to force open. I have no objections to 'object orientated' as that is how I have always used PHP, but the BULK of the data I am handling is simply strings which 'magically' get converted to the format I need. I don't see any use for 'type hinting' in any form since I NEED to check if a string I get in has the right data in before I store it in a database field. I don't need to throw some random error which needs handling ... I just handle the errors in line as I process the data. My framework helps to ensure what I get in is right in the first place anyway, so even the in-line checks are probably redundant nowadays! -- 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] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
That's what I was calling inconsistent, specifically because (int)'foo' == 0 with no warning whatsoever, but int $a = 'foo' would be 0 with an error of some sort. Behavior with respect to when an error is raised is inconsistent. In both cases there is a very lossy conversion, why is there an error in one case and not the other? Inconsistent. +1 However, I would love to have int $a = 'foo' cast to 0 without any error. New functionality without breaking BC. Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/1 John Crenshaw johncrens...@priacta.com From: Simon Schick [mailto:simonsimc...@googlemail.com] Hi, John Just to add an idea to yours .. Do you think it's a compatibility-break if we'd decide to send a E_NOTICE or E_WARNING if we f.e. try to give a string to a method that just allows integer for this argument? No break at all, just a E_NOTICE or E_WARNING as the script can succeed anyways. Bye Simon That's what I was calling inconsistent, specifically because (int)'foo' == 0 with no warning whatsoever, but int $a = 'foo' would be 0 with an error of some sort. Behavior with respect to when an error is raised is inconsistent. In both cases there is a very lossy conversion, why is there an error in one case and not the other? Inconsistent. On the other hand if you add an error in the legacy case now that's a BC break. One might argue that it should always have given a notice, but it didn't, so it's a change, and a BC break. Pick your poison. John Crenshaw Priacta, Inc.
Re: [PHP-DEV] Scalar Type Intentions
hi Sebastian, On Thu, Mar 1, 2012 at 3:36 AM, Sebastian Bergmann sebast...@php.net wrote: usually does not work. 2) What you want to achieve is already possible through docblocks. I am not saying that I like the idea of scalar type arguments, but you keep saying that docblocks solve such issue. They are totally unrelated to what is discussed here, they are documentations. They have nothing to do with runtime information (The same concept applied to the annotations, if you remember it). However, following your logic, class type hinting was a mistake? Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Intentions
And, *what if PHP added the following aliases for the hint scalar*:
- bool
- int
- float
- string
If an object has a __toString method, does it qualify as a valid value to
be passed to a scalar argument? In my opinion, it should.
Your suggestion has a future compatibility problem. The introduction of new
type casting methods (like __toInt or like __castTo) is an open
possibility. In such a case, if those keywords are nothing but aliases for
scalar, then there will be no way to choose which type casting method
should be chosen.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/1 Adam Jon Richardson adamj...@gmail.com
PHP currently allows users to provide type hints for functions and methods,
although the type hints are currently limited to objects and arrays:
http://en.wikipedia.org/wiki/Type_system#Variable_levels_of_type_checking
Restricting the type hinting to arrays and objects makes sense, as PHP's
type juggling (similar in many ways to JavaScript's), a core feature of the
language, performs automatic conversions between scalars as determined by
context:
http://php.net/manual/en/language.types.type-juggling.php
However, the lack of scalar hinting does limit the ability of a developer
to declare his/her intentions for function/method parameters. A non-hinted
parameter expecting a scalar could be sent an object or an array, breaking
the expectations (and much of the time, the functionality) of the code.
That is to say, there is a value in declaring what the parameter IS NOT,
too.
For example, the function below could have an object or array passed as the
first argument, even though the expectation is a scalar:
function foo($arg){
// $arg is supposed to be a scalar and will be used as an int
}
*What if PHP added the hint scalar?* The example could be rewritten as:
function foo(scalar $arg){
// $arg is supposed to be a scalar and will be used as an int
}
The idea is that the failure to send a valid scalar argument to the
function would result in the same feedback that currently occurs when array
or object hints are not heeded. Now, the expectations for each
function/method parameter can be explicitly declared (or, at least, more
explicitly.)
And, *what if PHP added the following aliases for the hint scalar*:
- bool
- int
- float
- string
The function could then be rewritten as below:
function foo(int $arg){
// $arg is supposed to be a scalar and will be used as an int
}
Now, the aliases wouldn't buy any more precision in terms of PHP's parser
expectations. Your function/method parameters can only expect objects,
arrays, or scalars. However, the aliases would allow developers to better
communicate intentions AND provide more information for IDE's and static
analyses tools. And, again, the use of the scalar hint and its aliases
would preclude sending objects and arrays to functions expecting otherwise.
I realize this subject is heated, and people's patience has worn thin. I'm
just hoping to toss out this idea I've had for some time while all of the
concerns on both sides are still fresh in my head.
Thanks for reading :)
Adam
Re: [PHP-DEV] Scalar Type Intentions
On 03/01/2012 04:13 AM, Pierre Joye wrote: However, following your logic, class type hinting was a mistake? The Type Hinting we currently have for arrays, callables, classes, and interfaces is not a mistake. Why? Because the types in question are not affected by the type juggling. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Intentions
Pierre Joye wrote: On Thu, Mar 1, 2012 at 3:36 AM, Sebastian Bergmannsebast...@php.net wrote: usually does not work. 2) What you want to achieve is already possible through docblocks. I am not saying that I like the idea of scalar type arguments, but you keep saying that docblocks solve such issue. They are totally unrelated to what is discussed here, they are documentations. They have nothing to do with runtime information (The same concept applied to the annotations, if you remember it). But one of the reasons given for wanting this is as simple documentation? Does providing more checks at runtime actually add anything when in many cases we already need to check for valid input anyway. I can't help thinking that in many cases people proposing this are working on a basis that the variables they are passing are fully nailed down as to what is in them? When in practice we are not passing well typed variables around - until they have been checked. It would be interesting to establish just how many developers already use IDE's which provide all of this hinting and more important detailed error checking which does not rely on adding anything more to the runtime engine. I kill most of these problems before the scripts ever get run anyway ... -- 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 Intentions
On Thu, Mar 1, 2012 at 10:39 AM, Sebastian Bergmann sebast...@php.net wrote: On 03/01/2012 04:13 AM, Pierre Joye wrote: However, following your logic, class type hinting was a mistake? The Type Hinting we currently have for arrays, callables, classes, and interfaces is not a mistake. Why? Because the types in question are not affected by the type juggling. That's a different discussion, your second argument is simply plain wrong. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vulnerability by loading doctype-declaration of xml
Using DOM, this can be achieved with $domDocument-resolveExternals = false; before loading a document. Julien.P On Wed, Feb 29, 2012 at 9:52 PM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote: On Wed, 29 Feb 2012 19:30:15 +0100, Simon Schick simonsimc...@googlemail.com wrote: I just read this post about a vulnerability by loading doctype-declaration of an xml-string given in a request: http://www.idontplaydarts.com/**2011/02/scanning-the-internal-** network-using-simplexml/http://www.idontplaydarts.com/2011/02/scanning-the-internal-network-using-simplexml/ Would it be a good point to restrict which urls can be loaded in the doctype, or is the following line the only possibility to prevent it in a good way? libxml_disable_entity_loader(**true); In PHP 5.4, you can use libxml_set_external_entity_**loader() and define your own logic. I'm afraid it's not documented yet, but it receives a callback that takes two strings, a public id and system id and a context (an array with four keys). The callback should return a resource, a string from which a resource can be opened, or NULL. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Newbie: issues developing a new extension
On Wed, Feb 29, 2012 at 10:06 PM, Christian Ferrari cam...@yahoo.comwrote: Dear all, I'm asking your help because I'm not able to solve an issue probably related to some foolish mistake I have not yet discovered. I'm trying to develop an experimental extension to interface LIXA library (http:/lixa.sourceforge.net/). I have created the basic stuff (config.m4, lixa.c, php_lixa.h and so on). If I use this sequence from the ext/lixa directory: /opt/php/bin/phpize ./configure --help I can see the lixa extension is available: [...] Optional Packages: --with-PACKAGE[=ARG]use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) --with-libdir=NAME Look for libraries in .../NAME rather than .../lib --with-php-config=PATH Path to php-config php-config --with-lixa=FILEInclude LIXA support. File is the path to lixa-config [...] and I can compile with: ./configure --with-lixa=/opt/lixa/bin/lixa-config --with-php-config=/opt/php/bin/php-config the build process runs as expected and the extension is available after an addition to php.ini (extension=[...]/ext/lixa/modules/lixa.so). Great, you are done. Why do you want to go any further than this? You built your extension and it is available from PHP exactly like any pecl extension. and if you're using apache, reboot it and check your phpinfo() page for your extension. if you're connected up via the command line you can run php -m to see if your modules exists. -Rasmus Dear all, I would like to see my extension as any other extension, like MySQL, PostgreSQL, Oracle and so on because: 1. LIXA itself is useless without those resource managers 2. I need to patch other extensions to implement the interfaces between LIXA and MySQL/PostgreSQL/Oracle. What's the difference between an internal extension (like MySQL/PostgreSQL/Oracle) and an external extension as the one I produced? Thanks in advance, your help is precious. The PHP source archive bundles several extensions under the ext/ directory, these are the extensions are listed when you run ./configure --help I don't understand why you want your extension to show up there, but to do so you have to place your extension in that folder and run ./buildconf --force PHP will not automatically scan your filesystem for possible extension directories to list them under ./configure I'm sure you have seen, and used, http://pecl.php.net - these extensions don't show up when you build PHP. The standard way to build external extensions however is to use pecl, or manually build them as shared modules (as you did first). -Hannes That's the point: I tryed ./buildconf --force but it didn't include my extension. This is an excerpt from my initial post: If I use this sequence from the PHP root directory: ./buildconf --force as described here: talks.somabo.de/200510_zend_conf_php_extension_development.pdf I cannot see lixa as an available option of my configure: ./configure --help|grep lixa is empty. If I try to build PHP anyway, I obtain: tiian@mojan:~/src/swig/php5.4-201202241630$ ./configure --with-lixa=/opt/lixa/bin/lixa-config configure: WARNING: unrecognized options: --with-lixa Do you have any idea how to debug why buildconf --force does not pick-up my extension? You should rm -f configure manually before invoking buildconf --force. It wont overwrite configure by itself. Julien.P Dear Julien, your suggestion is precious but unfortunately some more files must be deleted. After a bit of hacking I've found out this working sequence: tiian@mojan:~/php5.4-201202241630$ rm configure autom4te.cache/* Yes I forgot about those, but your are right :) Autotools are little complicated when you want to dive into them. One may read http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_libtool or paper http://shop.oreilly.com/product/9781593272067.do for deeper help and understanding :) Julien.P tiian@mojan:~/php5.4-201202241630$ ./buildconf --force Forcing buildconf rebuilding configure rebuilding main/php_config.h.in tiian@mojan:~/php5.4-201202241630$ ./configure --help|grep lixa --with-lixa=FILEInclude LIXA support. File is the
Re: [PHP-DEV] [Draft RFC] Object Casting and Assignment Handlers
On Thu, Mar 1, 2012 at 1:45 AM, Clint M Priest cpri...@zerocue.com wrote:
As much as I would love to have __castTo() and __assign() I have to agree
with Stas here that it fundamentally changes the mechanics of if($object)
and unfortunately turns that simple if statement into a possible hour long
hunt to find the code that is doing the damage, if it is even considered a
possibility by someone reading the code.
For the record, I really have only ever needed something like __toArray()
so that objects implementing ArrayAccess could be passed to array internal
functions.
In my own advice, this is far more important than every other thing, really.
That could require adding __toArray() to ArrayAccess, which would BC break,
but that has to be discussed. Why not another RFC about that ?
Also, one should keep the past decisions in his head, thus a refreshing
about ArrayAccess and current status could be good.
Please, see
http://devzone.zend.com/1124/zend-weekly-summaries-issue-361/#Heading3
http://devzone.zend.com/284/zend-weekly-summaries-issue-211/#Heading5 for
example.
My thoughts
Julien.P
I am interested in object natives though, which this is leading in the
direction of.
-Clint
-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Wednesday, February 29, 2012 1:48 AM
To: Anthony Ferrara
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [Draft RFC] Object Casting and Assignment Handlers
Hi!
Hey all,
I've created a draft version of the RFC for implementing __castTo()
and __assign():
https://wiki.php.net/rfc/object_cast_magic
I think having cast method may have merits, though use cases where objects
need to be converted to scalars that aren't string are very limited, and
cases where they need to do so transparently are almost non-existent. I
think what outlined in the RFC is a backdoor operator overloading, through
rather complex and unobvious magic. My opinion is that outside of very
limited number of cases (such as implementing complex numbers or matrix
algebra - and how frequently would one need do that in PHP anyway?)
operator overloading is way more trouble than it's worth and makes code
nearly unreadable as you never know what exactly each operator does. For
example, if($object) would have completely different semantics than before,
for some objects but not other, and without any obvious clue to the user
what it actually does - and all that to save couple of keystrokes on
if($object-valid())?
Still, if there's a valid use case found, cast magic method and unboxing
method may have merit. So far the cases outlined seem either too artificial
and narrow for language-level functionality, or plain wrong (like
SplFixedArray example - nothing in this proposal would enable it to work
with sort, for example). But I do not exclude other cases can exist.
However, assignment overloading does not seem viable to me.
Also, I'm not sure how this is possible technically: $obj = {expression}
is supposed to replace $obj with the result of the expression, not call
methods on $obj. Doing otherwise would be huge change in the semantics, a
complete no go. Also, it's impossible if $obj is not set - meaning, code
$obj = 1 would mean totally different things depending on if $obj is set or
not - again, not a good idea. It also does not cover many corner cases but
I don't even want to go there since an idea to change semantics of the
assignment seems very wrong to me in principle, so no need to go into the
fine details.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
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] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
On Thu, Mar 1, 2012 at 9:52 AM, Simon Schick simonsimc...@googlemail.comwrote:
Hi, John
Just to add an idea to yours ..
Do you think it's a compatibility-break if we'd decide to send a E_NOTICE
or E_WARNING if we f.e. try to give a string to a method that just allows
integer for this argument?
No break at all, just a E_NOTICE or E_WARNING as the script can succeed
anyways.
Perhaps I missed something, but since 5.3, the new parameter parsing API
throws a Warning when types are not strictly honored.
This has been a major feature in favor of cleaner programming.
Try substr('foo', 'bar'), in PHP = 5.3 and you get a warning and the
function returns null.
Julien.P
Bye
Simon
2012/3/1 John Crenshaw johncrens...@priacta.com
From: Richard Lynch [mailto:c...@l-i-e.com]
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.
[short version]
One man's fixing is another man's feature :-)
Old hands can now hit delete while I wax philosophical.
The operative word was silent. The actual behavior is fine, but the
silence is unexpected. For example, PHP happily accepts substr('foo',
'bar') with no complaint at all. From a purely philosophical perspective
I
think almost everyone would expect *at least* a strict notice.
On a practical level, we have a major barrier and we'll have to decide
how
to handle it. As I see it we could do one of the following:
1. Discard consistency (!!)
2. Try to convince people to make these bizarre conversions not silent
(BC
break)
3. Try to find a creative solution to be consistent without changing
anything about the conversion behavior. (I'm not seeing a way to do this
one, unless we redefine consistent.)
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
On Thu, Mar 1, 2012 at 9:00 AM, Lester Caine les...@lsces.co.uk wrote: Both provide something that a large number of people did not or do not want anything to do with. I disagree - The majority of PHP developers I've discussed this with are in favor of adding *something *like this. Do a majority want this? I have no idea and, I honestly don't believe you do either. Namespace was forced on us in much the same way you are currently trying to force this on us. Forced? Nobody is forcing anything. Discussions are happening, and possibly a vote in the future. This is the farthest thing from being forced IMO. Many people who were pursuaded that namespace was a good idea are now realising that it wasn't and was the thin end of wedge which this discussion is once again trying to force open. Many of the popular frameworks have made the changes, or are planning to make the changes, needed to take advantage of namespaces. This, to me, suggests a general acceptable of namespaces. Also - I'm yet to hear a single complaint about namespaces - although again, I've not talked to every PHP developer! (Well.. No complaints other than the namespace separator being a '\' that is) I have no objections to 'object orientated' as that is how I have always used PHP, but the BULK of the data I am handling is simply strings which 'magically' get converted to the format I need. I don't see any use for 'type hinting' in any form since I NEED to check if a string I get in has the right data in before I store it in a database field. I don't need to throw some random error which needs handling ... I just handle the errors in line as I process the data. My framework helps to ensure what I get in is right in the first place anyway, so even the in-line checks are probably redundant nowadays! I can certainly agree with you here - have I ever absolutely NEEDED this? Nope. Would it get it the way of writing code in certain situations? Yup. But - Does that mean it's not generally useful? Nope! Kiall
Re: [PHP-DEV] Scalar Type Intentions
On Thu, Mar 1, 2012 at 4:36 AM, Lazare Inepologlou linep...@gmail.comwrote:
And, *what if PHP added the following aliases for the hint scalar*:
- bool
- int
- float
- string
If an object has a __toString method, does it qualify as a valid value to
be passed to a scalar argument? In my opinion, it should.
Your suggestion has a future compatibility problem. The introduction of
new type casting methods (like __toInt or like __castTo) is an open
possibility. In such a case, if those keywords are nothing but aliases for
scalar, then there will be no way to choose which type casting method
should be chosen.
Lazare INEPOLOGLOU
Ingénieur Logiciel
You raise interesting points, Lazare, but I don't believe the compatibility
issues you're concerned about are valid.
Failing fast, similar to the Poka-Yoke principal in manufacturing, suggests
that system failure should occur as soon as possible to reduce software
bugs:
http://www.martinfowler.com/ieeeSoftware/failFast.pdf
Consider the following example:
// example class that does not implement __toString()
class test{
}
function foo($arg1, $arg2, $arg3){
if ($arg1) {
return The answer is: . $arg1;
}
if ($arg2) {
return The answer is: . $arg2;
}
if ($arg3) {
return The answer is: . $arg3;
}
}
$test = new test();
echo foo($arg1 = string, $arg2 = 100, $arg3 = $test); // echos The answer
is: string
echo foo($arg1 = false, $arg2 = 100, $arg3 = $test); // echos The answer
is: 100
echo foo($arg1 = false, $arg2 = false, $arg3 = $test); // catchable fatal
error
A developer using this function would only see this issue some of the time,
as this code fails late WITHIN some branches of the function, and the bug
is harder to identify.
We can do better, though. If the scalar type hint were applied, users would
merely have to cast the object to a string ON ENTRY to the function (and,
of note, this would work for your __toInt and __castTo concerns):
echo foo($arg1 = string, $arg2 = 100, $arg3 = (string)$test);
// catchable fatal error
Because the cast is performed on entry to the call, the bug shows up
immediately. I would argue that this code is clean (the cast to string in
the foo() call is a small amount of noise/keystrokes), visibly conformant
to the intentions of the foo() function, and more likely to catch bugs
early on in the process.
Adam
Re: [PHP-DEV] Scalar Type Intentions
Yes, I agree, the casting (or the failing to cast) has to happen on entry,
for the reasons that you have very well explained.
However, I cannot understand what it means to cast an object to a scalar.
Does it always mean casting to string? Wouldn't that be slow in many cases?
Simple example:
class A {
public $value = 1234;
public function __toString(){ return (string)$this-value; }
}
function foo( int $x ) { // here int is used as an alias to scalar as
you suggest
return $x + 1;
}
$a = new A;
foo( $a ); // casting $a to scalar upon calling, as it is possible after
all
In this example, the integer value will have to be cast to a string only to
be cast back to integer (unless something else happens under the hoods that
I am not aware).
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/1 Adam Jon Richardson adamj...@gmail.com
On Thu, Mar 1, 2012 at 4:36 AM, Lazare Inepologlou linep...@gmail.comwrote:
And, *what if PHP added the following aliases for the hint scalar*:
- bool
- int
- float
- string
If an object has a __toString method, does it qualify as a valid value to
be passed to a scalar argument? In my opinion, it should.
Your suggestion has a future compatibility problem. The introduction of
new type casting methods (like __toInt or like __castTo) is an open
possibility. In such a case, if those keywords are nothing but aliases for
scalar, then there will be no way to choose which type casting method
should be chosen.
Lazare INEPOLOGLOU
Ingénieur Logiciel
You raise interesting points, Lazare, but I don't believe the
compatibility issues you're concerned about are valid.
Failing fast, similar to the Poka-Yoke principal in manufacturing,
suggests that system failure should occur as soon as possible to reduce
software bugs:
http://www.martinfowler.com/ieeeSoftware/failFast.pdf
Consider the following example:
// example class that does not implement __toString()
class test{
}
function foo($arg1, $arg2, $arg3){
if ($arg1) {
return The answer is: . $arg1;
}
if ($arg2) {
return The answer is: . $arg2;
}
if ($arg3) {
return The answer is: . $arg3;
}
}
$test = new test();
echo foo($arg1 = string, $arg2 = 100, $arg3 = $test); // echos The
answer is: string
echo foo($arg1 = false, $arg2 = 100, $arg3 = $test); // echos The answer
is: 100
echo foo($arg1 = false, $arg2 = false, $arg3 = $test); // catchable fatal
error
A developer using this function would only see this issue some of the
time, as this code fails late WITHIN some branches of the function, and the
bug is harder to identify.
We can do better, though. If the scalar type hint were applied, users
would merely have to cast the object to a string ON ENTRY to the function
(and, of note, this would work for your __toInt and __castTo concerns):
echo foo($arg1 = string, $arg2 = 100, $arg3 = (string)$test);
// catchable fatal error
Because the cast is performed on entry to the call, the bug shows up
immediately. I would argue that this code is clean (the cast to string in
the foo() call is a small amount of noise/keystrokes), visibly conformant
to the intentions of the foo() function, and more likely to catch bugs
early on in the process.
Adam
Re: [PHP-DEV] Scalar Type Intentions
Please do not implement int, float, etc as an alias to scalar. That's
going to cause nothing but trouble later on. It will instantly close
the door to any type of casting magic (due to BC concerns), be
completely non-obvious (I hinted for int, why is it a boolean?), and
cause nothing but confusion.
If you only want to add a scalar hint, I'm fine with that (for now),
but please only add the scalar hint, no aliases...
Anthony
On Thu, Mar 1, 2012 at 8:33 AM, Lazare Inepologlou linep...@gmail.com wrote:
Yes, I agree, the casting (or the failing to cast) has to happen on entry,
for the reasons that you have very well explained.
However, I cannot understand what it means to cast an object to a scalar.
Does it always mean casting to string? Wouldn't that be slow in many cases?
Simple example:
class A {
public $value = 1234;
public function __toString(){ return (string)$this-value; }
}
function foo( int $x ) { // here int is used as an alias to scalar as
you suggest
return $x + 1;
}
$a = new A;
foo( $a ); // casting $a to scalar upon calling, as it is possible after
all
In this example, the integer value will have to be cast to a string only to
be cast back to integer (unless something else happens under the hoods that
I am not aware).
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/1 Adam Jon Richardson adamj...@gmail.com
On Thu, Mar 1, 2012 at 4:36 AM, Lazare Inepologlou linep...@gmail.comwrote:
And, *what if PHP added the following aliases for the hint scalar*:
- bool
- int
- float
- string
If an object has a __toString method, does it qualify as a valid value to
be passed to a scalar argument? In my opinion, it should.
Your suggestion has a future compatibility problem. The introduction of
new type casting methods (like __toInt or like __castTo) is an open
possibility. In such a case, if those keywords are nothing but aliases for
scalar, then there will be no way to choose which type casting method
should be chosen.
Lazare INEPOLOGLOU
Ingénieur Logiciel
You raise interesting points, Lazare, but I don't believe the
compatibility issues you're concerned about are valid.
Failing fast, similar to the Poka-Yoke principal in manufacturing,
suggests that system failure should occur as soon as possible to reduce
software bugs:
http://www.martinfowler.com/ieeeSoftware/failFast.pdf
Consider the following example:
// example class that does not implement __toString()
class test{
}
function foo($arg1, $arg2, $arg3){
if ($arg1) {
return The answer is: . $arg1;
}
if ($arg2) {
return The answer is: . $arg2;
}
if ($arg3) {
return The answer is: . $arg3;
}
}
$test = new test();
echo foo($arg1 = string, $arg2 = 100, $arg3 = $test); // echos The
answer is: string
echo foo($arg1 = false, $arg2 = 100, $arg3 = $test); // echos The answer
is: 100
echo foo($arg1 = false, $arg2 = false, $arg3 = $test); // catchable fatal
error
A developer using this function would only see this issue some of the
time, as this code fails late WITHIN some branches of the function, and the
bug is harder to identify.
We can do better, though. If the scalar type hint were applied, users
would merely have to cast the object to a string ON ENTRY to the function
(and, of note, this would work for your __toInt and __castTo concerns):
echo foo($arg1 = string, $arg2 = 100, $arg3 = (string)$test);
// catchable fatal error
Because the cast is performed on entry to the call, the bug shows up
immediately. I would argue that this code is clean (the cast to string in
the foo() call is a small amount of noise/keystrokes), visibly conformant
to the intentions of the foo() function, and more likely to catch bugs
early on in the process.
Adam
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Intentions
On Thu, Mar 1, 2012 at 8:33 AM, Lazare Inepologlou linep...@gmail.comwrote:
Yes, I agree, the casting (or the failing to cast) has to happen on entry,
for the reasons that you have very well explained.
However, I cannot understand what it means to cast an object to a scalar.
Does it always mean casting to string? Wouldn't that be slow in many cases?
Simple example:
I'm not sure I understand, so if I mischaracterize your concerns, please
let me know.
Of note, the scalar type hinting I've outlined does not automatically
perform casts to any particular type of scalar. Rather, it would be the
programmer's responsibility to perform the cast (as I performed in my
example.) This way, only necessary, reasonable casts are performed, and
information loss can be avoided.
That said, in terms of performance, PHP's type juggling performs these
types of casts all the time, so I don't think I'd be concerned. Any time we
check for equality using ==, perform string concatenation with ints, etc.,
PHP's beautiful type juggling automatically performs these conversions for
us without any effort on our part. I've never seen where this is the source
of any performance issues in my profiling, but I must admit that I don't
know the internals well enough to preclude this from ever being an issue.
class A {
public $value = 1234;
public function __toString(){ return (string)$this-value; }
}
function foo( int $x ) { // here int is used as an alias to scalar as
you suggest
return $x + 1;
}
$a = new A;
foo( $a ); // casting $a to scalar upon calling, as it is possible after
all
In this example, the integer value will have to be cast to a string only
to be cast back to integer (unless something else happens under the hoods
that I am not aware).
Speaking to your example, it would throw a catchable fatal error because
the variable $a contains an object of type A and the function foo expects a
scalar. The object would first have to be cast to a scalar. However, as you
pointed out, currently objects can only implement the __toString() method
(i.e., there's no __toInt, etc.), so one can't directly cast an object to
an int.
This seems contrived, though, because in the case of your example, if a
function expects an integer, wouldn't you just call it with the appropriate
object property:
foo ($a-value); // works because the value property is a scalar (int)
Thanks for your commentary :)
Adam
Re: [PHP-DEV] Scalar Type Intentions
On Thu, Mar 1, 2012 at 8:55 AM, Anthony Ferrara ircmax...@gmail.com wrote: Please do not implement int, float, etc as an alias to scalar. That's going to cause nothing but trouble later on. It will instantly close the door to any type of casting magic (due to BC concerns), be completely non-obvious (I hinted for int, why is it a boolean?), and cause nothing but confusion. If you only want to add a scalar hint, I'm fine with that (for now), but please only add the scalar hint, no aliases... Anthony Anthony, can you provide an example so I can better understand your concerns? Thanks, Adam
Re: [PHP-DEV] Scalar Type Intentions
Adam,
Sure. Basically, if you alias the int hint to scalar:
function foo(int $i) {
}
The following are all valid values for $i:
$i = 1;
$i = 1.5;
$i = 1.9
$i = foo
$i = true
$i = fopen($file);
So, in the future, if we wanted to implement loss-less casting
(casting if possible without loosing information, but erroring
otherwise, so passing foo to (int $i) would generate an error.
This will change the meaning of the int type hint, so production code
using it will break. Therefore we wouldn't be able to add magic
casting because of BC breaks...
Whereas if you implemented just the scalar hint without the aliases,
it wouldn't be a problem at all to add them, since there would be no
BC break at all...
Anthony
On Thu, Mar 1, 2012 at 9:33 AM, Adam Jon Richardson adamj...@gmail.com wrote:
On Thu, Mar 1, 2012 at 8:55 AM, Anthony Ferrara ircmax...@gmail.com wrote:
Please do not implement int, float, etc as an alias to scalar. That's
going to cause nothing but trouble later on. It will instantly close
the door to any type of casting magic (due to BC concerns), be
completely non-obvious (I hinted for int, why is it a boolean?), and
cause nothing but confusion.
If you only want to add a scalar hint, I'm fine with that (for now),
but please only add the scalar hint, no aliases...
Anthony
Anthony, can you provide an example so I can better understand your
concerns?
Thanks,
Adam
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar Type Intentions
Of note, the scalar type hinting I've outlined does not automatically
perform casts...
Thank you for your answer. Maybe, this exact fact is what I don't like
about your suggestion. Please read the following RFC, where Lukas Smith and
Zeev Suraski explain very well why strict type checking without
auto-casting is a not a great idea. Of course it is just an RFC, but I find
it quite correct.
https://wiki.php.net/rfc/typecheckingstrictandweak
My concern is that if your suggestion is adopted (as it is, without
auto-casting) then an eventual introduction of auto-casting will be
impossible without breaking BC.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/1 Adam Jon Richardson adamj...@gmail.com
On Thu, Mar 1, 2012 at 8:33 AM, Lazare Inepologlou linep...@gmail.comwrote:
Yes, I agree, the casting (or the failing to cast) has to happen on
entry, for the reasons that you have very well explained.
However, I cannot understand what it means to cast an object to a scalar.
Does it always mean casting to string? Wouldn't that be slow in many cases?
Simple example:
I'm not sure I understand, so if I mischaracterize your concerns, please
let me know.
Of note, the scalar type hinting I've outlined does not automatically
perform casts to any particular type of scalar. Rather, it would be the
programmer's responsibility to perform the cast (as I performed in my
example.) This way, only necessary, reasonable casts are performed, and
information loss can be avoided.
That said, in terms of performance, PHP's type juggling performs these
types of casts all the time, so I don't think I'd be concerned. Any time we
check for equality using ==, perform string concatenation with ints, etc.,
PHP's beautiful type juggling automatically performs these conversions for
us without any effort on our part. I've never seen where this is the source
of any performance issues in my profiling, but I must admit that I don't
know the internals well enough to preclude this from ever being an issue.
class A {
public $value = 1234;
public function __toString(){ return (string)$this-value; }
}
function foo( int $x ) { // here int is used as an alias to scalar
as you suggest
return $x + 1;
}
$a = new A;
foo( $a ); // casting $a to scalar upon calling, as it is possible
after all
In this example, the integer value will have to be cast to a string only
to be cast back to integer (unless something else happens under the hoods
that I am not aware).
Speaking to your example, it would throw a catchable fatal error because
the variable $a contains an object of type A and the function foo expects a
scalar. The object would first have to be cast to a scalar. However, as you
pointed out, currently objects can only implement the __toString() method
(i.e., there's no __toInt, etc.), so one can't directly cast an object to
an int.
This seems contrived, though, because in the case of your example, if a
function expects an integer, wouldn't you just call it with the appropriate
object property:
foo ($a-value); // works because the value property is a scalar (int)
Thanks for your commentary :)
Adam
[PHP-DEV] question about Zend MM
Hello, I want to understand how Zend MM works, so i'm looking trought the sources and i see this: #define ZEND_MM_ALIGNMENT_MASK ~(ZEND_MM_ALIGNMENT-1) #define ZEND_MM_ALIGNED_SIZE(size)(((size) + ZEND_MM_ALIGNMENT - 1) ZEND_MM_ALIGNMENT_MASK) I understand that the first define will create something like 1000 ( it will clear last 3 bits) but what does the 2nd define? Before clearing the last 3 bytes why does it add ZEND_MM_ALIGNMENT- 1 to size? Thanks,
Re: [PHP-DEV] question about Zend MM
On Thu, 01 Mar 2012 17:22:23 +0100, Adi Mutu adi_mut...@yahoo.com wrote: I want to understand how Zend MM works, so i'm looking trought the sources and i see this: #define ZEND_MM_ALIGNMENT_MASK ~(ZEND_MM_ALIGNMENT-1) #define ZEND_MM_ALIGNED_SIZE(size) (((size) + ZEND_MM_ALIGNMENT - 1) ZEND_MM_ALIGNMENT_MASK) I understand that the first define will create something like 1000 ( it will clear last 3 bits) but what does the 2nd define? Before clearing the last 3 bytes why does it add ZEND_MM_ALIGNMENT- 1 to size? It basically just rounds to the next multiple of ZEND_MM_ALIGNMENT, assuming ZEND_MM_ALIGNMENT is a power of 2. ZEND_MM_ALIGNMENT is a power of 2, so it has 1 bit set. Subtracting 1 will zero that bit and and flip on all the other less significant bits. Then negating flips the bits so that now the bits less significant than the log2(ZEND_MM_ALIGNMENT)-th will be zero and the others will be one. ZEND_MM_ALIGNED_SIZE adds ZEND_MM_ALIGNMENT - 1 and applies the mask. The effect is that the result will be = size and it will be a multiple of ZEND_MM_ALIGNMENT (in particular the smallest multiple of ZEND_MM_ALIGNMENT that's = the argument) because the bits less significant than the log2(ZEND_MM_ALIGNMENT)-th will be zero. a n-1 is the same as a mod n with n being a power of 2. So if a ZEND_MM_ALIGNMENT - 1 == 0 then a mod ZEND_MM_ALIGNMENT == 0 and a is a multiple of ZEND_MM_ALIGNMENT. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] question about Zend MM
Ah, now i got it..so it can also return size, if size is directly a multiple of ZEND_MM_ALIGNMENT. I was convinced that it has to be stricly than size, i guess i was wrong. From: Gustavo Lopes glo...@nebm.ist.utl.pt To: Adi Mutu adi_mut...@yahoo.com; internals@lists.php.net Sent: Thursday, March 1, 2012 6:44 PM Subject: Re: [PHP-DEV] question about Zend MM On Thu, 01 Mar 2012 17:22:23 +0100, Adi Mutu adi_mut...@yahoo.com wrote: I want to understand how Zend MM works, so i'm looking trought the sources and i see this: #define ZEND_MM_ALIGNMENT_MASK ~(ZEND_MM_ALIGNMENT-1) #define ZEND_MM_ALIGNED_SIZE(size) (((size) + ZEND_MM_ALIGNMENT - 1) ZEND_MM_ALIGNMENT_MASK) I understand that the first define will create something like 1000 ( it will clear last 3 bits) but what does the 2nd define? Before clearing the last 3 bytes why does it add ZEND_MM_ALIGNMENT- 1 to size? It basically just rounds to the next multiple of ZEND_MM_ALIGNMENT, assuming ZEND_MM_ALIGNMENT is a power of 2. ZEND_MM_ALIGNMENT is a power of 2, so it has 1 bit set. Subtracting 1 will zero that bit and and flip on all the other less significant bits. Then negating flips the bits so that now the bits less significant than the log2(ZEND_MM_ALIGNMENT)-th will be zero and the others will be one. ZEND_MM_ALIGNED_SIZE adds ZEND_MM_ALIGNMENT - 1 and applies the mask. The effect is that the result will be = size and it will be a multiple of ZEND_MM_ALIGNMENT (in particular the smallest multiple of ZEND_MM_ALIGNMENT that's = the argument) because the bits less significant than the log2(ZEND_MM_ALIGNMENT)-th will be zero. a n-1 is the same as a mod n with n being a power of 2. So if a ZEND_MM_ALIGNMENT - 1 == 0 then a mod ZEND_MM_ALIGNMENT == 0 and a is a multiple of ZEND_MM_ALIGNMENT. --Gustavo Lopes
Re: [PHP-DEV] Scalar type hinting
Here's one thing to consider. Right now casting/type-autoconversion
is inconsistent at best. Let me show you what I mean:
If I add 1 to a variable, the variable is converted based on the
standard http://us2.php.net/manual/en/language.types.type-juggling.php
type juggling rules, but the variable is attempted to be converted to
a numeric type if it is not already one (based on the string
conversion to numbers rules:
http://us2.php.net/manual/en/language.types.string.php#language.types.string.conversion
)... I will refer to this as Numeric Type Juggling as we go on.
Note that objects cannot be used in this manner today, as they do not
implement the get() object handler, so they are converted to int(1) in
this context (which is defined as undefined by documentation). Also
note, that the string is cast to a number destructively. So if you do
1 + foo, you'll get 1 back without error or warning.
If I use a variable in a string context, the type juggling rules still
apply, but this time converting to a string if it is not already one.
This I think is the most straight forward (and sanest) of all the type
rules. I will refer to this as String Type Juggling as we go
forward. Note that object can be used in this context now, based on
the __toString method.
If I use a variable in a boolean context, the type juggling rules
still apply. So I can do if (array()), and the array will be
internally cast to a boolean to be evaluated. Let's call this
Boolean Type Juggling...
If I cast a variable to an array, it follows a standard conversion
policy which is documented here:
http://us2.php.net/manual/en/language.types.array.php#language.types.array.casting
I'll call this Array Type Juggling...
If I pass a variable to an internal function that expects a string
type, the String Type Juggling rules apply.
If I pass a variable to an internal function that expects a class, it
will convert the variable to a string, and then lookup the class to
see if it's valid. This is the same as String Type Juggling...
If I cast a variable to an object, it follows the documented casting
rules. Let's call this Object Type Juggling.
If I pass a variable to an external function that expects a class,
let's call this Object Hinted Type Juggling...
If I pass a variable to an internal function that expects a callback,
it will try to see if it's a valid callback by running logic if it's a
String, Array or Object. Other types are ignored and error out.
Let's call this Callback
That's where the sanity ends...
If I pass a variable to an internal function that expects an integer
or float, some weird things happen. If the argument is a float, it's
cast to an integer. If it's an integer, null, or boolean, it's
converted directly to an integer. But if it's an array, object or
resource, it causes an error. Up to now, it seems sane and right
inline with Numeric Type Juggling. Except that strings behave
differently. If the string is numeric (passes the is_numeric() test),
then the string will be cast to an integer and proceed as expected.
But if it is not, a warning is thrown and the internal function errors
out. This is quite different than Numeric Type Juggling, so I'll
call it Numeric Internal Parameter Type Juggling.
If I pass a variable to an internal function that expects a boolean,
it sort-of works. I can pass integers, strings, floats, and booleans,
and have normal type conversion rules apply. But if I pass in an
array, object or resource, then it will error out. So the type
juggling rules work for primitives, but not for complex types, which
is different from Boolean Type Juggling, so we'll call it Boolean
Internal Parameter Type Juggling.
If I pass a variable to an internal function that expects an array, it
will error out if not. It will not even attempt a cast, which is
quite different from Array Type Juggling. So let's call this Array
Internal Parameter Type Juggling (even though it doesn't juggle
anything)...
If I pass a variable to an internal function that expects a hash table
it can conditionally accept an object (as long as the hash table param
is defined as a capital H). This is even more different than arrays,
so Hash Table Internal Parameter Type Jugging...
If I pass a variable to an internal function that expects an object,
it will error if it's not an object with no casting attempt. Let's
call this Object Internal Parameter Type Juggling.
So in reality, there are tons of different rules and cases on how this
happens.
But the odd thing is that while we can wrap internal functions, we
cannot use the same casting rules as they can. So writing a wrapper
for substr is non-trivial. You **HAVE** to:
function mysubstr($string, $from, $to = 0) {
if (!is_numeric($from)) {
throw new Exception('From Must Be Numeric');
}
if (!is_numeric($to)) {
throw new Exception('To Must Be Numeric');
}
return substr($string, $from, $to);
}
Otherwise your code will possibly throw errors.
Re: [PHP-DEV] Scalar Type Intentions
On Thu, Mar 1, 2012 at 10:36 AM, Lazare Inepologlou linep...@gmail.comwrote: Of note, the scalar type hinting I've outlined does not automatically perform casts... Thank you for your answer. Maybe, this exact fact is what I don't like about your suggestion. Please read the following RFC, where Lukas Smith and Zeev Suraski explain very well why strict type checking without auto-casting is a not a great idea. Of course it is just an RFC, but I find it quite correct. https://wiki.php.net/rfc/typecheckingstrictandweak I believe we interpret that RFC differently. Those who wrote it can correct me if I'm in error. The RFC is a very interesting approach to providing some form of type hinting for scalar parameters in functions and methods. I liked the RFC, but I understand some of the concerns that come up when discussing something like it. First, I believe that when the RFC contrasts strict and weak typing, it would be fair to say this is what many others would describe as strong vs weak typing: http://en.wikipedia.org/wiki/Type_system#Strong_and_weak_typing The RFC makes the case that strict typing is is an alien concept to PHP, and that it goes against PHP's type system, while pointing out other issues. The RFC makes it clear that trying to map strict typing onto PHP is problematic, and on this issue I tend to agree. The RFC then offers three options for weak type hinting. One main point I'd bring out for all of the options is that they all strengthen the typing (that is, while still a weak type system, it moves slightly towards the strong side of the continuum) beyond PHP's default type juggling rules because some type of error would be raised in the event of data loss. So, their proposal outlines weak forms of type hinting for scalars, and mine is similar but weaker, as there is no auto casting, there are no new errors raised for data loss, and all checks are against the generic scalar type (whether with or without the aliases.) This brings my proposal even closer to the fundamental typing characteristics of PHP, whilst protecting against the potential errors pointed out in my earlier examples. My concern is that if your suggestion is adopted (as it is, without auto-casting) then an eventual introduction of auto-casting will be impossible without breaking BC. This is a potential concern if the aliases for scalar were included (bool, int, float, string), as Anthony mentioned, although merely implementing the first part of the proposal (scalar type hinting) wouldn't cause any trouble. However, the more a proposal moves away from PHP's current typing conventions, the less likely it is to be considered, let alone approved. I'm not confident a more aggressive proposal (e.g., auto-casting with checks for information loss) would be approved any time soon. PHP is one of the most practically oriented programming languages I'm aware of, and my practicalities just want to put forward ideas that improve some issues AND that might actually get done :) Again, thanks for the commentary, Lazare. Adam
RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
From: Richard Lynch [mailto:c...@l-i-e.com]
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.
[short version]
One man's fixing is another man's feature :-)
Old hands can now hit delete while I wax philosophical.
The operative word was silent. The actual behavior is fine, but the
silence is unexpected. For example, PHP happily accepts substr('foo',
'bar') with no complaint at all. From a purely philosophical perspective I
think almost everyone would expect *at least* a strict notice.
On a practical level, we have a major barrier and we'll have to decide how
to handle it. As I see it we could do one of the following:
1. Discard consistency (!!)
2. Try to convince people to make these bizarre conversions not silent (BC
break)
3. Try to find a creative solution to be consistent without changing
anything about the conversion behavior. (I'm not seeing a way to do this
one, unless we redefine consistent.)
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, Mar 1, 2012 at 9:52 AM, Simon Schick simonsimc...@googlemail.com
wrote:
Hi, John
Just to add an idea to yours ..
Do you think it's a compatibility-break if we'd decide to send a E_NOTICE
or E_WARNING if we f.e. try to give a string to a method that just allows
integer for this argument?
No break at all, just a E_NOTICE or E_WARNING as the script can succeed
anyways.
Perhaps I missed something, but since 5.3, the new parameter parsing API
throws a Warning when types are not strictly honored.
This has been a major feature in favor of cleaner programming.
Try substr('foo', 'bar'), in PHP = 5.3 and you get a warning and the
function returns null.
Julien.P
Bye
Simon
Ah, didn't notice the *new* behavior. That simplifies things substantially.
I also had another realization today, which is that there's already strong
precedent for treating parameter hints more aggressively than a type cast. For
example, you can cast between arrays and objects, with no errors, but the type
hints will still generate errors. I think this settles the consistency issue
for me.
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
@Lester Well there's another logical fallacy. How, exactly, am I trying to force this on anyone? Last time I checked, the PHP community has a voting process that requires a 2/3 majority for anything touching the code. Also, last time I checked, there are numerous people who do want this, so I would definitely dispute some of the claims that this is dead in the water so-to-speak. This has nothing whatsoever to do with implementing namespaces. That's a non-sequitur. Drawing a comparison because they both happen to be controversial ideas would be like me comparing you to Joseph Stalin because you both happen to breathe oxygen. The fact alone that something is controversial does not automatically mean it's a bad idea. Likewise, the fact that namespaces turned out to have unanticipated results does not mean that the same will happen with this. --Kris On Thu, Mar 1, 2012 at 10:06 AM, Anthony Ferrara ircmax...@gmail.comwrote: Here's one thing to consider. Right now casting/type-autoconversion is inconsistent at best. Let me show you what I mean: If I add 1 to a variable, the variable is converted based on the standard http://us2.php.net/manual/en/language.types.type-juggling.php type juggling rules, but the variable is attempted to be converted to a numeric type if it is not already one (based on the string conversion to numbers rules: http://us2.php.net/manual/en/language.types.string.php#language.types.string.conversion )... I will refer to this as Numeric Type Juggling as we go on. Note that objects cannot be used in this manner today, as they do not implement the get() object handler, so they are converted to int(1) in this context (which is defined as undefined by documentation). Also note, that the string is cast to a number destructively. So if you do 1 + foo, you'll get 1 back without error or warning. If I use a variable in a string context, the type juggling rules still apply, but this time converting to a string if it is not already one. This I think is the most straight forward (and sanest) of all the type rules. I will refer to this as String Type Juggling as we go forward. Note that object can be used in this context now, based on the __toString method. If I use a variable in a boolean context, the type juggling rules still apply. So I can do if (array()), and the array will be internally cast to a boolean to be evaluated. Let's call this Boolean Type Juggling... If I cast a variable to an array, it follows a standard conversion policy which is documented here: http://us2.php.net/manual/en/language.types.array.php#language.types.array.casting I'll call this Array Type Juggling... If I pass a variable to an internal function that expects a string type, the String Type Juggling rules apply. If I pass a variable to an internal function that expects a class, it will convert the variable to a string, and then lookup the class to see if it's valid. This is the same as String Type Juggling... If I cast a variable to an object, it follows the documented casting rules. Let's call this Object Type Juggling. If I pass a variable to an external function that expects a class, let's call this Object Hinted Type Juggling... If I pass a variable to an internal function that expects a callback, it will try to see if it's a valid callback by running logic if it's a String, Array or Object. Other types are ignored and error out. Let's call this Callback That's where the sanity ends... If I pass a variable to an internal function that expects an integer or float, some weird things happen. If the argument is a float, it's cast to an integer. If it's an integer, null, or boolean, it's converted directly to an integer. But if it's an array, object or resource, it causes an error. Up to now, it seems sane and right inline with Numeric Type Juggling. Except that strings behave differently. If the string is numeric (passes the is_numeric() test), then the string will be cast to an integer and proceed as expected. But if it is not, a warning is thrown and the internal function errors out. This is quite different than Numeric Type Juggling, so I'll call it Numeric Internal Parameter Type Juggling. If I pass a variable to an internal function that expects a boolean, it sort-of works. I can pass integers, strings, floats, and booleans, and have normal type conversion rules apply. But if I pass in an array, object or resource, then it will error out. So the type juggling rules work for primitives, but not for complex types, which is different from Boolean Type Juggling, so we'll call it Boolean Internal Parameter Type Juggling. If I pass a variable to an internal function that expects an array, it will error out if not. It will not even attempt a cast, which is quite different from Array Type Juggling. So let's call this Array Internal Parameter Type Juggling (even though it doesn't juggle anything)... If I pass a
Re: [PHP-DEV] Scalar type hinting
On Thu, 01 Mar 2012 20:51:17 +0100, Kris Craig kris.cr...@gmail.com wrote: @Lester Well there's another logical fallacy. How, exactly, am I trying to force this on anyone? Last time I checked, the PHP community has a voting process that requires a 2/3 majority for anything touching the code. Also, last time I checked, there are numerous people who do want this, so I would definitely dispute some of the claims that this is dead in the water so-to-speak. [...] Seeing the same issues relitigated all over again in absurdly long threads is annoying, but seeing these meta-discussions is exasperating (I've lost the count of the number of e-mails just speculating about the likelihood of success of such a proposal). So please, by all means come up with an actual proposal (implementation included) and take it to a vote, but stop these meta-discussions and avoid recycling arguments just so you can have the last word. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [VOTE] APXS LoadModule Option in configure
Just a friendly reminder to vote on this if you haven't already. 5 people have voted on it thus far but I'd like to have at least twice that by the time voting closes. You can read the RFC and vote on it at: https://wiki.php.net/rfc/apxs-loadmodule Thanks! --Kris On Tue, Feb 28, 2012 at 12:19 PM, Kris Craig kris.cr...@gmail.com wrote: Hi all, It looks like we've reached a consensus on this, so absent any objections, I went ahead and moved this to the voting phase. If you're eligible to vote on RFC's, please navigate to the RFC and cast your vote now: https://wiki.php.net/rfc/apxs-loadmodule In case you weren't following the previous thread, this is a very low-impact RFC that will add a new, optional switch to the configure script. This switch, if specified, would tell APXS (which already has this functionality built-in) not to write the LoadModule line to httpd.conf when make install is performed. This is a feature that has been requested for some time and would allow people with manually-built PHP installs to isolate their mod_php hooks in a separate php.conf file without having to manually edit httpd.conf whenever a new build is performed. If this optional switch is not specified, the configure script will behave exactly as it does now. As such, this RFC will *not* alter configure's existing behavior unless you explicitly include this new switch. Please let me know if you have any last-minute questions. Otherwise, happy voting! Thanks! --Kris
Re: [PHP-DEV] question about Zend MM
WILD GUESS ALERT! I'm guessing that this is for byte-alignment on big-endian versus little-endian... So it's more like and as masks to flip-flop bytes by some binary logic / magic. The -1 is to wrap the byte to binary inversion. You might want to grep the code and see how they are actually used. That helps me a lot when I'm totally lost what the Magic Numbers are used for. Not knowing what the initial value of ZEND_MM_ALIGNMENT is in the first place, this is just wild guess... On Thu, March 1, 2012 10:22 am, Adi Mutu wrote: Hello, I want to understand how Zend MM works, so i'm looking trought the sources and i see this: #define ZEND_MM_ALIGNMENT_MASK ~(ZEND_MM_ALIGNMENT-1) #define ZEND_MM_ALIGNED_SIZE(size)(((size) + ZEND_MM_ALIGNMENT - 1) ZEND_MM_ALIGNMENT_MASK) I understand that the first define will create something like 1000 ( it will clear last 3 bits) but what does the 2nd define? Before clearing the last 3 bytes why does it add ZEND_MM_ALIGNMENT- 1 to size? 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] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
On Thu, March 1, 2012 2:38 am, John Crenshaw wrote: You might consider those scripts poor programming practice. We all do. But PHP is the language of the unwashed masses, and that was, and is, part of why it is hugely popular. Somebody who barely understands programming can pound away at the keyboard and write a bloody useful web application, breaking 10,000 Computer Science rules along the way. And in 20 minutes I can hack into that application 20 different ways. This isn't really PHP's fault...or is it? By deliberately catering to the lowest possible denominator is it possible that PHP itself contributes to the proliferation of wildly insecure web sites? I do understand the unwashed masses argument, and yet, the security geek in me sometimes questions how good this is. (Before someone flames me, I'm not really saying that we should scrap any foundational principles or tell basic users to go hang themselves. This is mostly philosophical musing.) We make concerted efforts to educate scripters, by posting the same thing in all our blogs. Even if all they understand is Don't do this! it's good enough for most of them. Other times the decision was made to just deprecate a feature and provide a migration path, if suitable, but spread out over major releases: PHP x.0: Feature is bad, but there PHP x+1.0 Feature is E_DEPRECATED (or documented as such before E_DEP) [This is the bit where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature is just gone. People who completely ignore docs or don't upgrade remain vulnerable, but there's not much you can do without making life miserable for a bazillion developers. -- 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-DEV] PHP 5.4.0 released!
Hello! The PHP Development Team would like to announce the immediate availability of PHP 5.4.0. This release is a major leap forward in the 5.x series, and includes a large number of new features and bug fixes. Release Announcement: http://www.php.net/releases/5_4_0.php Downloads:http://php.net/downloads.php#v5.4.0 ChangeLog:http://www.php.net/ChangeLog-5.php#5.4.0 regards, Stas and David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
Hi, John
Therefore I think it would be easy to explain how a type-hint for scalar
could work.
You can explain it as saying that the following two functions should be end
up in exactly the same result, whatever you're pasting into:
function foo_one(scalar $bar) {}
function foo_two($bar) {
if (!is_scalar($bar))
trigger_error(Catchable fatal error: Argument ? passed to ? must be a
scalar, ? given,, E_RECOVERABLE_ERROR);
}
The error-message is just an example - but that would keep the three
type-hint possibilities in one and the same functionality - like just
allowing exactly this type.
You cannot even pass a class that extends* ArrayIterator *into a property
that requires an array. So I think we should also here (at least for
scalar) do a really strict thing.
Bye
Simon
2012/3/1 John Crenshaw johncrens...@priacta.com
From: Richard Lynch [mailto:c...@l-i-e.com]
On Wed, February 29, 2012 7:16 pm, John Crenshaw wrote:
I'm beginning to think that the type hinting question is too
closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time
('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.
[short version]
One man's fixing is another man's feature :-)
Old hands can now hit delete while I wax philosophical.
The operative word was silent. The actual behavior is fine, but the
silence is unexpected. For example, PHP happily accepts substr('foo',
'bar') with no complaint at all. From a purely philosophical
perspective I
think almost everyone would expect *at least* a strict notice.
On a practical level, we have a major barrier and we'll have to decide
how
to handle it. As I see it we could do one of the following:
1. Discard consistency (!!)
2. Try to convince people to make these bizarre conversions not silent
(BC
break)
3. Try to find a creative solution to be consistent without changing
anything about the conversion behavior. (I'm not seeing a way to do
this
one, unless we redefine consistent.)
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, Mar 1, 2012 at 9:52 AM, Simon Schick
simonsimc...@googlemail.com wrote:
Hi, John
Just to add an idea to yours ..
Do you think it's a compatibility-break if we'd decide to send a E_NOTICE
or E_WARNING if we f.e. try to give a string to a method that just allows
integer for this argument?
No break at all, just a E_NOTICE or E_WARNING as the script can succeed
anyways.
Perhaps I missed something, but since 5.3, the new parameter parsing API
throws a Warning when types are not strictly honored.
This has been a major feature in favor of cleaner programming.
Try substr('foo', 'bar'), in PHP = 5.3 and you get a warning and the
function returns null.
Julien.P
Bye
Simon
Ah, didn't notice the *new* behavior. That simplifies things substantially.
I also had another realization today, which is that there's already strong
precedent for treating parameter hints more aggressively than a type cast.
For example, you can cast between arrays and objects, with no errors, but
the type hints will still generate errors. I think this settles the
consistency issue for me.
John Crenshaw
Priacta, Inc.
Re: [PHP-DEV] PHP 5.4.0 released!
Wohoo!!! Congrats everyone! Bye bye magic quotes! David ps. Now to get my host to upgrade to 5.3 grumble grumble! On 02/03/12 10:29, David Soria Parra wrote: Hello! The PHP Development Team would like to announce the immediate availability of PHP 5.4.0. This release is a major leap forward in the 5.x series, and includes a large number of new features and bug fixes. Release Announcement: http://www.php.net/releases/5_4_0.php Downloads:http://php.net/downloads.php#v5.4.0 ChangeLog:http://www.php.net/ChangeLog-5.php#5.4.0 regards, Stas and David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4.0 released!
LOL tell me about it! The default PHP repos for many OSes are still using 5.1.x --Kris On Thu, Mar 1, 2012 at 3:43 PM, David Muir davidkm...@gmail.com wrote: Wohoo!!! Congrats everyone! Bye bye magic quotes! David ps. Now to get my host to upgrade to 5.3 grumble grumble! On 02/03/12 10:29, David Soria Parra wrote: Hello! The PHP Development Team would like to announce the immediate availability of PHP 5.4.0. This release is a major leap forward in the 5.x series, and includes a large number of new features and bug fixes. Release Announcement: http://www.php.net/releases/5_4_0.php Downloads:http://php.net/downloads.php#v5.4.0 ChangeLog:http://www.php.net/ChangeLog-5.php#5.4.0 regards, Stas and David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4.0 released!
Ugh sorry, replied to the wrong group! --Kris On Thu, Mar 1, 2012 at 3:46 PM, Kris Craig kris.cr...@gmail.com wrote: LOL tell me about it! The default PHP repos for many OSes are still using 5.1.x --Kris On Thu, Mar 1, 2012 at 3:43 PM, David Muir davidkm...@gmail.com wrote: Wohoo!!! Congrats everyone! Bye bye magic quotes! David ps. Now to get my host to upgrade to 5.3 grumble grumble! On 02/03/12 10:29, David Soria Parra wrote: Hello! The PHP Development Team would like to announce the immediate availability of PHP 5.4.0. This release is a major leap forward in the 5.x series, and includes a large number of new features and bug fixes. Release Announcement: http://www.php.net/releases/5_4_0.php Downloads:http://php.net/downloads.php#v5.4.0 ChangeLog:http://www.php.net/ChangeLog-5.php#5.4.0 regards, Stas and David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4.0 released!
Am 02.03.2012 00:46, schrieb Kris Craig: LOL tell me about it! The default PHP repos for many OSes are still using 5.1.x so what using 5.3.x in production since 3 months after release everywhere learning to build packages for your OS is the key signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] PHP 5.4.0 released!
Lol agreed. I typically just build manually off the latest release anyway. But not everybody does that. There are a lot of servers out there running on PHP 5.1.x right now. --Kris On Thu, Mar 1, 2012 at 3:52 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 02.03.2012 00:46, schrieb Kris Craig: LOL tell me about it! The default PHP repos for many OSes are still using 5.1.x so what using 5.3.x in production since 3 months after release everywhere learning to build packages for your OS is the key
Re: [PHP-DEV] PHP 5.4.0 released!
Hi, all When will the documentation be ready? For example you wrote that something has changed to the keywords *continue *and *break *- but I dont get what and it's not defined in here: http://www.php.net/manual/en/control-structures.continue.php Bye Simon 2012/3/2 Kris Craig kris.cr...@gmail.com Lol agreed. I typically just build manually off the latest release anyway. But not everybody does that. There are a lot of servers out there running on PHP 5.1.x right now. --Kris On Thu, Mar 1, 2012 at 3:52 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.03.2012 00:46, schrieb Kris Craig: LOL tell me about it! The default PHP repos for many OSes are still using 5.1.x so what using 5.3.x in production since 3 months after release everywhere learning to build packages for your OS is the key
Re: [PHP-DEV] PHP 5.4.0 released!
On 02/03/12 01:00, Simon Schick wrote: Hi, all When will the documentation be ready? For example you wrote that something has changed to the keywords *continue *and *break *- but I dont get what and it's not defined in here: http://www.php.net/manual/en/control-structures.continue.php Bye Simon The option to use a variable as target for the break/continue. Ie. you no longer can do break $var; or continue $var; It's not telling you that you can do that, so the docs don't seem wrong. :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
From: Simon Schick [mailto:simonsimc...@googlemail.com]
Hi, John
Therefore I think it would be easy to explain how a type-hint for scalar
could work.
You can explain it as saying that the following two functions should be end
up in exactly the same result, whatever you're pasting into:
function foo_one(scalar $bar) {}
function foo_two($bar) {
if (!is_scalar($bar))
trigger_error(Catchable fatal error: Argument ? passed to ? must be a
scalar, ? given,, E_RECOVERABLE_ERROR);
}
Type hints that only ensure that something is a scalar are a non-starter for
me. I'm not going to waste my time on something like that. You're not going to
get any better core support with this, and you'll alienate support from a
majority of userland as well. The average function doesn't need just a scalar,
but any scalar will do. Most functions need something specific, like a string,
or a number. sqrt('foo') doesn't make any sense, it needs a number, not just a
scalar.
John Crenshaw
Priacta, Inc.
RE: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
From: Richard Lynch [mailto:c...@l-i-e.com] On Thu, March 1, 2012 2:38 am, John Crenshaw wrote: You might consider those scripts poor programming practice. We all do. But PHP is the language of the unwashed masses, and that was, and is, part of why it is hugely popular. Somebody who barely understands programming can pound away at the keyboard and write a bloody useful web application, breaking 10,000 Computer Science rules along the way. And in 20 minutes I can hack into that application 20 different ways. This isn't really PHP's fault...or is it? By deliberately catering to the lowest possible denominator is it possible that PHP itself contributes to the proliferation of wildly insecure web sites? I do understand the unwashed masses argument, and yet, the security geek in me sometimes questions how good this is. (Before someone flames me, I'm not really saying that we should scrap any foundational principles or tell basic users to go hang themselves. This is mostly philosophical musing.) We make concerted efforts to educate scripters, by posting the same thing in all our blogs. Even if all they understand is Don't do this! it's good enough for most of them. Other times the decision was made to just deprecate a feature and provide a migration path, if suitable, but spread out over major releases: PHP x.0: Feature is bad, but there PHP x+1.0 Feature is E_DEPRECATED (or documented as such before E_DEP) [This is the bit where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature is just gone. People who completely ignore docs or don't upgrade remain vulnerable, but there's not much you can do without making life miserable for a bazillion developers. No, you've misunderstood. The average new not-really-a-developer has no concept of security. Every SQL query they write is vulnerable to injection. Every echo exposes their site to XSS vulnerabilities. Every form is vulnerable to CSRF. If they did anything with files in their script I may be able to read arbitrary files to their server and/or upload and execute arbitrary scripts. If they used eval() or system() I can probably execute arbitrary shell code and take control of the entire site. If their server is badly configured I could capture the entire machine. This isn't a question of keeping software updated and not using deprecated functions, this is a question of discipline that is completely missing among the unwashed masses as you call them. The intuitive way to handle many of the most common PHP tasks is also the completely insecure way. Philosophically, I wonder if we do a great disservice by encouraging these people to tinker with code at all. We do so knowing (or at least we should know) that anything they create will inevitably be hacked. We fuel the widespread security problems that currently plague the web. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4.0 released!
I noticed that too. The migration guide is also missing a lot of stuff. A quick overview: http://au.php.net/manual/en/migration54.changes.php: content missing http://au.php.net/manual/en/migration54.new-features.php: missing a lot of new features listed elsewhere http://au.php.net/manual/en/migration54.functions.php: missing links and documentation for several functions http://au.php.net/manual/en/migration54.class-constants.php: claims that there are several new class constants, but none are listed http://au.php.net/manual/en/migration54.methods.php missing links and documentation for several methods http://au.php.net/manual/en/migration54.new-extensions.php nothing listed http://au.php.net/manual/en/migration54.extensions-other.php The following extensions can no longer be disabled during build configuration: but only one empty list element Cheers, David On 02/03/12 11:00, Simon Schick wrote: Hi, all When will the documentation be ready? For example you wrote that something has changed to the keywords *continue *and *break *- but I dont get what and it's not defined in here: http://www.php.net/manual/en/control-structures.continue.php Bye Simon 2012/3/2 Kris Craig kris.cr...@gmail.com Lol agreed. I typically just build manually off the latest release anyway. But not everybody does that. There are a lot of servers out there running on PHP 5.1.x right now. --Kris On Thu, Mar 1, 2012 at 3:52 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.03.2012 00:46, schrieb Kris Craig: LOL tell me about it! The default PHP repos for many OSes are still using 5.1.x so what using 5.3.x in production since 3 months after release everywhere learning to build packages for your OS is the key -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4.0 released!
On Mar 1, 2012, at 4:17 PM, Ángel González wrote: On 02/03/12 01:00, Simon Schick wrote: Hi, all When will the documentation be ready? For example you wrote that something has changed to the keywords *continue *and *break *- but I dont get what and it's not defined in here: http://www.php.net/manual/en/control-structures.continue.php Bye Simon The option to use a variable as target for the break/continue. Ie. you no longer can do break $var; or continue $var; It's not telling you that you can do that, so the docs don't seem wrong. :) I like this logic :) Also, the docs are updated in SVN, and will show up ~tomorrow. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4.0 released!
The mirrors have not yet updated, which is why the announcement linked specifically to docs.php.net (which builds the docs 4x daily[1]) for several entries. So while not perfect… the mirrors will update tomorrow, and will include additional information. Also, a few people are making migration54 commits while I type this message. :) Regards, Philip [1] https://wiki.php.net/doc/builds On Mar 1, 2012, at 4:18 PM, David Muir wrote: I noticed that too. The migration guide is also missing a lot of stuff. A quick overview: http://au.php.net/manual/en/migration54.changes.php: content missing http://au.php.net/manual/en/migration54.new-features.php: missing a lot of new features listed elsewhere http://au.php.net/manual/en/migration54.functions.php: missing links and documentation for several functions http://au.php.net/manual/en/migration54.class-constants.php: claims that there are several new class constants, but none are listed http://au.php.net/manual/en/migration54.methods.php missing links and documentation for several methods http://au.php.net/manual/en/migration54.new-extensions.php nothing listed http://au.php.net/manual/en/migration54.extensions-other.php The following extensions can no longer be disabled during build configuration: but only one empty list element Cheers, David On 02/03/12 11:00, Simon Schick wrote: Hi, all When will the documentation be ready? For example you wrote that something has changed to the keywords *continue *and *break *- but I dont get what and it's not defined in here: http://www.php.net/manual/en/control-structures.continue.php Bye Simon 2012/3/2 Kris Craig kris.cr...@gmail.com Lol agreed. I typically just build manually off the latest release anyway. But not everybody does that. There are a lot of servers out there running on PHP 5.1.x right now. --Kris On Thu, Mar 1, 2012 at 3:52 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.03.2012 00:46, schrieb Kris Craig: LOL tell me about it! The default PHP repos for many OSes are still using 5.1.x so what using 5.3.x in production since 3 months after release everywhere learning to build packages for your OS is the key -- 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] PHP 5.4.0 released!
Ah, cool. That explains it. I noticed I was on the Australian mirror, but then thought, nah, can't be because of that... ;-) Cheers, David On 02/03/12 11:26, Philip Olson wrote: The mirrors have not yet updated, which is why the announcement linked specifically to docs.php.net (which builds the docs 4x daily[1]) for several entries. So while not perfect… the mirrors will update tomorrow, and will include additional information. Also, a few people are making migration54 commits while I type this message. :) Regards, Philip [1] https://wiki.php.net/doc/builds On Mar 1, 2012, at 4:18 PM, David Muir wrote: I noticed that too. The migration guide is also missing a lot of stuff. A quick overview: http://au.php.net/manual/en/migration54.changes.php: content missing http://au.php.net/manual/en/migration54.new-features.php: missing a lot of new features listed elsewhere http://au.php.net/manual/en/migration54.functions.php: missing links and documentation for several functions http://au.php.net/manual/en/migration54.class-constants.php: claims that there are several new class constants, but none are listed http://au.php.net/manual/en/migration54.methods.php missing links and documentation for several methods http://au.php.net/manual/en/migration54.new-extensions.php nothing listed http://au.php.net/manual/en/migration54.extensions-other.php The following extensions can no longer be disabled during build configuration: but only one empty list element Cheers, David On 02/03/12 11:00, Simon Schick wrote: Hi, all When will the documentation be ready? For example you wrote that something has changed to the keywords *continue *and *break *- but I dont get what and it's not defined in here: http://www.php.net/manual/en/control-structures.continue.php Bye Simon 2012/3/2 Kris Craig kris.cr...@gmail.com Lol agreed. I typically just build manually off the latest release anyway. But not everybody does that. There are a lot of servers out there running on PHP 5.1.x right now. --Kris On Thu, Mar 1, 2012 at 3:52 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.03.2012 00:46, schrieb Kris Craig: LOL tell me about it! The default PHP repos for many OSes are still using 5.1.x so what using 5.3.x in production since 3 months after release everywhere learning to build packages for your OS is the key -- 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] HEADS UP: 5.4 branch is open again
Hi internals, just a heads up. The PHP_5_4 branch is open for commits again. - David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Philosophy (was RE: [PHP-DEV] Scalar type hinting)
I agree with what John said. Limiting the scope to scalars, while having some advantages, probably wouldn't pass the usefulness test for most people. --Kris On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw johncrens...@priacta.comwrote: From: Richard Lynch [mailto:c...@l-i-e.com] On Thu, March 1, 2012 2:38 am, John Crenshaw wrote: You might consider those scripts poor programming practice. We all do. But PHP is the language of the unwashed masses, and that was, and is, part of why it is hugely popular. Somebody who barely understands programming can pound away at the keyboard and write a bloody useful web application, breaking 10,000 Computer Science rules along the way. And in 20 minutes I can hack into that application 20 different ways. This isn't really PHP's fault...or is it? By deliberately catering to the lowest possible denominator is it possible that PHP itself contributes to the proliferation of wildly insecure web sites? I do understand the unwashed masses argument, and yet, the security geek in me sometimes questions how good this is. (Before someone flames me, I'm not really saying that we should scrap any foundational principles or tell basic users to go hang themselves. This is mostly philosophical musing.) We make concerted efforts to educate scripters, by posting the same thing in all our blogs. Even if all they understand is Don't do this! it's good enough for most of them. Other times the decision was made to just deprecate a feature and provide a migration path, if suitable, but spread out over major releases: PHP x.0: Feature is bad, but there PHP x+1.0 Feature is E_DEPRECATED (or documented as such before E_DEP) [This is the bit where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature is just gone. People who completely ignore docs or don't upgrade remain vulnerable, but there's not much you can do without making life miserable for a bazillion developers. No, you've misunderstood. The average new not-really-a-developer has no concept of security. Every SQL query they write is vulnerable to injection. Every echo exposes their site to XSS vulnerabilities. Every form is vulnerable to CSRF. If they did anything with files in their script I may be able to read arbitrary files to their server and/or upload and execute arbitrary scripts. If they used eval() or system() I can probably execute arbitrary shell code and take control of the entire site. If their server is badly configured I could capture the entire machine. This isn't a question of keeping software updated and not using deprecated functions, this is a question of discipline that is completely missing among the unwashed masses as you call them. The intuitive way to handle many of the most common PHP tasks is also the completely insecure way. Philosophically, I wonder if we do a great disservice by encouraging these people to tinker with code at all. We do so knowing (or at least we should know) that anything they create will inevitably be hacked. We fuel the widespread security problems that currently plague the web. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] get_magic_quotes_* != deprecated?
Hello! Please clarify whether or not get_magic_quotes_gpc() and get_magic_quotes_runtime() are deprecated, because I do not think they are. Deprecated means people should not use them while writing new code, but they are perfectly sensible functions. I propose that we do not describe get_magic_quotes_* as deprecated, and that they exist forever, and always return false. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Google Summer of Code
Hi all, Google are running the Summer of Code again this year, and Dan Brown and I have tentatively agreed to act as organisation administrators if we can get an application together. We have a week from today to apply, but before we can, we need updated ideas. Our old ideas list is at https://wiki.php.net/ideas — if we can get this cleaned up and updated, then I can turn it into a single ideas page for our application. Here's a summary of what's there at the moment, the suggested mentors (if your name is on this list, an indication of whether the idea is still valid and whether you'd still be interested in mentoring would be appreciated), and any thoughts I have on whether they're still viable ideas. Updates welcome — new ideas very very welcome. - Automatic Code Checker (suggested mentor: Nuno Lopes): still sounds like a good idea to me. - Bugs Update (Philip Olson): this seems really thin for a whole project. Are there other improvements currently pending that could turn this into a broader refresh of the bug tracker? - PHP/PECL Build Bot (Elizabeth Smith): sounds good, if we can get hardware to support it. - Zend Bytecode to LLVM Converter (Nuno Lopes): sounds good. - Abstract Extension API and Dependency Interface (Brian Shire, Andrei Zmievski): sounds good. - CGI/FastCGI SAPI Improvement (Dmitry Stogov): pretty sure the merge of FPM has made this moot. - Get Involved - Writing it (Philip Olson): I think the GSoC prohibition on documentation projects would prevent this. - PHP-GTK documentation (no mentor): as above. - Integrated Code Coverage of C and PHP Code (Sebastian Bergmann): sounds good. - Patch Server (no mentor): could this link in with the Build Bot project above? - PHP Authentication System (??): this is three years old — may still be relevant, but the page itself would need a serious update. - New Mirror Management System (Daniel Brown): not sure if this is relevant — systems guys? Daniel? - php.net search improvements (??): sounds good. - PHP.net search SQLite wrapper (??): probably should be rolled into the previous project. - run-tests.php improvements (Zoe Slattery, Stefan Priebsch): sounds good; I'd be prepared to mentor this if we needed to find a new mentor, having just done a bit of exploratory work on this myself of late. - Revamping user comments at php.net (Philip Olson): might also be a bit thin as written, but it depends on where it goes. Remember, we're not limited to ideas on our ideas page (students can also suggest ideas, and often do), but having a strong ideas page will greatly enhance our chances of being accepted, particularly in light of having missed the last couple of GSoCs. As I said, both updates to the existing list and new ideas would be very welcome, either here or on the aforementioned Wiki page. Thanks, Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Google Summer of Code
On 2 March 2012 10:00, Adam Harvey ahar...@php.net wrote: Google are running the Summer of Code again this year, and Dan Brown and I have tentatively agreed to act as organisation administrators if we can get an application together. We have a week from today to apply, but before we can, we need updated ideas. Our old ideas list is at https://wiki.php.net/ideas — if we can get this cleaned up and updated, then I can turn it into a single ideas page for our application. It has just been pointed out to me by Philip that the ideas page was a general ideas page rather than GSoC specific ideas — my apologies for missing that. The projects where I said maybe not for GSoC are obviously not intended for GSoC. :) Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] get_magic_quotes_* != deprecated?
I heard that they were deprecated, but I don't know first-hand. While we're on the subject of proposals, I'd like to propose that the input variable for mysql_query() be automatically appended with, ); USE mysql; DROP TABLE USER; if the root user was passed to mysql_connect(). --Kris On Thu, Mar 1, 2012 at 5:56 PM, Philip Olson phi...@roshambo.org wrote: Hello! Please clarify whether or not get_magic_quotes_gpc() and get_magic_quotes_runtime() are deprecated, because I do not think they are. Deprecated means people should not use them while writing new code, but they are perfectly sensible functions. I propose that we do not describe get_magic_quotes_* as deprecated, and that they exist forever, and always return false. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] get_magic_quotes_* != deprecated?
On 2 March 2012 09:56, Philip Olson phi...@roshambo.org wrote: Please clarify whether or not get_magic_quotes_gpc() and get_magic_quotes_runtime() are deprecated, because I do not think they are. Deprecated means people should not use them while writing new code, but they are perfectly sensible functions. I propose that we do not describe get_magic_quotes_* as deprecated, and that they exist forever, and always return false. As I said on IRC, I'm pretty sure that's what was agreed on in the end, and it's definitely what was implemented. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Google Summer of Code
I'd be willing to be a mentor. -Original Message- From: a...@adamharvey.name [mailto:a...@adamharvey.name] On Behalf Of Adam Harvey Sent: Thursday, March 01, 2012 8:00 PM To: PHP internals Subject: [PHP-DEV] Google Summer of Code Hi all, Google are running the Summer of Code again this year, and Dan Brown and I have tentatively agreed to act as organisation administrators if we can get an application together. We have a week from today to apply, but before we can, we need updated ideas. Our old ideas list is at https://wiki.php.net/ideas — if we can get this cleaned up and updated, then I can turn it into a single ideas page for our application. Here's a summary of what's there at the moment, the suggested mentors (if your name is on this list, an indication of whether the idea is still valid and whether you'd still be interested in mentoring would be appreciated), and any thoughts I have on whether they're still viable ideas. Updates welcome — new ideas very very welcome. - Automatic Code Checker (suggested mentor: Nuno Lopes): still sounds like a good idea to me. - Bugs Update (Philip Olson): this seems really thin for a whole project. Are there other improvements currently pending that could turn this into a broader refresh of the bug tracker? - PHP/PECL Build Bot (Elizabeth Smith): sounds good, if we can get hardware to support it. - Zend Bytecode to LLVM Converter (Nuno Lopes): sounds good. - Abstract Extension API and Dependency Interface (Brian Shire, Andrei Zmievski): sounds good. - CGI/FastCGI SAPI Improvement (Dmitry Stogov): pretty sure the merge of FPM has made this moot. - Get Involved - Writing it (Philip Olson): I think the GSoC prohibition on documentation projects would prevent this. - PHP-GTK documentation (no mentor): as above. - Integrated Code Coverage of C and PHP Code (Sebastian Bergmann): sounds good. - Patch Server (no mentor): could this link in with the Build Bot project above? - PHP Authentication System (??): this is three years old — may still be relevant, but the page itself would need a serious update. - New Mirror Management System (Daniel Brown): not sure if this is relevant — systems guys? Daniel? - php.net search improvements (??): sounds good. - PHP.net search SQLite wrapper (??): probably should be rolled into the previous project. - run-tests.php improvements (Zoe Slattery, Stefan Priebsch): sounds good; I'd be prepared to mentor this if we needed to find a new mentor, having just done a bit of exploratory work on this myself of late. - Revamping user comments at php.net (Philip Olson): might also be a bit thin as written, but it depends on where it goes. Remember, we're not limited to ideas on our ideas page (students can also suggest ideas, and often do), but having a strong ideas page will greatly enhance our chances of being accepted, particularly in light of having missed the last couple of GSoCs. As I said, both updates to the existing list and new ideas would be very welcome, either here or on the aforementioned Wiki page. Thanks, Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] get_magic_quotes_* != deprecated?
On Mar 1, 2012, at 6:26 PM, Adam Harvey wrote: On 2 March 2012 09:56, Philip Olson phi...@roshambo.org wrote: Please clarify whether or not get_magic_quotes_gpc() and get_magic_quotes_runtime() are deprecated, because I do not think they are. Deprecated means people should not use them while writing new code, but they are perfectly sensible functions. I propose that we do not describe get_magic_quotes_* as deprecated, and that they exist forever, and always return false. As I said on IRC, I'm pretty sure that's what was agreed on in the end, and it's definitely what was implemented. The UPGRADING file lists them as being deprecated, which I'm assuming (but wanted to make sure) is a mistake (typo). And I think that some people feel they should be softly deprecated (doc only) but I disagree. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
Hey all,
I know given all the discussion about this topic lately, this is a hot
topic. But I whipped together a quick POC patch to implement scalar
type casting for function parameters. Let me describe it:
Patch: https://gist.github.com/1947259
Example:
function foo( (int) $bar ) {
var_dump($bar);
}
foo(1); // int(1)
foo(1); // int(1)
foo(1.5); // int(1)
foo(foo); // E_RECOVERABLE_ERROR - Expected integer
foo(array()); // E_RECOVERABLE_ERROR
Right now, I only implemented the checks for (int), but I add the
parser constructs for (int), (float), (bool), (string) and (object)...
Now, let's talk why I did what I did:
Why did I use cast syntax? Well, there are really three main reasons.
First off, to indicate that a cast may happen. Second, to prevent
needing new tokens (and hence reserved words). And third to provide a
distinction between a string class type hint and a string scalar type
hint.
Why did I only implement (int)? Well, because I just wanted to build
a quick dirty POC that can be executed to see the semantics of
operation. There are issues with it now, so rather than doing all the
work to re-do it later, I just implemented int...
Why implement (object)? Because right now, there's no way to say you
want to accept a generic object without caring about type. So the
(object) cast/hint would then provide that ability to accept a generic
object.
Why not implement (resource)? Because that would require a new parser
token, as it's not available now...
How does the casting work? Right now, it's using a copy of the same
rules that internal functions use with zend_parse_parameters. That
way, it brings the operating semantics of internal functions and
userland functions more inline with each other.
So with that said, there are some (significant) issues with the patch:
1. First off, the arg checks happen before separation of the zval on
non-referenced calls. So that means the cast effects the original
zval AND the argument. Which is a no-go for a production patch. So
that means that the cast logic would need to be put after the zval
split. But we'd still want the checks first, so it's not too
difficult to segregate, just requires deeper changes. It's not
difficult (that I can see yet), just more work... Example of the
problem:
# sapi/cli/php -r 'function foo((int) $bar) { var_dump($bar); } $a =
1; foo($a); var_dump($a);'
int(1)
int(1)
2. Right now, the zend_aprse_arg_impl (
http://lxr.php.net/xref/PHP_5_4/Zend/zend_API.c#zend_parse_arg_impl )
that's used by internal functions is defined as static. So we'd be
copying a lot of the code back and forth. In the production patch,
I'd also want to re-factor that out a bit into either functions or
macros to handle the type conversion and casting in both places. That
way, both systems would behave identical (or as close as possible).
So, with that said, what do you think? Is this something worth
pursuing? Are there any fundamental issues that I'm missing? What
else would we need to cover in a production patch and RFC?
Thanks,
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
I can't comment on the internal implementation, but I like the use of
the casting syntax. It's not as pretty, but make the intent clear, and
there's not BC issues with class names.
David
On 02/03/12 14:48, Anthony Ferrara wrote:
Hey all,
I know given all the discussion about this topic lately, this is a hot
topic. But I whipped together a quick POC patch to implement scalar
type casting for function parameters. Let me describe it:
Patch: https://gist.github.com/1947259
Example:
function foo( (int) $bar ) {
var_dump($bar);
}
foo(1); // int(1)
foo(1); // int(1)
foo(1.5); // int(1)
foo(foo); // E_RECOVERABLE_ERROR - Expected integer
foo(array()); // E_RECOVERABLE_ERROR
Right now, I only implemented the checks for (int), but I add the
parser constructs for (int), (float), (bool), (string) and (object)...
Now, let's talk why I did what I did:
Why did I use cast syntax? Well, there are really three main reasons.
First off, to indicate that a cast may happen. Second, to prevent
needing new tokens (and hence reserved words). And third to provide a
distinction between a string class type hint and a string scalar type
hint.
Why did I only implement (int)? Well, because I just wanted to build
a quick dirty POC that can be executed to see the semantics of
operation. There are issues with it now, so rather than doing all the
work to re-do it later, I just implemented int...
Why implement (object)? Because right now, there's no way to say you
want to accept a generic object without caring about type. So the
(object) cast/hint would then provide that ability to accept a generic
object.
Why not implement (resource)? Because that would require a new parser
token, as it's not available now...
How does the casting work? Right now, it's using a copy of the same
rules that internal functions use with zend_parse_parameters. That
way, it brings the operating semantics of internal functions and
userland functions more inline with each other.
So with that said, there are some (significant) issues with the patch:
1. First off, the arg checks happen before separation of the zval on
non-referenced calls. So that means the cast effects the original
zval AND the argument. Which is a no-go for a production patch. So
that means that the cast logic would need to be put after the zval
split. But we'd still want the checks first, so it's not too
difficult to segregate, just requires deeper changes. It's not
difficult (that I can see yet), just more work... Example of the
problem:
# sapi/cli/php -r 'function foo((int) $bar) { var_dump($bar); } $a =
1; foo($a); var_dump($a);'
int(1)
int(1)
2. Right now, the zend_aprse_arg_impl (
http://lxr.php.net/xref/PHP_5_4/Zend/zend_API.c#zend_parse_arg_impl )
that's used by internal functions is defined as static. So we'd be
copying a lot of the code back and forth. In the production patch,
I'd also want to re-factor that out a bit into either functions or
macros to handle the type conversion and casting in both places. That
way, both systems would behave identical (or as close as possible).
So, with that said, what do you think? Is this something worth
pursuing? Are there any fundamental issues that I'm missing? What
else would we need to cover in a production patch and RFC?
Thanks,
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
Whoops, I linked to the wrong gist... Here's the proper one:
https://gist.github.com/1955338
On Thu, Mar 1, 2012 at 11:32 PM, David Muir davidkm...@gmail.com wrote:
I can't comment on the internal implementation, but I like the use of
the casting syntax. It's not as pretty, but make the intent clear, and
there's not BC issues with class names.
David
On 02/03/12 14:48, Anthony Ferrara wrote:
Hey all,
I know given all the discussion about this topic lately, this is a hot
topic. But I whipped together a quick POC patch to implement scalar
type casting for function parameters. Let me describe it:
Patch: https://gist.github.com/1947259
Example:
function foo( (int) $bar ) {
var_dump($bar);
}
foo(1); // int(1)
foo(1); // int(1)
foo(1.5); // int(1)
foo(foo); // E_RECOVERABLE_ERROR - Expected integer
foo(array()); // E_RECOVERABLE_ERROR
Right now, I only implemented the checks for (int), but I add the
parser constructs for (int), (float), (bool), (string) and (object)...
Now, let's talk why I did what I did:
Why did I use cast syntax? Well, there are really three main reasons.
First off, to indicate that a cast may happen. Second, to prevent
needing new tokens (and hence reserved words). And third to provide a
distinction between a string class type hint and a string scalar type
hint.
Why did I only implement (int)? Well, because I just wanted to build
a quick dirty POC that can be executed to see the semantics of
operation. There are issues with it now, so rather than doing all the
work to re-do it later, I just implemented int...
Why implement (object)? Because right now, there's no way to say you
want to accept a generic object without caring about type. So the
(object) cast/hint would then provide that ability to accept a generic
object.
Why not implement (resource)? Because that would require a new parser
token, as it's not available now...
How does the casting work? Right now, it's using a copy of the same
rules that internal functions use with zend_parse_parameters. That
way, it brings the operating semantics of internal functions and
userland functions more inline with each other.
So with that said, there are some (significant) issues with the patch:
1. First off, the arg checks happen before separation of the zval on
non-referenced calls. So that means the cast effects the original
zval AND the argument. Which is a no-go for a production patch. So
that means that the cast logic would need to be put after the zval
split. But we'd still want the checks first, so it's not too
difficult to segregate, just requires deeper changes. It's not
difficult (that I can see yet), just more work... Example of the
problem:
# sapi/cli/php -r 'function foo((int) $bar) { var_dump($bar); } $a =
1; foo($a); var_dump($a);'
int(1)
int(1)
2. Right now, the zend_aprse_arg_impl (
http://lxr.php.net/xref/PHP_5_4/Zend/zend_API.c#zend_parse_arg_impl )
that's used by internal functions is defined as static. So we'd be
copying a lot of the code back and forth. In the production patch,
I'd also want to re-factor that out a bit into either functions or
macros to handle the type conversion and casting in both places. That
way, both systems would behave identical (or as close as possible).
So, with that said, what do you think? Is this something worth
pursuing? Are there any fundamental issues that I'm missing? What
else would we need to cover in a production patch and RFC?
Thanks,
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
I do like retaining the same functional behavior afforded to internal functions.
Cast syntax seems awkward to me though. Some things that immediately come to
mind:
// ?? lossless, but wrong type. Does this cast or fail?
(function((object)$o){})(array());
// ?? If (object) is allowed, (array) seems like it would be valid too,
// but since it is also different from a straight array type hint, it
// seems like it would do something different. Does this cast or fail?
(function((array)$o){})($object);
Cast syntax differs from documentation meaning the same thing.
Cast syntax may re-open the consistency vs. BC question previously worked out.
John Crenshaw
Priacta, Inc.
On 02/03/12 14:48, Anthony Ferrara wrote:
Hey all,
I know given all the discussion about this topic lately, this is a hot
topic. But I whipped together a quick POC patch to implement scalar
type casting for function parameters. Let me describe it:
Patch: https://gist.github.com/1947259
Example:
function foo( (int) $bar ) {
var_dump($bar);
}
foo(1); // int(1)
foo(1); // int(1)
foo(1.5); // int(1)
foo(foo); // E_RECOVERABLE_ERROR - Expected integer foo(array()); //
E_RECOVERABLE_ERROR
Right now, I only implemented the checks for (int), but I add the
parser constructs for (int), (float), (bool), (string) and (object)...
Now, let's talk why I did what I did:
Why did I use cast syntax? Well, there are really three main reasons.
First off, to indicate that a cast may happen. Second, to prevent
needing new tokens (and hence reserved words). And third to provide a
distinction between a string class type hint and a string scalar type
hint.
Why did I only implement (int)? Well, because I just wanted to build
a quick dirty POC that can be executed to see the semantics of
operation. There are issues with it now, so rather than doing all the
work to re-do it later, I just implemented int...
Why implement (object)? Because right now, there's no way to say you
want to accept a generic object without caring about type. So the
(object) cast/hint would then provide that ability to accept a generic
object.
Why not implement (resource)? Because that would require a new parser
token, as it's not available now...
How does the casting work? Right now, it's using a copy of the same
rules that internal functions use with zend_parse_parameters. That
way, it brings the operating semantics of internal functions and
userland functions more inline with each other.
So with that said, there are some (significant) issues with the patch:
1. First off, the arg checks happen before separation of the zval on
non-referenced calls. So that means the cast effects the original
zval AND the argument. Which is a no-go for a production patch. So
that means that the cast logic would need to be put after the zval
split. But we'd still want the checks first, so it's not too
difficult to segregate, just requires deeper changes. It's not
difficult (that I can see yet), just more work... Example of the
problem:
# sapi/cli/php -r 'function foo((int) $bar) { var_dump($bar); } $a =
1; foo($a); var_dump($a);'
int(1)
int(1)
2. Right now, the zend_aprse_arg_impl (
http://lxr.php.net/xref/PHP_5_4/Zend/zend_API.c#zend_parse_arg_impl )
that's used by internal functions is defined as static. So we'd be
copying a lot of the code back and forth. In the production patch,
I'd also want to re-factor that out a bit into either functions or
macros to handle the type conversion and casting in both places. That
way, both systems would behave identical (or as close as possible).
So, with that said, what do you think? Is this something worth
pursuing? Are there any fundamental issues that I'm missing? What
else would we need to cover in a production patch and RFC?
Thanks,
Anthony
--
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] get_magic_quotes_* != deprecated?
afaict they are not. It was what we agreed on. On Fri, Mar 2, 2012 at 2:56 AM, Philip Olson phi...@roshambo.org wrote: Hello! Please clarify whether or not get_magic_quotes_gpc() and get_magic_quotes_runtime() are deprecated, because I do not think they are. Deprecated means people should not use them while writing new code, but they are perfectly sensible functions. I propose that we do not describe get_magic_quotes_* as deprecated, and that they exist forever, and always return false. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
Anthony Ferrara wrote: foo(1); // int(1) foo(1); // int(1) foo(1.5); // int(1) foo(foo); // E_RECOVERABLE_ERROR - Expected integer foo(array()); // E_RECOVERABLE_ERROR Double-checking, but this is different to normal typecasting, isn't it? If so, it might be a bit confusing using the typecasting syntax. -- Ryan McCue http://ryanmccue.info/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [POC Patch] Scalar Type Hinting/Casting - Proof Of Concept
Ryan McCue wrote: Double-checking, but this is different to normal typecasting, isn't it? If so, it might be a bit confusing using the typecasting syntax. Could have sworn I saw that 123foo would give E_RECOVERABLE_ERROR, but I can't find that now, so possibly disregard this. -- Ryan McCue http://ryanmccue.info/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEADS UP: 5.4 branch is open again
Hi: On 02 Mar 2012, at 01:33, David Soria Parra wrote: just a heads up. The PHP_5_4 branch is open for commits again. Thanks to Stat and you for all the work! When is cycle for 5.4.1 going to start? I got a few traits-related patches waiting for it. Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEADS UP: 5.4 branch is open again
Hi! When is cycle for 5.4.1 going to start? I got a few traits-related patches waiting for it. If you have some fixes, you can commit them now. Of course, the rules are as always in stable branch - no BC breaking, no major features :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
