Re: [PHP-DEV] Cannot call constructor
First, thanks for all the comments! Responding in-line to myself to address everything so far in this thread: On Thu, May 23, 2013 4:24 pm, Richard Lynch wrote: Consider this common scenario: I use some OOP library, that is a black box and I like it that way. This was a made-up scenario. Well, somewhat... In my experience, this sort of thing usually happens in the corporate environment with Jr. Programmer, rather than in publicly-released libraries. Educating Jr. Programmer regarding documentation needs to happen and will happen, but it will probably be out-of-band from using their code. if (method_exists(get_parent_class(), '__construct')) parent::__construct(); 99% of the time, I need to call their constructor before mine to initialize stuff. I'm very pragmatic. If PHP had default __construct, and in the absence of [decent] docs for the parent, I'm going to call the parent constructor first and pray. I thought all PHP user-land class were rooted in stdClass. The class functions that display hierarchy obscure that, but there it's there under the hood. If so, adding the magic anti-pattern methods to stdClass would be easy, right? Extensions that return PHP objects should get the free ride from stdClass, I would expect. The sample init() pattern or whatever from Etienne made my eyes un-focus in the first couple lines. I'm not saying it's not the better pattern, or even that what I propose isn't an anti-pattern. Just it was way too complicated for what I need 99% of the time. I'm sure if I *needed* that particular pattern's properties it would make a whole lot more sense. My thoughts on which magic methods [don't] fit this treatment: DO FIT __construct: 99% I let them init their stuff, and I init mine __destruct: I tear down my stuff, and call the parent __toString: I would imagine children tacking on (actually, I think parent::__toString being safe might be baked in already, as all classes have a toString, right?...) __call*: Parent first, do my stuff, usually return parent result __invoke? Never used it, don't like it, basing on description DO NOT FIT __sleep __wakeup __get __set __isset __set_state Already effectively calls all descendants if the first note is correct... __clone Already has an :after method __done() to deal with this I'm not particularly strongly for or against any of them except __construct __destruct Well, __set_state and __clone pretty much have to be the NOT FIT pile, as far as I can see. Again, I'm VERY pragmatic. The base object having __construct and __destruct so I can call them in FIFO/LIFO order covers 99% of the use cases. If I was writing an RFC today, and I'm not until there is a little more discussion on-list, I would explicitly include only ctor/dtor in it as a trial, and leave the rest for later. Or never if that's the way it pans out. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On Thu, May 23, 2013 3:10 pm, Stas Malyshev wrote: I'm probably not the typical PHP user; I spend 99% of my PHP time using the CLI (and not web SAPIs). This means that I frequently run PHP without an .ini file. As a I'm not sure how this follows - CLI is capable of using ini file just like the rest of SAPIs. Why not create it? The U in UTC *does* stand for Universal, after all. It's a sensible default and as such shouldn't I don't think it's a sensible default - people don't actually use UTC when considering dates. A minority of people can use timezone that coincides with UTC, but not very many use actual UTC. I don't know about everybody else, but if I need a timezone-aware application, I always use GMT/UTC and have I/O routines for user-interface to convert to local for them. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Cannot call constructor
Consider this common scenario:
I use some OOP library, that is a black box and I like it that way.
As part of the integration, I need to extend one of the library's
classes:
class App_bar extends Library_foo{
function __construct(){
//do whatever I need to do here.
}
}
So I write this code, and it works, and I'm happy.
Years go by and new releases of the library come out, steadily
improving features and fixing bugs etc.
But at some point, the library needed a resource in a __construct()
somewhere in the ancestry of Library_foo, to perform something at the
time of construction.
So they re-factored or re-implemented the black box library to have a
constructor in Library_foo class, or any of its numerous ancestors.
Suddenly my code doesn't work. Maybe the resource is only needed under
certain conditions. So their __construct doesn't get called, but
nothing bad happens until the circumstances where they need the
__construct called.
So now I don't just have a bug, I have an intermittent bug.
And as much as we all like to think our testing covers 100% of the
functionality...
I'm tearing my hair out trying to find where things went wrong in code
that worked for years.
Right now, to avoid this situation, you have to do:
if (method_exists(get_parent_class(), '__construct'))
parent::__construct();
If you don't check for the method existing, you get:
Fatal error: Cannot call constructor ...
I don't want to have an intimate knowledge of the internals of the
library; just the documented API. That's one of the major reasons for
using a library.
I would think that as PHP climbs up the chain of extends et al, if
it never found a parent method, if wouldn't complain about it, much
less E_FATAL...
I mean, so you didn't find a method that's not there to find. And I
should call parent::__construct just in case there is one there,
because I don't know, or care, really, how the black box is
implemented. So long as the library does what's on the tin (in the
docs).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Support negative indexes for arrays and strings
On Mon, June 4, 2012 2:08 pm, Marc Easen wrote: I have submitted a patch to support negative indexs in strings, as per the conversation adding them to arrays could possibly detract from the syntactical sugar they are indented to be. In summary: An alternative to: $var = 'abc'; echo $var[strlen($var) - 1]; Can be: $var = 'abc'; echo $var[-1]; This seems simple enough for a hard-coded -1, but... Would $var[-2] be strlen($var) - 2 and so on? And then one would expect some rather complex logic to compute -N for $var[-N] At that point, this becomes a pretty big WTF, imho. I've never honestly felt it to be a big burden to use strlen($var) - 1, so I don't really see the point, at least for me. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Support negative indexes for arrays and strings
On Mon, June 11, 2012 2:13 pm, Stas Malyshev wrote:
And then one would expect some rather complex logic to compute -N
for
$var[-N]
I don't see much of complex logic here, but $a[2] = 'a' would create a
new array element if it does not exist, while $a[-2] can't. Not a big
issue, but somewhat inconsistent I guess.
$n = some_incredibly_long_and_complex_computation();
//and, for real fun, sometimes it returns positive, and sometimes
negative.
$s = $var[$n];
//a few hundred lines later, buried somewhere else
if ($n 0){
//whatever
}
else{
//something entirely different
}
Sooner or later, somebody will do that, and I really don't want to
have to un-tangle all that mess to figure out if $n is positive or
negative for the sake of saving a few keystrokes...
--
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] Question about parser implementation details
On Sun, April 1, 2012 7:19 am, Florian Anderiasch wrote: I'd appreciate any hints on how to tackle this serious concern. If this actually wasn't an April Fool's joke... Never ignore the user contributed notes after doing a search like: http://php.net/roman http://us3.php.net/manual/en/function.base-convert.php#105414 Those notes may be 90% [bleep], but there are always hidden gems in some of them :-) Actually, even if it WAS an April Fool's joke, my second sentence still has merit. Sorry to reply so late, but nobody who took it seriously pointed this one out... PS No idea what spqr is, but 0r would probably be more appropriate. -- 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] Re: [VOTE] Vote change for empty() RFC
On Sun, May 20, 2012 5:44 pm, Pierre Joye wrote: On Sun, May 20, 2012 at 11:03 PM, Rafael Dohms lis...@rafaeldohms.com.br wrote: On Mon, May 14, 2012 at 1:16 PM, Anthony Ferrara ircmax...@gmail.com wrote: I had meant to reply to the list, but I had replied to Stas directly. I would be happy to change my vote from isset() and empty() to empty() only if that's what it would take... Anthony This would settle it, so in the realm of action what can we do now? Is there a rule that allows to call for a re-vote? Should start a new RFC? Or can we just alter the vote and consider this the end of voting? Sorry, but all this talking is running around in circles, and everything has been said. I would like to bring closure to this topic. See the previous mails, as long as other voters agree to change their votes to empty only, we are done. I had voted none. I really don't care about empty, because it has changed edge cases in every major release, so I can't use it. Therefore and herewith, I officially change my none vote to empty only Please put a fork in it and call it done. -- 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] 2/3 = ??? Re: [PHP-DEV] [VOTE] Vote change for empty() RFC
On Mon, May 21, 2012 5:22 pm, Sanford Whiteman wrote: Ah, this is why one should trust a coder over a butler: http://www.ask.com/answers/112530521/5-people-are-voting-what-is-2-3-s-of-a-majority Regarding the 2/3 super-majority rule... I thought I'd check the non-authorative but always interesting wikipedia article... Apparently, we are not the only ones confused by edge cases: http://en.wikipedia.org/wiki/Supermajority -- 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 interpreter
On Wed, May 9, 2012 5:05 pm, Xin Tong wrote:
I am new to php runtime. i am doing some research on runtime
interpreter. can anyone please tell me where the interpreter of the
php runtime is ? which file ? and does the php runtime has a JIT
compiler ?
I believe the interpreter is built out of bison/yacc files, so you
could start with those to find out where they put it.
The php runtime is a JIT parser/compiler to a bytecode, which is then
run by the Zend Engine (see above).
Actually, that last statement might imply the the zend directory would
also be a good place to look.
Finally, it should be noted that APC and other caching mechanisms save
a great deal of time by not hitting the disk to load the script, but
keeping it in RAM, if possible.
As gravy on top of that, the bytecode is saved in cache instead of
source, so it is not a JIT if one of those caches is in use.
Psuedo code to describe the difference the APC (or other cache) makes:
//save hitting the hard disk
if ( $source_code = in_cache($path)){
}
else{
//super-duper slow!!!
$source_code = file_get_contents($path);
}
$bytecode = zend_parse($source_code);
zend_execute($bytecode);
//save hitting the hard disk
//and a small bonus, cache the bytecode, not source:
if ($bytecode = in_cache($path)){
//do nothing
}
else{
$source_code = file_get_contents($path);
$bytecode = zend_parse($source_code);
}
zend_execute($bytecode);
The savings from parsing is chump change compared to disk I/O.
It's also trivial chump change to implement.
Ever ounce counts :-)
--
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] 2/3 = ??? Re: [PHP-DEV] [VOTE] Vote change for empty() RFC
On Tue, May 22, 2012 1:51 pm, Sanford Whiteman wrote: Apparently, we are not the only ones confused by edge cases: http://en.wikipedia.org/wiki/Supermajority Can you point to where there's any suggestion of using the ceiling (rounding up) instead of requiring whole persons? In fact, the Wikipedia page matter-of-factly says ...two thirds (currently 34) of the states I should have been more clear: Whether that article addresses rounding up, down or sideways, it's an awfully long article for what should be a fairly simple thing... I know I started zoning out long before the halfway mark. I certainly didn't do the math for every example from every country/quorum/entity... Actually, if we used the abstain == no logic of some bodies, I don't think any of our RFCs would pass :-) -- 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] Catchable - marking methods just like static?
On Tue, April 3, 2012 9:02 pm, Alan Knowles wrote: I just saw Daniel changing some of the PEAR classes to use Exceptions, and it's pretty clear that this could cause havoc with the end users. The problem being that there is no 'soft' landing for the migration process. If I understand set_exception_handler correctly, you could simply make anything that reaches that state simply not return at all, and exit. If you are that serious about the problem, the code expecting a result and not an exception won't get anything at all. And code with proper exception handling will do the right thing, assuming you have written all your exception handlers at every layer correctly. Personally, try/catch and throw always felt like GOTO to me, and the larger the codebase, the harder I found it to track down who was the thrower and who was the catcher. Reminded me of the old Abbot and Costello baseball routine. -- 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] Persist context across threads?
On Mon, May 14, 2012 1:47 pm, David Rueter wrote: I am interested in preserving the complete PHP context for a thread (globals, variables, interpreter, etc.--everything) for later access from a different thread. What would be involved in this? It seems like: 1) Avoid calling ts_free_thread 2) Call tsrm_set_interpreter_context from new thread Is it safe to assume that the context of a terminated thread will not be destroyed or overwritten as long as ts_free_thread is not called? I don't really know what I'm talking about, but nobody has answered yet... For starters, not all extensions are thread-safe. I would expect that to mean that anything actively using those extensions saved state in another thread is a segfault waiting to happen. For security reasons and sheer plain cussedness, I don't think you're going want and/or get any resource (mysql connection/result/etc, gd images, file handles, etc) survive to the next thread. A mysql connection, for example, is opened with a specific user/pass. Another thread picking this up could probably abuse that, as I understand it. Finally, your question begs another question: Why do you want to do this? -- 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] memory usage ouchy
No offense intended, but if you've got so many OOP objects flying around that they are sucking down that much memory... You probably need to refactor your code and just don't do that Just my opinion. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Allow non-variable arguments to empty() and isset()
On Fri, May 4, 2012 2:10 pm, Kris Craig wrote: On Fri, May 4, 2012 at 11:48 AM, Richard Lynch c...@l-i-e.com wrote: On Wed, May 2, 2012 4:43 am, Pierre Joye wrote: empty() on the other hand, tests if something is empty, and only if it is empty. The result of an expression can be empty. an expression can also have a value of null. And NULL is empty. No issue here. Expressions can also return , 0, 0.0, 0, array() You really think those should all be empty? Unless I'm missing something here, aren't all those things already considered to be empty?? Here's what the PHP man page for empty() says: The following things are considered to be empty: - ** (an empty string) - *0* (0 as an integer) - *0.0* (0 as a float) - *0* (0 as a string) - *NULL* - *FALSE* - *array()* (an empty array) - *var $var;* (a variable declared, but without a value in a class) I am suggesting that some of those wouldn't make so much sense being empty in an expression. empty(2.0 - 1.9); Might not be 0.0, but that's not the point. For some not-empty values added or subtracted, more or less at the whims of digital float behave would or wouldn't be empty. Furthermore, empty on 0 was originally designed user input via GET/POST so that an option0/option would be empty() -- 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 -- 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 extension versions
I'm terribly sorry, but I managed to delete the original while running through the thread to be sure I didn't duplicate comments, and my mailer won't let me respond to a deleted message. So this will appear as a new thread. #1 A standard for non-core extension version fields is a great idea. But if all the core ones are PHP_VERSION, you might as well suppress it completely, as there's not much point in checking it. #2 The curl version is in an Information field. The original poster may wish to maintain a list of which extensions have version information in which fields for now. #3 It wasn't 100% clear when I read it, but I presume the non-core extensions wouldn't have all their versions set to PHP_VERSION. That would make the whole thing completely useless... -- 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] Re: internals Digest 18 Apr 2012 20:34:27 -0000 Issue 2671
On Wed, April 18, 2012 9:42 pm, Rasmus Schultz wrote: On 04/10/2012 06:20 PM, Adir Kuhn wrote: PHP Gotchas, how they came to be, and why we can't simply fix them can't or won't? It seems that the requirement for backward compatibility, as with most software, stands in the way of any substantial leaps, and makes it impossible to do away with outdated cruft. As a result, PHP is dragging around a lot of baggage - both the language itself and the libraries. Hey, here's a crazy thought: ?php6 Now you don't have to be backward compatible - the bytecode needs to remain compatible with bytecode generated by standard ?php tags of course, but you're free to change/improve/deprecate/extend the syntax, update inconsistent APIs, etc. I know this is no small thing, heh. I'm sure there's some technical reason this isn't even feasible or possible... I just figured I'd bring it up anyway, it's always fun to see your reactions to such radical ideas - bring on the flames! ;-) Using the Duck Rule, this seems the same as a php.ini switch for core PHP. We all know how that one worked out... -- 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] Allow non-variable arguments to empty()
On Thu, April 12, 2012 6:05 pm, Johannes Schlüter wrote:
On Wed, 2012-04-11 at 00:53 +0200, Nikita Popov wrote:
Currently the empty() language construct only works on variables.
You
can write if (empty($array)) but not empty if
(empty(getSomeArray()).
I've mentioned this thought off-list already but let's discuss it
officially:
A fear I have is that this makes empty more looking like a function,
while not being one. Right now one notices quite quickly that it is
something else. Things like $check = $condition ? empty : isset;
$check($bar); trigger an even more confusing error (Call to undefined
function)
I'm not sure whether that's a strong argument, but I guess it's good
enough to be noted :-)
If one doesn't know isset/empty aren't functions, one doesn't
understand their purpose nor how variables are used/scoped.
If one doesn't know these things, one should learn. Quickly.
Call to undefined function is exactly correct.
$a = 5;
$b = 3;
$foo = 'if';
$foo ($a == $b){
echo Nope.;
}
While it might be as nifty as runkit to do this, it should not be
encouraged. Or even allowed.
--
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] Allow non-variable arguments to empty()
On Tue, April 10, 2012 5:53 pm, Nikita Popov wrote: Another reason is that currently you get a very obscure error message if you try to use empty() on a function return value: Can't use function return value in write context. Aha. Where did I try to write to the return value?! On the line number indicated in the message :-) More seriously, if the guts of PHP can easily detect when you are not really write context versus this, just fix the error message to something more meaningful. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Optional PHP tags by php.ini and CLI options (Ver. 1.4)
On Wed, April 11, 2012 5:14 pm, Yasuo Ohgaki wrote: I think my RFC confused people on this list due to improper descriptions and too much information. Sorry for the confusion. I revised the RFC so that most important points can be understood at a glance. https://wiki.php.net/rfc/nophptags We all know there are a LOT of bad scripts out there. A *LOT* of bad scripts. With major security holes in them. I do not see your average PHP scripter changing that behavior: It's just so easy to write a PHP script, which is why it's so popular. Now, you are going to open up all the inexperienced scripters to code exposure when they start using this cool new feature of being lazy and not typing that silly ?php tag. And that code being exposed will have major security holes in it. This is just not a good idea... Instead of random bots attacking random URLs hoping to hit pay dirt for an SQL injection, you will have bots that: Use google to find stuff that looks like raw PHP code. Scape page to look for mysql.*$_POST Attack site. Unless I'm really missing something here, you put a few million people's code at risk, for a feature that has dubious value in the first place. -- 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] [off] PHP: a fractal of bad design
On Tue, April 10, 2012 1:27 pm, Stas Malyshev wrote:
Hi!
Scroll down a bit; he gets into valid points about the == operator,
for instance. It's not a useless post. He does cite too many things
that he has to follow up himself by saying this was fixed in PHP
5.x.y. If it was fixed, why is it on your laundry list still?
What exactly valid points? == is a converting operator, === is a
strict
operator. OK, in his favorite language it is not. Where exactly the
valid point is? Author goes at great lengths to refuse to make even a
slight mental effort to understand how it works (really, it's not that
hard) and then complains it's useless. Well, a lot of things would
be
useless if you don't want to know how to use them.
He has a few valid points in the part I read before I got bored...
$a = 123ABF453...; //a password
$b = 123DFEABC...; //another one
if ($a == $b){
//you're in.
}
Yes, one should have validated the input...
But you don't have to be THAT naive to think that the hashed value of
an SQL injection attack just isn't going to work, so it's safe...
I'll bet I have some of these in my (recent) code, for that matter.
On the other hand, if you accept type juggling, you have to expect the
other cases he has for == being a bit strange.
--
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] JPEG Upload
On Tue, April 10, 2012 1:13 pm, John Crenshaw wrote: In most systems you can upload *anything* with a .jpg extension and the app will take it, so you can still include the file People don't use imagecreatefromjpeg() to be sure it isn't some ware or executable or PHP script disguised as a JPEG?! That's just crazy. And inexcusable in a framework. Somebody might be able to craft a JPEG that validates and still manages to somehow parse some PHP in the middle... Probably using JPEG comments so it's easier. But on should at least you'd have some kind of validation on user input! -- 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] Re: Disabling PHP tags by php.ini and CLI options
On Wed, April 11, 2012 12:25 am, Stas Malyshev wrote:
Hi!
I'm sure you have seen the same code in JSON hijack countermeasure.
while(1){}
I think you misunderstood what I means. What I meant is you can inject
code without ? the same way you can inject code with ?, so where's
the
improvement?
kill() function would be just an example of code being injected by
hostile third party (intent on killing your server, presumably). If I
can inject it with ?, what prevents me from injecting without ? ?
Actually, it makes it worse.
I can search for '?php' (no short open tags) or '?=' and reject
without the new feature.
Without the new feature, no easy way to detect it contains PHP code.
--
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] Education
[soapbox] Several people in at least one thread (I can't remember) have stated: Education won't work. I must take objection to that. Not too long ago, a large number of people on this very list agreed that SQL Injection was a Big Problem, and if they all blogged about it, awareness would help. And so it was. Did it stop SQL injection completely? No. Did it make a serious dent? YES! Never underestimate the power of injection. Nor your collective power here to make a concerted effort to educate with tremendous succes. [/soapbox] -- 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] release process with git
On Tue, April 17, 2012 3:34 am, Martin Jansen wrote: On 17.04.12 10:24, Bas van Beek wrote: Sounds like facilitating wrong security protocols to me. In this 365/24/7 environment, sysadmins should be willing and able to patch, fix and secure systems at any time. Weekend should be no excuse. Willing to? Yes. Happy about it? No. Deciding PHP is a PITA because it keeps making them work on weekends? Bad Idea. -- 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] JPEG Upload
On Sat, May 5, 2012 12:29 pm, Ferenc Kovacs wrote: On Sat, May 5, 2012 at 6:32 PM, Richard Lynch c...@l-i-e.com wrote: On Tue, April 10, 2012 1:13 pm, John Crenshaw wrote: In most systems you can upload *anything* with a .jpg extension and the app will take it, so you can still include the file People don't use imagecreatefromjpeg() to be sure it isn't some ware or executable or PHP script disguised as a JPEG?! That's just crazy. And inexcusable in a framework. Somebody might be able to craft a JPEG that validates and still manages to somehow parse some PHP in the middle... Probably using JPEG comments so it's easier. yeah, and injecting php code through the jpeg comments isn't new also, see http://ha.ckers.org/blog/20070604/passing-malicious-php-through-getimagesize/ but I bet I could find even older posts discussing the topic. so imo the correct remedy for this situation is to prevent your uploaded files to be executed at the first place, instead of trying to write an error-prone method to detect malicious content inside your uploaded media files. getImageSize is not better than file Info... If the whole thing parses as an image with imagecreatefromjpeg() I should think that's a bit tougher to create a hack that works. Then one can strip off the exif info with the comments, I believe. And, yes, ideally one would keep images in a totally separate directory not even in the webtree... Which I do, but some folks can bear the cost of passing the image through PHP. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] JPEG Upload
On Sat, May 5, 2012 1:52 pm, Ángel González wrote: I never said it was an iron-clad technique. Only that it would be harder to craft such an image. If your TOU that meta-data gets stripped, so be it. Or find a way to have (some of) your users have some level of trust. To: Tom (?) One doesn't always control one's apache config. Shared hosting, corporate environment with an inexperienced sysadmin, etc. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Allow non-variable arguments to empty() and isset()
On Wed, May 2, 2012 4:43 am, Pierre Joye wrote: empty() on the other hand, tests if something is empty, and only if it is empty. The result of an expression can be empty. an expression can also have a value of null. And NULL is empty. No issue here. Expressions can also return , 0, 0.0, 0, array() You really think those should all be empty? Or you want different behavior for expressions vs variables. I'm assuming virtually everybody would agree THAT is unacceptable... Or are the rules for what is or isn't empty going to also change. Again. -- 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] considering to remove ext/imap from master
On Fri, April 27, 2012 1:51 pm, Pierre Joye wrote: hi! On Fri, Apr 27, 2012 at 8:40 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Alternative means rewriting all the code. On top of framework previously not used in the project, with different APIs, different approach to IMAP, etc. This is a large piece of work, for many projects - totally unnecessary as ext/imap work for them right now. I think you over estimate the complexity to move something to a clean, maintained, user friendly API from a over complex, buggy and unmaintained extension and library (which can kill requests under certain circumstances too). I think you are over-estimating my bandwidth to take on such a task. :-) That provided the person in question actually owns the code, not just runs the app. In the latter case he has no options to upgrade at all. Again, 2015! That's not now, not tomorrow but 2015! I have an imap script running server-side to filter my email and knock out a whole bunch of spam that SpamAssasin doesn't catch. It's been running in a cron job since at least July 15, 2004 That's just the earliest mod-time file I can find in the directory... It's been running longer than that, actually. I set it up when Eudora was taking too long to download my email. And Eudora was free. And ad-free. So that's probably pre-2003, if I'm reading Wikipedia correctly. I add a new folder and edit the script or set up an alias and edit the script or find a new annoying pattern and edit the script... It's currently at 1065 lines of code, most of which are mailbox filtering or patterns to kill spam. It's been working fine for 8 years. I don't really care if it dies in any given run. It's going to run again in 10 minutes anyway. I dunno what 8 years time 10 minutes is, but that's an awful lot of times it worked just fine. I don't have time to change it, it's running all on an internal network at my webhost, so security is not a real concern. I'd have to plead No -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] skipping optional parameters
On Tue, April 17, 2012 6:23 pm, Jordi Boggiano wrote: On 18.04.2012 00:54, Stas Malyshev wrote: One of the annoying things I've encountered in working with PHP was dealing with functions having long optional parameter lists, especially if you need to change only the last one - you have to copy all the defaults. Full named params implementation would solve it, probably, but before we have that here's an easier solution for part of the problem: https://wiki.php.net/rfc/skipparams Basically, it allows you to do this: create_query(deleted=0, name,,, /*report_errors*/ true); It might be worth mentioning in the docs edge cases like strtok. As you all know, I presume, the optional first param restarts parsing with a new string. When there is only one param, it continues parsing the previous first argument. As silly as this may seem to you experts, newbies will probably be confused by the optional argument syntax versus functions that change the parameter position... -- 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] Ability to assign new object to a class property.
On Sun, April 15, 2012 5:47 pm, Simon Schick wrote:
Just to add a random thought
When do you expect this code to be executed?
class Foo {
static public $foo = new StdClass();
}
I may be too late to this party, but...
For what it's worth, if the non-scalar initialization in class
definition were to be implemented, I, the naive PHP developer, would
expect the implementation to execute the new StdClass() exactly once
(either at compile time or on the instantiation of the first instance)
and Foo::$foo or whatever it is would be static in the sense that the
same instance of a stdClass would be shared by all Foo instances.
I'm with Stas on this one though.
Yes, it would be nifty syntactic sugar, and I used to yearn for it.
But complex initializations in the constructor is something I've grown
used to, and now appreciate as a Feature.
Trying to find all the little bits and pieces of non-scalar
initializations up and down the chain of a complex class hierarchy is
already difficult enough.
Tossing in a bunch more places it can happen is Not Good (tm).
--
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] TSRMLS_* keywords in PHP source
On Mon, March 19, 2012 2:45 pm, Barbu Paul Gheorghe wrote: What role does the keywords TSRMLS_CC, TSRMLS_DC, TSRMLS_D have when passed along with a argument in PHP's source? For example in this random file: http://lxr.php.net/opengrok/xref/PHP_5_4/ext/intl/formatter/formatter_data.c I don't even know if keyword is the right technical term for it because it's the first time I see this kind of call in C: It's a macro. You can find it in the zend / tsrm files. If I recall correctly the _CC and _DC and _D have to do with whether you need a comma (,) after the macro or not... It's been awhile, so don't quote me on that. -- 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] PHP5.4 'nannying'
On Sun, March 18, 2012 6:35 am, Reindl Harald wrote: Am 18.03.2012 10:14, schrieb Lester Caine: I think what I am probably looking for is a clean guide as to how code SHOULD be written nowadays in order to avoid the nanny messages since it's certainly not my normal practice after 10 years of coding in PHP5 ... I once worked with a team that didn't believe in E_NOTICE... I turned it on, and flooded the logs on a shard DEV. I turned it off. Copied the source to my own box, ran it with E_NOTICE, did some grep/sed/awk mumbo-jumbo to find the most common messages, fixed those, and committed them. And found, corrected, and closed about 5 long-standing bugs in the process. They started to think maybe I was on to something here... :-) We turned E_NOTICE back on at that point, as it was only an odd script once in a while that went to the logs. Or new code from that one guy who still didn't quite get it for awhile... He came around after we fixed a couple of his newly-introduced bugs that were triggering E_NOTICE... -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] i hope using set_exception_handler and set_error_handler in php extension code.
On Fri, March 16, 2012 8:33 pm, langwan wrote:
i hope using set_exception_handler and set_error_handler in php
extension
code.
hi, all:
i write php monitor extension now.
1. question
i hope using set_exception_handler or set_error_handler in
PHP_RINIT_FUNCTION()
for example:
PHP_RINIT_FUNCTION(my)
{
set_exception_handler(my_exception_handler);
}
please help me.
You need to separate PHP userland functions (http://php.net/) from C
functions in core/extensions (http://lxr.php.net/)
Find the C source for PHP set_exception_handler in LXR, and see what
it calls. Then call the same thing.
2. question
i hope print $e-getMessage() info in
PHP_FUNCTION(my_exception_handler).
You'll have to find the Exception structure somewhere in the guts of
try/catch implementation, probably tied to the yacc (bison?) (I
forget) code that gets turned into the basic syntax.
There should be some kind of base Exception struct somewhere in there,
that will probably have a message element.
You're trying to write an extension in C. You'll have to find the
underlying C function for any PHP function, and figure out enough
about how it works to re-tool it to your needs.
Hope that helps.
PS
I am *so* not an expert, but I stumbled my way through writing a
sample extension once.
--
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] Small question about performance
On Thu, March 15, 2012 9:21 am, Klaus Silveira wrote:
Hello internals,
I've been involved in a discussion at the PHP Standards Group and we
recently had the following statement:
*Say you had a loop, and inside that loop you wanted to modify a param
**update the key:**
**foreach($a as $key = $val) {
** $a[$key] = someLong(functionCalls(hereThat($spanOver85Chars)));
**}**
**If this exceeded the line width, you would have to split things
like
**this over a few lines, storing the val temporarily in a zval's
until
**you reached your end computation. Therefore allocating more memory
**iteratively. *
I'm curious about this. Can anyone confirm it or a benchmark should be
made?
I don't see why your standard can't allow for:
$a[$key] =
someLong(
functionCalls(
hereThat(
$spanOver85Chars
) ) );
Some folks insist that the closing parens be on separate lines.
They're isomorphic to me, so I just put them on one line.
So long as the count matches and they line up in reverse order,
indented properly, it's all good.
But then, I cut my teeth on Lisp, where a zillion parens to close off
almost anything is the norm. :-)
PS
If you want a benchmark for how much 3 or 4 temporary zvals takes,
knock yourself out.
Also consider trying this in a second benchmark:
//don't create / destroy zvals in the loop, hopefully
$someLong = '';
$functionCalls = '';
$hereThat = '';
foreach ($a as $key = $value){
...
}
PPS
I'm assuming $a is not within the Coding Standard :-)
--
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] set the PHP_INI_ENTRY_* values the same as for php.ini-production
On Wed, March 14, 2012 12:09 pm, Ferenc Kovacs wrote: On Mon, Jul 25, 2011 at 12:34 PM, Richard Quadling rquadl...@gmail.comwrote: On 23 July 2011 23:29, Ferenc Kovacs tyr...@gmail.com wrote: I would propose that the defaul values(PHP_INI_ENTRY_*) and the php.ini-production should be keep in sync as much as possible. I'm +1 if only for the fact that I wouldn't have to research what's different and re-write my (stupid) RFC about E_ALL being the default in PHP_INI_ENTRY* ... I have always presumed that PHP_INI_ENTRY* matched at least one of the two php.ini-* files shipped, actually. Guess that was naive, but it USED to be that way, back in the day, as far as I know... So in terms of expected behavior this can almost be considered a break in BC... -- 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] Let parse_str() parse more than max_input_vars args
On Thu, March 15, 2012 5:01 am, Ryan McCue wrote: I'm not arguing that it should, I'm saying that in the INI it refers to the HTTP arguments, while in the code (via ini_set) it would not affect this. I think that could be confusing for users who don't realise the script is only loaded after parsing the request. If they don't know it by the time they need parse_str, it's time for them to learn it... :-) Not saying it won't cause confusion: But they have to make some effort to figure out how PHP works. Maybe a link in the error message to something that documents the workflow clearly enough that they get it just by clicking on the link and reading? -- 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] default charset confusion
On Mon, March 12, 2012 2:44 pm, Rasmus Lerdorf wrote: But you can't necessarily hardcode the encoding if you are writing portable code. That's a bit like hardcoding a timezone. In order to write portable code you need to give people the ability to localize it. If you wanted it portable, wouldn't you need to have a variable there, so it can survive the ISO-8859-1 to UTF-8 change, and to allow people to change it despite whatever non-standard setting might happen to be in somebody else's php.ini? I mean, sure, it's nice if it just works for the folks who want to install and have it localized for their own charset hard-coded in php.ini, but if it's being multi-national website, you have to pass in a variable there, which seems the more portable option to this naive reader. Having it default to whatever happens to be in php.ini only solves the use case of people who only want to serve up their content in their own charset. I'd have to agree with Stas that everybody should start passing in a variable there, that can be set somewhere in a config, or, perhaps, would DEFAULT to, e... You can't default to a function call. ANOTHER magic constant like __INI_CHARSET__ ??? That's probably a bad idea... -- 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] Re: Git Migration: Status Update
On Wed, March 7, 2012 1:51 pm, Sebastian Bergmann wrote: Am 07.03.2012 19:46, schrieb Kris Craig: As I and others have said already, using a Subversion branching model on Git just doesn't make any sense. How often does it have to be explained to you and others that we would like to do this step by step? First we change the tool, then we change the process. Shouldn't be too hard to understand ... Maybe it's just me, but if I told my boss we were going to change the tool and decide and document the fundamental business processes later, I don't think that would float... That said, I still can't get my head around Git at all, and so far have only managed to checkout/update on a read-only basis. Not that it matters. My code contributions to PHP have been nil so far anyway. -- 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] HEADS UP: 5.4 branch is open again
On Fri, March 2, 2012 4:26 am, Ferenc Kovacs wrote: If we can agree upon the next version number beforehand, and we decide that we will go with the major release (be that php 6 or 7, whatever), we don't to do anything right now, we can branch the version from trunk/master, when the time comes. If we can't agree upon the next version number, or we agree upon that there will be an 5.5 version, I think it would make sense to create a branch for it ASAP, so there is place (trunk/master) for the approved but backward incompatible changes, and people don't have to hold patches. What do you think? If I was in charge, and thankfully I'm not, I'd just create 5.5 and 6.0 If you have patches that don't break BC, put them in both. If you're too busy to do both, put it in 6.0 Somebody will back-port or not, based on their relative need/availability or not. If it breaks BC, put it in 6.0 Or perhaps I misunderstand the tiny bit I thought I got it of the point of using Git in the first place... Branches and merges are supposed to be seamless, right??? -- 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] default charset confusion
On Mon, March 12, 2012 1:49 am, Rasmus Lerdorf wrote: What we really need is what we added in PHP 6. A runtime encoding ini setting that is distinct from the output charset which we can use here. The usual argument against another php.ini setting, other than too many already is the difficulty it presents to write portable code libraries. I'm not smart enough to predict how such a setting (regardless of its name) would help or hinder a library of code that doesn't want another conditional in a zillion places. But you folks are that smart. :-) And I haven't seen any discussion regarding this sub-issue. So, how would the help / hinder authors of generic library code to be distributed in the wild? Forgive me if the answer is so blindingly obvious I should already know it... :-) -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CURL file posting
On Sun, March 11, 2012 6:29 pm, Stas Malyshev wrote: Hi! I'd sure like a PHP extension that didn't have this obvious and nasty bug: https://bugs.php.net/bug.php?id=46439 This doesn't look good. Documentation does say the @ prefix exists, but it has very high potential of creating security holes for unsuspecting people. open_basedir would help limit the impact, but still it's not a good thing. Any ideas on fixing it without breaking the BC? Ouch. Issue an E_NOTICE when it happens? Add a new CURLOPT_FILEFIELDS that takes an array of the parameters that are supposed to be files, so the ones that are expected to have @... do not fire the E_NOTICE. Issuing E_NOTICE is a BC, I suppose, but you'd think people would appreciate an alert about a potential security threat... -- 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] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
On Fri, March 9, 2012 2:51 am, Nikita Popov wrote: On Fri, Mar 9, 2012 at 3:58 AM, Ilia Alshanetsky i...@prohost.org wrote: Anthony, My concern with this type of patch is that what you are proposing are not really hints, they are forced casts. As such they modify the data potentially leading to data loss. This patch specifically tries to overcome this problem of the previous version. It will not accept input which will lead to a data loss on cast. The only exception is passing 123abc to an int hint, which will cast to 123 and throw a notice. This is also my only point of critique: I'd prefer to be stricter here and go all the way to a recoverable fatal error. So what happens to (int) 1233553463645747675685685 Does it cast and then cause an overflow, which PHP pretty much ignores and wraps to a negative number? Or does it error out as you can't convert without mangling the data? Will it behave differently on 32-bit versus 64-bit hardware for values that are in-range of 64 but no 32? -- 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] [POC - Patch] Scalar Type Hinting - A-La zend_parse_parameters
On Fri, March 9, 2012 5:58 pm, John Crenshaw wrote: The reason you have to validate the input type in this case is because even though it is a reference, we don't ACTALLY know that it isn't supposed to contain an input (even though that would be against all sane rules most of the time). Last time I checked, two consecutive exec calls with the same second argument would append to the array of outputs. Hey, it's even documented that way: http://www.php.net/manual/en/function.exec.php It was unexpected when I first saw it, but seemed perfectly sane to me, as I suppose somebody might want it, and unset($output); wasn't exactly horrible to add before each exec call. It would be wise to check other PHP function with references returned to sanity check your definition of sane :-) -- 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] any blogs?
I can't recommend any blogs, per se, but Sara's book or even her articles on Zend.com as well as the php.net manual about internals at the end are a must read for understanding the internals... On Thu, March 8, 2012 6:22 am, adit adit wrote: Let's try to stick only to the internals blogs, ok? If any other php core devs have some blogs.. I found also Sara Golemon's blog but is discontinued for some years now. On Thu, Mar 8, 2012 at 1:09 PM, Peter Beverloo pe...@lvp-media.com wrote: There is a Planet PHP which aggregates many blogs articles written by contributors: http://planet-php.net/ Peter On Thu, Mar 8, 2012 at 09:58, adit adit miche...@gmail.com wrote: Hi, Can you tell me which one of you guys has any blogs on which i can read about the php internals? I've already subscribed to laruence's , problem is google translate is pretty bad at translating chinese 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] Scalar Type Hinting
On Thu, March 8, 2012 5:13 am, Alain Williams wrote: On Thu, Mar 08, 2012 at 11:06:56AM +0200, Arvids Godjuks wrote: Type hints are meant to filter input from external sources Correction, it should read like this: Type hints are _not_ meant to filter input from external sources +1 What they will do is to catch where input from external sources has NOT been correctly filtered -- but that should be a rare event and indicative of a bug. While everybody here routinely filters all input, you're living in a dream world if you think un-filtered data is a rare event. It's still a bug, but definitely not rare. Or perhaps you meant that should be a rare event if we want all PHP apps to be well-written rather than that should be a rare event in terms of BC -- 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] Providing sandboxed versions of include and require language constructs
On Tue, March 6, 2012 3:30 am, Florian Anderiasch wrote: Security by blacklist almost always isn't security... You're bound to miss one of the functions you should have blacklisted, but didn't. Something like Drupal would be crippled by this because major extensions used by all rely on access that would probably want to be blocked. So then they'd have to come up with a blessed list of extension to not block, and then... Nice idea, in the abstract, but I don't think it will work out to be very useful in the Real World (tm). -- 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] 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
Re: [PHP-DEV] [Draft RFC] Object Casting and Assignment Handlers
On Tue, February 28, 2012 8:40 pm, Anthony Ferrara wrote: https://wiki.php.net/rfc/object_cast_magic Suggestion: Rename __castTo as __castObject, to be parallel to engine Question: Is there no need to implement the get() function in userland? It feels wrong for 1/3 to be missing, but I probably just don't get it The const example seems quite contrived, given that a) it's allowed to be unset() and b) PHP has define() I believe that particular example weakens the RFC rather than strengthens it. Re: your conversation with Stas: I have to agree with Stas. In short, there is complexity and complexity squared and this just seems like complexity squared for a handful of edge cases that only provides syntactic sugar / less typing versus a new feature that is needed to achieve a goal that currently can't be done. If it made it possible to achieve the impossible, or even just simplified your code without such a wide scope for abuse by people who only think they know what they are doing... -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
On Tue, February 28, 2012 5:17 pm, Kris Craig wrote: Some cases I would find interesting to be explained: (using 'streak' for strong and/or weak, feel free to separate the two) streak int $i = 123.456; //Common idiom for floor() streak int $i = 123.456; //In contrast to previous streak int $i = 1 ; //value=1 is ridiculously common HTML It's all well and good to say that any loss of data is bad and to raise some E_* for it, but there are some idioms so common that feel wrong as I consider them... If everyone for the new type hinting/forcing can reach consensus on these sorts of cases, it would help clarify any RFCs a bit, I think wrt E_RECOVERABLE_ERROR vs E_WARNING If current type hinting raises E_RECOVERABLE_ERROR, I have no objection to following that lead, with the explicit caveat that a change to the existing type-hinting to E_WARNING, as unlikely as that seems, would pull the new streak with it. I don't even object to using E_ERROR for the strong variant, if that passes review, really, since strong is, errr, strong. :-) Anybody who doesn't like the E_* can re-define them in a custom error handler anyway, though allowing PHP to continue after E_ERROR is like playing russian roulette... -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
On Wed, February 29, 2012 6:55 pm, Kris Craig wrote: If not, I'll go ahead and draft an RFC for these proposed amendments sometime today or tomorrow when I get a spare moment. If anyone has any thoughts on this, please share them! Thanks! This is not an official answer. I don't have time to dig out references. I believe the PHP community settled on the idea of having a single simple pass / fail vote without the complexity of branches / options. It was simply to hard to tally the votes once you open up the options, because your support base ends up being split. NOTE: See current US Republican Primaries for examples of how complex it gets. :-) There is nothing to stop one from drafting multiple proposals, with alternative options, and each one getting vote upon, other than the time available to the person drafting the proposals. And, of course, a reasonable expectation that with TOO many proposals of the same idea, the community would quickly turn into robo-voting, both for and against, as that's just human nature. Again, I say, I don't claim to speak for the whole community. This is merely my interpretation from my faulty memory of past events. -- 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 Philosophy (was RE: [PHP-DEV] Scalar type hinting)
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
Re: [PHP-DEV] Possibility to add finally to try/catch?
https://bugs.php.net/bug.php?id=36779 Not to say that finally shouldn't be added, but I don't think this lock inside a loop is a particularly compelling example... Either that loop is going to wait a whole lot for an exclusive lock at every iteration, or the locks aren't exclusive and could be more easily built up in an array and disposed of after the loop. Of course, for now, we have GOTO which might be of use in these situations. :-) Though I'm not sure you could effectively manage the (constrained to make wanton usage difficult) GOTO statements and targets if you need this a lot. -- 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] Possibility to add finally to try/catch?
On Tue, February 28, 2012 8:22 am, Kiall Mac Innes wrote:
+1000
This is a feature that I've always wanted in PHP, My main reason being
to
reduce code duplication. eg
try {
$fh = fopen($filename);
// Do some work on the file + encounter an error.
throw new Exception();
} catch (Exception $e) {
// Log an error or something
+ if ($fh) fclose($fh); //many PHP file errors NULL out the $fh
+ }
- } finally {
- fclose($fh);
- }
Another non-compelling example...
Still not saying finally is a bad idea.
Just want a compelling use case before I would vote...
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
On Mon, February 27, 2012 5:21 pm, Ángel González wrote: On 27/02/12 19:22, Richard Lynch wrote: I'm not so sure about that. In a well-written web application, you would typically convert them on the first layer, when receiving from the web. On next usages, your int variables are usually ints already. Afraid not. It turns out that PHP, on 32-bit hardware, converting large BIGINT using (int) $ID ends up as a negative number, and then when you pass it in to the database if a string query, you get a negative ID, not at all what was intended. (Been there, done that, got burned) At least, that's been my experience with some versions of PHP and some database drivers. So at least the database IDs have to remain as strings, if you are using BIGINT. You could, of course, only convert the values known to be in range of PHPs positive integers, and leave the others as strings. This is just a simple example of how the super strict typing simply doesn't work out too well in PHP. That's a good example from experience. Although if you want to keep ids as strings, you can simply keep them as a string type. I was thinking on input coming from a web browser, btw. In a pagination of billions of items, it could come from the browser... Of course, you'd need something like a relativistic paginator such as: First | -1,000,000 | -100,000 | -10,000 | -1,000 | -100 | -10 | current | +10 | +100 | +1,000 | +10,000 | +100,000 | + 1,000,000 | Last Of course, you need to show 10 per page for this to be navigable to any item. I had to write such a beast once, though the range was only in the 100K, not billions... And it took some user-training, but it was an internal tool, so that was okay. Even the CEO who didn't know how to work email (literally) managed to figure it out eventually. You can get to billions with only 6 more links, however. :-) -- 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] pecl, zts, non-zts, fastcgi and Apache
On Mon, February 27, 2012 6:46 pm, Christopher Jones wrote: On 02/27/2012 01:12 PM, William A. Rowe Jr. wrote: On 2/27/2012 6:58 AM, jpauli wrote: Recently we had a bug with the new Apache 2.4 API where apxs doesn't answer about the MPM configuration anymore, leading to a ZTS build by default. This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172. Wrong fix. Out of the box you don't know which mpm may be loaded, because the mpm is now loadable (although a full daemon stop/start is necessary). Can you expand explain this, with an eye to resolving 61172? Are you saying Apache 2.4 'httpd -M' might not return the mpm? If I'm reading this correctly: apxs runs at PHP compile time and reads mpm from httpd.conf Apache is started, probably with that mpm, and then a different mpm is loaded and apache is re-started, maybe even with graceful, for real fun. mod_php has no knowledge of the new mpm, because the mpm choice was compiled in at apxs time. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting
On Mon, February 27, 2012 11:05 pm, Anthony Ferrara wrote:
?php
class Foo {
public $value = 1;
}
class Bar {
public $value = 1;
public function __castTo($type) {
return $this-value;
}
public function __assign($value) {
$this-value = $value;
return $value != 10;
}
}
$a = new Foo;
$b = new Bar;
$a++;
So, here's the thing...
This obviously trivial example makes perfect sense, until you realize
that some moron (and PHP has lots of them) will sooner or later make
++ do something completely weird, and I'm going to have to edit their
code-base and will have to dig through umpteen class files to figure
out what the heck ++ means...
I can see a lot of legitimate serious coders using this wisely.
Unfortunately, I can see a million scripters using it very un-wisely.
I can even see people overloading the plus operator for an object
wrapped around an array in multiple different ways, then pulling in
different libraries that seem quite useful, and the only way I can
figure out what + means is to dig through even more files and figure
out which bastard child this object comes from, that was passed into
some random function that uses + on it.
And then god knows what happens when you do:
$foo = new Foo(); //from library A
$bar = new Bar(); //from library B
$foobar = $foo + $bar;
//Will this last statement even make sense, even though both Foo and
Bar override the + operator, just in entirely different ways...
How can you even guarantee that $foo, presumably taking precedence,
won't attempt to access a non-existent property of Bar, generating an
ignored E_NOTICE on most hosts, and introduce a subtle bug that nobody
notices for months, even years, in a seldom-used function?
Consider the trivial example where Foo uses array_sum() and Bar uses
count() comes up with a number. It's a totally meaningless number in
any real-world scenario. How would one detect this bug, really, in
some mish-mash of libraries from PEAR/PECL/homebrew-MVC/Framework.
I'm sure you can define the rules in a page or so for precedence in
type-casting and what happens when.
But I really am not interested in figuring out the rules for + when
I've been using it the same way since 2nd grade, with modest changes
over the years that follow the spirit of +
Your proposal lets one re-define + to mean whatever one wants, and
while you might not abuse that, somebody else will...
You might as well install runkit on everybody's server and let them
have at it. :-)
PHP was founded on the KISS principle, so that newbies can, in fact,
write sub-optimal but working code quickly to get a website up, and to
keep newbie fingers out of mashing gears.
This is way over-the-top from that principle.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
On Mon, February 27, 2012 4:34 pm, Kris Craig wrote: I think this is the main reason for differentiating between strong (or whatever word is appropriate) and weak. The developer may very well want their script to blow-up in such a case. I believe I actually get it now... You want 3 layers: $a = 1; //current kosher unchanged weak int $a = 1; // some E_x error level strong int $a = 1; // some E_y error level where E_y E_x Is that a correct summation? -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
On Mon, February 27, 2012 2:08 pm, Johannes Schlüter wrote: On Mon, 2012-02-27 at 21:05 +0100, Gustavo Lopes wrote: On Mon, 27 Feb 2012 20:09:08 +0100, Johannes Schlüter johan...@schlueters.de wrote: On Mon, 2012-02-27 at 13:05 -0600, Richard Lynch wrote: I'd have to come up with some OTHER scenario not involving fatal error, such as: strict $db = new DB(); The example is wrong. The new operator will always return an instance of the given class (or there will be an exception). [...] This is not true. The new operator can return NULL. In fact, the intl extension uses this extensively: ok, internal stuff can do everything it wants. But it shouldn't. Doing that is really bad and I wasn't aware of that case. :-) And since it's bad another example should be used :-) At the risk of quoting the docs to a guy who probably wrote a bunch of it... http://www.php.net/manual/en/language.oop5.basic.php#language.oop5.basic.new doesn't really SAY you can't return NULL in the event of an Exception or raising an error... Maybe it's a documentation error to not explicitly state what the return value is when one raises an error and/or throws the Exception. But it may not even make sense to create an Object of that type, or could be incredibly difficult to create if there are enough extends, interface and whatnot... So shouldn't is an un-documented statement, at this time, and more a Best Practice perhaps. :-) To me, however, returning NULL seems like a reasonable action when the spec is followed and an Exception is thrown or an error is raised. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
On Tue, February 28, 2012 3:31 am, Arvids Godjuks wrote: I really liked what the O'Raily wrote here: http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html Please note that the author was a bass player in a band wanting to sell CDs online when the five (5) choices were the same brick-and-mortar major label distributors who wouldn't take his CD as he wasn't on a major label. He examined the options, and PHP was the only one that didn't make his head spin. His act of creating a single page to sell his CD online went viral, and he accidentally built a multi-million dollar company because of that. Since he'd never set out to make the money, just to help his friends (and they told 2 friends, and they told 2 friends...) he always tracked success not by not, nor gross, but by dollars paid out to artists[1] He eventually sold the company to a trust fund that goes to charity when he dies, and lives very comfortably off the interest, since he lost interest in running the company when it just got too routine.[2] If he had seen this strict/weak/strong stuff in PHP, that online CD store for the indie artists would probably not have existed for quite a long time, if ever. He's actually been online a long time, and is worth learning from, even if he never actually became a Real Programmer (tm), in his own words. PS You can find many conversations between him and me on the old, old, old PHP list before the split of the lists into -general etc. [1] http://www.cdbaby.com/About [2] http://sivers.org/trust -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting
On Sun, February 26, 2012 9:48 am, Anthony Ferrara wrote: I have to say that no matter how much a luv my OOP, turning every built-in type into an Object is just a Bad Idea... It's a form of bloat on RAM and CPU with minimal added value, imho. No matter which way you twist this pretzel: -1 -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting
On Sun, February 26, 2012 8:45 pm, Anthony Ferrara wrote:
Or operator-overlading to the rescue? :-)
Not quite. Especially because with operator overloading done at this
level (how it would be implemented in PHP) it's almost impossible to
make it consistent:
class string {
public function overload+($mixed) {
return $this-value + $mixed;
I think you meant '.' here instead of '+'
Otherwise, PHP type juggling will make it be 10 as well.
}
}
class Integer {
public function overload+($mixed) {
return $this-value + $mixed;
}
}
$int = new Integer(5);
$string = new String(5);
echo $int + $string; // 10
echo $string + $int; // 55
While I like the concept of overloading, I don't really think it's
solvable in a consistent enough manner that it would work here.
That said, there is no inconsistency.
If what you want to do is overload + on strings to do concatenation,
then it's on you to typecast everything to (string) for it to make
sense.
Oh, and string is a reserved word, so this won't work as-is, though
that's obviously picuyane.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bugs.php.net php 6
On Sun, February 26, 2012 2:03 am, Stas Malyshev wrote: Just discovered that our stock php 4 support discontinued message in bugs looks like: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Unless I've missed something, the momentum for php 6 is very much nonexistent, so we probably want to fix that message :) Isn't the emotional scarring of PHP 6 == Unicode far enough in the past to start some momentum for PHP 6? I sure core Devs have thought about this, and have gone so far as to make statements for what should be in PHP 6... PS If it isn't already, I want to write an RFC to change the default error_reporting to include E_NOTICE. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_3/NEWS branches/PHP_5_3/Zend/zend_API.c trunk/NEWS trunk/Zend/zend_API.c
On Mon, February 27, 2012 2:31 am, Laruence wrote: On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov dmi...@zend.com wrote: Hi Laruence, The attached patch looks wired. The patch on top of it (r323563) makes it better. However, in my opinion it fixes a common problem just in a single place. Each call to __toString() that makes side effects may cause the similar problem. It would be great to make a right fix in zend_std_cast_object_tostring() itself, but probably it would require API Hi: before this fix, I thought about the same idea of that. but, you know, such change will need all exts who implmented their own cast_object handler change there codes too. for now, I exam the usage of std_cast_object_tostring, most of them do the similar things like this fix to avoid this issues(like ZEND_CAST handler). so I think, maybe it's okey for a temporary fix :) Perhaps a better solution would be to make a NEW function that uses zval** and deprecate the old one with memory leaks. Old extensions remain functional, new extension consume less memory. (This presumes I actually understand the issue, which is questionable.) -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: PHP 6 include E_NOTICE in default php.ini
As promised in another thread, I have created a formal RFC on the topic of including E_NOTICE in the default php.ini.* files. Please note that I am specifically not proposing E_STRICT nor E_DEPRECATED in this RFC, as I believe the each need to be considered on their own merits, and not lumped into one decision nor even conversation. https://wiki.php.net/rfc/error_reporting_e_notice My first formal RFC, so please be gentle :-) -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bugs.php.net php 6
On Mon, February 27, 2012 9:37 am, Simon Schick wrote: The development of the unicode-as-default-charset should really be done within the next release coming after 5.4 I heared somewhere that it's nearly done ... I would have happily seen it in 5.4 but as this release is late right now we have to wait ;) I was off on medical leave for awhile, but last I heard, the one (1) guy who cared enough to work hard-core on a Unicode PHP realized just how terribly difficult it was, and just how many irreconcilable issues it raised, and he stopped working on it. Nobody else has taken up the banner, and PHP 6 trunk was moth-balled and started over, or so I heard... That sums up, even over-simplifies, a whole mess of threads, discussions at conferences, and IRC discussion in a couple sentences... I apologize to all for the over-simplification, and possibly outright errors. While I understand the allure of writing code in one's native language, and the ease of having one's native language supported out of the box in the string built-in type... There are mechanisms available in PHP now, which are more cumbersome, but they work without the very complex issues alluded to in paragraph 1.. Other languages may have this feature, but they were included from the beginning. Grafting them on to PHP at this point was attempted, and, as far as I know, failed. It was an ambitious attempt, and the issues could not have easily been foreseen, so it's probably very disheartening to have failed just short of the goal line. That's the way the ball bounces sometimes. Again, please forgive me if I have completely failed to catch something here, especially as I'm just getting back into the flow of things. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Cannot build ext/intl on Fedora 15
On Sun, February 26, 2012 1:19 pm, Tom Boutell wrote: Bump - this is still a live issue on Ubuntu 11.10, for instance. I just hacked my Ubuntu PHP-from-source installer to touch up the Makefile by prepending -lstdc++ to EXTRA_LIBS. That does the job. Which I knew more about autoconf, I'd like to help figure this out properly so everyone doesn't wind up maintaining hacks to compile PHP from source. It discourages a very large community from trying new releases. Is this perhaps because some of the code being included in the PHP build happens to be C++ code? (Not readily apparent from the outside of course.) I believe core PHP is all in C. Extensions, however, could be in C++ And if one extension has forgotten to edit the Makefiles to do -lstdc++ I presume that it could be the cause. I'd even hazard a guess that it would only surface if one disabled other extensions that generally PRECEDE it in the configure / make process, as once the -lstdc++ is in there, it remains for the rest of the build process. This is just a guess, however... At any rate, if you could eliminate each extension, one by one, you might find the culprit, assuming my guesses are valid. No promises anything I have said is even correct in any way. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] APXS LoadModule Option in configure
On Fri, February 24, 2012 6:14 pm, Kris Craig wrote: No, it happens and it's even clearly documented in APXS. Basically, if you specify the -a option in APXS, it overwrites your httpd.conf (or apache.conf or whatever it is on your system) and adds the LoadModule line to it. In PHP's configure script, you'll notice that -a is always specified; there's no option to use APXS without it. As a result, make install will always overwrite your LoadModule entry in httpd.conf if APXS is enabled. The problem occurs when you have LoadModule in an included .conf file already; APXS does not have the ability to detect that. Therefore, a duplicate LoadModule entry is added to httpd.conf by APXS, and thus the clash occurs. This behavior has been reproduced numerous times. I think the RFC is pretty clear on how this works. Nobody else has expressed confusion thus far. I could clarify further but I'm not sure how; it's pretty straight-forward, really. I'm not sure what may have been happening in your case or if perhaps you misunderstood what this RFC is about. Either way, I would recommend you create a fresh Linux-based build environment, build Apache 2.2 and PHP 5.3.10 yourself (i.e. stay away from yum/apt-get), then attempt to generate an APXS-enabled Makefile using PHP's configure script that does not activate APXS with the -a option. It might also be a good idea for you to check-out the APXS documentation (I included a link to it on the RFC). Those steps should enable you to reproduce this. =) Once upon a time, a lonng time ago, I read through the configure / make process, and I *thought* there was logic there to try to detect if your httpd.conf diverged significantly from the default, and, if so, it would choose NOT to add the LoadModule line, assuming you were a power user who had it somewhere else... I could be mis-remembering. This logic could have been removed. I could be hallucinating. The logic I saw could have been doing something entirely difference, as I have only a vague notion of how configure/make works in the first place. It could have been some other project. Or this could account for your different experiences, based on whether you hacked httpd.conf enough or started with a fresh out of the box one and didn't touch it until after installing PHP. ymmv ianal -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Fri, February 24, 2012 4:40 pm, Larry Garfield wrote: On 2/24/12 4:34 PM, Richard Lynch wrote: On Fri, February 24, 2012 4:16 pm, Larry Garfield wrote: On 2/24/12 3:28 PM, Richard Lynch wrote: Except that per HTTP, GET and POST are completely different operations. One is idempotent and cacheable, the other is not idempotent and not cacheable. I very much care which someone is using. If all my operations are idempotent, regardless of the request method, I can and will cache the POST operations, because I know I can do so. In other words: The HTTP spec specifically requires GET to be idempotent, and that implies it is cacheable. Nowhere in the HTTP spec can I find a REQUIREMENT for POST to not be idempotent, or to NOT be cached if it happens to BE idempotent. If I'm wrong please cite your reference. As Will said in the other reply, there's security implications. (I don't know who suggested that POST is more secure than GET. I certainly didn't.) I know you wouldn't say that. Only total newbies think POST is more secure because they just don't understand how they work. You want your login form operating over POST, not GET, in large part for the reasons above. Obviously login MUST be POST. It's not idempotent. Authentication to receive the content would also have to be POST, as it's not idempotent. But there is no reason to REQUIRE idempotent requests to be GET, and no specification that I can find that states that it is. The only requirement is that NON-idempotent must *NOT* be GET. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Fri, February 24, 2012 4:48 pm, Ronald Chmara wrote: On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield la...@garfieldtech.com wrote: To me, it's just a request for some content, and in a REST API that's read-only, I just don't care if the consumer sends their request as GET or POST. I'll cheerfully give them what they wanted. Except that per HTTP, GET and POST are completely different operations. One is idempotent and cacheable, the other is not idempotent and not cacheable. I very much care which someone is using. People exploiting security would *never* think of caching/replaying/modifying a POST request, that's just totally unimaginable! It would take, like HUGE computational effort to like, cURL it or just type it out! You missed the totally newbie way, or at least a way to demonstrate the issue to somebody who simply doesn't understand the issue: Save the HTML form to your hard drive. Edit it in Notepad (et al) to make up whatever value=xyz you want. Open it in your browser using Open File... and pick the file. Submit the FORM. I had to do this several times for non-technical bosses or students who simply refused to believe that it was TRIVIAL to forge POST requests... Once they saw it in action, the light bulb goes on and you can say: I can also script this to repeat the same thing a million times with form-letter substitution, and then they understand it *is* trivial. Maybe I just had dense bosses/students, or I was bad at explaining the idea, but it worked for me... -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
On Fri, February 24, 2012 4:33 pm, Kris Craig wrote: I hear that a lot; i.e. If you want static typing, use Java. Unfortunately, that dismissive answer has not worked too well over the years, has it? People are still clamoring for this, and I think making some very valid arguments that shouldn't be so derisively and flippantly brushed aside. I did not mean to be flippant, and was quite sincere, so allow me to restate it: This idea has been floated many times. Sometimes, it even came with initial patches to prove it could be done, and was feasible. Every time, eventually, non-trivial issues were raised by Core Devs that could simply NOT be addressed by the proposer, and they realized that changing PHP at such a fundamental level was, indeed, a non-starter. Or at least a non-finisher. :-) I only meant to suggest that if you seriously WANT these features in your language, switching to Java and JSP will give them to you, without the pain and suffering of a TON of work that history has shown will 99.% sure end in failure. I am, again, not being flippant, nor trying to claim that PHP is not an evolving language. I am, still, stating that the probability of it evolving in this direction, after it has been tried and failed so MANY times in the past, is incredibly unlikely. Examine the historical record, and the many proposed patches / changes / ideas, and I sincerely believe you will come to the same conclusion. If you really think you can pull it off, despite the historical evidence, I suggest you start to make a patch to do so, and find out just how much you are biting off to chew. In essence, you will effectively be re-writing Java / JSP or something similar, while trying to maintain compatibility with PHP and PHP internals that rely extensively on dynamic typing. To bowlderize Clemens (?) with regard to typing: Strict is strict, and dynamic is dynamic, and never the twain shall meet. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
On Sat, February 25, 2012 7:58 pm, Kris Craig wrote: On Sat, Feb 25, 2012 at 4:54 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! I'm well aware that this has been discussed before, Stas. However, you're mischaracterizing those previous conversations. It has never been proven that optional strict typing doesn't work. You've made the same arguments against it, but those arguments have counter-arguments that are also viable. I'm not sure what you mean by proven. You expect rigorous mathematical proof? You're not getting one. If you have something new to say with regard to the arguments that were brought up 10 times already - ok, go ahead. But please read them first. Another logical fallacy. Cognitive dissonance. Either there is rigorous mathematical proof or a statement is completely unproven (and/or cannot be proven). Are you going to completely dismiss statistical probability somewhere in the middle of the two? People a whole lot smarter than I, and, forgive me, but *some* of them probably smarter than you, have tried this again and again and again. They all failed. They failed exactly for the reasons Stas pointed out: You can't change just one thing. The changes have repercussions, and in this particular instance, those repercussions dig into the heart and soul of PHP, to the point where you would, quite literally, have to change PHP *INTO* JSP or similar. In fact, you haven't proven your point by any standard, rigorous or otherwise. There is no basis for suggesting that it cannot be done. You've clearly stated that you don't think it *should* be done, but you haven't viably demonstrated that it *can't* be done, or that it would break PHP as we know it. The problem is probably NP-incomplete, though I have no proof for even that statement, other than my gut telling me it is so. I certainly have not the time nor inclination to prove the completeness or lack thereof for adding static typing to PHP. Perhaps a trained mathematician (like me) who has kept his skills up (unlike me) would take a go at it. :-) people keep asking for it. It keeps coming up because, despite belittling and dismissive comments made by yourself and a few others, people continue to see that there is, in fact, a valid argument for implementing this. It shows that you have never been able to convince those who don't already agree with you that this is impossible. Or it's coming up because people don't bother to read past discussions and think they are first who thought let's put strict typing in PHP and only reason why it's not there because nobody was smart enough to think about it. It's not so. It was repeatedly discussed and rediscussed. If you have new argument - fine, we'd all be happy to hear it. So far I didn't hear one though. Please let us hear it. No, it's coming up because people have read these past discussions and still think it's a reasonable goal that deserves further consideration. In the abstract ideal, it's quite reasonable. The devil is in the details. It can't be done, without completely re-writing PHP into something akin to a different language. This conclusion has been reached multiple times, with multiple proposals and attempts, including a lot of patches, some that went very far down the path before they failed, and were abandoned. On the contrary, it looks to me more like it either fizzled or was punted each time, but no consensus was ever reached. Therefore, further discussion is warranted. The fact that this was discussed previously does not make this topic any less legitimate. They all fizzled or punted because the enormity of the problem space turned out to be insurmountable. This is not to say you CANNOT succeed: Only that every attempt before, and they are legion, has failed. It doesn't work that way. Language is a complex construct, with all parts influencing each other, thinking you can just add strict typing somewhere in the corner and nothing changes is a dangerous illusion. It would not work. If you type function arguments, you should also type all the variables that could end up as the function arguments, all the functions returning into those arguments and all the operators and functions that do any transformations over those things. Otherwise it is guaranteed to blow up in runtime. After doing that, you've got yourself a strictly typed language. Absent compiler, though, such language would be quite hard to operate - how do you know your code correctly uses all the types some library wants? How do you know next version doesn't change any types without you noticing? etc., etc. You're operating on a number of unfounded assumptions here (a house of cards if you will). First, nobody is saying that this wouldn't be a significant undertaking at the core development level. We all agree that it would be. However, you're once again introducing cognitive dissonance into this.
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
I'm not so sure about that. In a well-written web application, you would typically convert them on the first layer, when receiving from the web. On next usages, your int variables are usually ints already. Afraid not. It turns out that PHP, on 32-bit hardware, converting large BIGINT using (int) $ID ends up as a negative number, and then when you pass it in to the database if a string query, you get a negative ID, not at all what was intended. (Been there, done that, got burned) At least, that's been my experience with some versions of PHP and some database drivers. So at least the database IDs have to remain as strings, if you are using BIGINT. You could, of course, only convert the values known to be in range of PHPs positive integers, and leave the others as strings. This is just a simple example of how the super strict typing simply doesn't work out too well in PHP. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Fri, February 24, 2012 5:15 pm, Larry Garfield wrote: On 2/24/12 4:55 PM, Jeremiah Dodds wrote: Except that per HTTP, GET and POST are completely different operations. One is idempotent and cacheable, the other is not idempotent and not cacheable. I very much care which someone is using. Correct me if I'm wrong, but you're referring to the HTTP *method* used. A POST can be made to a URL that includes a query-string, but what that means as far as interpreting the variables is undefined as far as I know. Because of that, I think it's a bad idea to either treat them as the same thing, or rely on both $_POST and $_GET parameters being present. The underlying problem is that HTTP has a URI query string, and a body. In a typical GET request there is no body. Nitpick: I think a body is explicitly NOT supposed to exist in a GET request, and not just typically. It's been a long time since I read the HTTP spec though... In a typical POST the body is a query string in similar format to the URI's query string, plus possibly other stuff. In other request methods the body may be something else entirely. PHP's superglobals make the (wrong) assumption that the URI query string comes from a GET query (hence $_GET) and body comes from a POST query string ($_POST), because that matches up with the default method= attribute of HTML forms. That assumption is limiting and misleading, and made worse by the existence of $_REQUEST, but is the assumption that PHP makes. Unless I am very much mistaken, the HTTP spec explicitly states that parameters in the URL with a POST request are completely kosher. Separating those two sources in a single request, by placing the URL-specified input as $_GET makes perfect sense to most PHP developers, even though, strictly speaking, the are part of the POST request. I don't know if the HTTP spec even addresses the question of having a URL-specified and a POST-body specified parameter of the same name. However, given that it explicitly allows a URL with ?foo=barfoo=12foo=whatever, I can't see how it would ban the duplicity of POST data and GET data having the same parameter name, once it allows URL-specified and POST-body specified parameters. I have certainly always enjoyed PHP's extension of the spec to create an array for multiple params ending in []. Trying to do the same sort of thing in old-school ASP made me tear my hair out... I like the way PHP handles $_GET $_POST and $_REQUEST, and you don't. Neither is right or wrong Sometimes I find $_REQUEST useful, sometimes I don't. I have presented at least one use case where I do not *care* where the input comes from, because the operations are all idempotent, and nothing in the spec says POST has to be NON-idempotent. Another use-case, back before CSS let you change presentation of buttons and links, and javascript was just a nightmare of incompatibilities in even the most simple scripts, was a case where the look and feel dictated links (GET) on one page, and buttons (POST) on the other page. I simply used $_REQUEST in the processing page, which was just a read-only filter to idempotent requests. I believe one was a search FORM that was POST, and the other was just pagination with filters. Perhaps, in retrospect, the FORM should have used method=GET (the preferred capitalization in those days). But it may have set some session-preferences, and therefore not been strictly idempotent, while the GET did not set preferences... It's been a long time... At any rate, I still contend that when the server just doesn't care what method of request comes in, because they are all idempotent, there is no need to insist that GET be used if the consumer of the service finds POST more convenient. GET must be idempotent. The converse is not true. An idempotent request does not HAVE to be a GET. In other words, POST is not required to be NON-idempotent, even if GET cannot be NON-idempotent. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object Casting - An Alternative to Type Hinting
On Mon, February 27, 2012 9:20 am, Anthony Ferrara wrote: I have to say that no matter how much a luv my OOP, turning every built-in type into an Object is just a Bad Idea... It's a form of bloat on RAM and CPU with minimal added value, imho. Re-read what I had written. I never said to turn every built-in type into an object. In fact, what I was talking about was keeping and preserving the base types as-is. All that I was proposing was adding the ability to cast from and to the primitives. That way you could silently convert back and forth as needed (transparently when possible). I apologize that my brevity has been misconstrued. You are certainly free, even with the tools available in PHP, to wrap an object around integers, strings, and so on. There may even be occasions where I think that would be a Good Idea (tm). What I object to is building such a facility into core PHP, because: 1) You can already do it in userland, and I believe that's where it belongs. 2) It unnecessarily [see 1] complicates core PHP, whose major strengths that drive its success includes its simplicity. No matter which way you twist this pretzel: I had hoped that this bit would hint that all the proposals along these lines, including yours, are proposals I would vote against, even though I did over-blow your actual proposal. -1 So what it sounds like you're -1ing to, is not actually what was proposed... I'm starting to work on a patch for this as a proof of concept... Please do so! I'll still vote -1, but obviously others will vote as they see fit. All these ideas are welcome. The ones with complete patches even more so, as they allow a true idea of what the change would mean. Unfortunately, however, I must repeat that, so far, the idea has always fallen flat on its face when the proposer actually attempts to put action into deed, making a patch that fully meets their proposal. That doesn't mean you can't succeed, if you are more skilled than all your predecessors. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
On Mon, February 27, 2012 10:45 am, Ángel González wrote: On 27/02/12 17:19, Richard Lynch wrote: PRESUMPTION: *ANY* strict datatype could also be NULL, to represent a failure condition... Otherwise, when you are out of RAM: strict $o = new Object(); //violates strict, because Object HAS to be NULL, as there is no RAM left for it to be an object. Uh? No. You would get a fatal error because PHP exceeded maximum allowed memory. You are correct. I'd have to come up with some OTHER scenario not involving fatal error, such as: strict $db = new DB(); and your database being down, unavailable, or connection parameters being wrong. The principle remains. You probably still want $db to be NULL in that situation, rather than an unusable DB object. Otherwise, you'll have to write a lot more sanity checking code elsewhere, which is what you are trying to avoid in the first place... Or, perhaps not. Perhaps you really do want this case to just plain bomb out with a failure that the $db is not strictly an object, with no recourse to try again, or deal with the error in application logic... -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
On Mon, February 27, 2012 11:38 am, Anthony Ferrara wrote: Discussed to death. Yet only one time before (discussing a specific patch)... Did you go back to the old, old, old PHP list (and was it PHP-dev back then?), before it split into php-general and php-internals and php-*, back when there weren't enough users to warrant more than two lists? You may find more fruitful results there, I think. Or not. Did you check the wiki and RFCs that came out of those discussions? Those are the places where the really serious proposals with patches developed after the mailing list wrangling. They all failed, in the end, but those are the ones that actually got taken seriously, because they had enough specificity to discuss for or against for technical merit. The idea has always always had some technical merit. The implementation, however, has always failed. The very strict typing usually failed quickly. The not so strict typing either failed after a lot of effort, and edge cases kept cropping up, or ended up being so weak as to not provide any additional value over the original dynamic typing. The patches are out there. The conclusions and technical issues are out there. They may be lost in the sea of flame-wars, but they do exist. If you don't like this feature, and you can explain from a TECHNICAL perspective why, please do so! If you don't like the feature, and are going to lean on It's not Java, or We've discussed this to death already, please don't... Stas has already stated that you can't do what you want and have it mean anything without changing the very nature of PHP. I said the same, poorly, and invite you to TRY with a patch instead of discussing it endlessly here. And to be fair: and you can provide new arguments to the discussion has already happened quite a bit (dating back the past 5 years), but those arguments were ignored or overruled for political reasons. Write the proof of concept patch, please. Then we can discuss the technical merits or prove why it won't work. Otherwise, it really is an endless discussion of a dead horse. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
On Mon, February 27, 2012 1:15 pm, Kris Craig wrote: Now, to rewind a bit past the latest chunk of I hate this idea posts I'd like to suggest a new term: strong. This term would be similar to weak, except with a few key differences: - Weak would behave very much like Arvids suggested in his earlier post; i.e. if the variable is an integer but you pass a string (like aaa) to it, a warning would be thrown and PHP would attempt to convert it (i.e. it would become 1). Nitpick: Two backwards compatibility breaks: 1) Throwing E_WARNING 2) aaa converted to (int) is 0. - Strong, on the other hand, would throw a fatal error if you attempted to pass an incompatible value to an array. Or, to put it another way, if the converted value does not match the original value. For example, if we're assigning aaa to an integer, that would convert to 1; and, since 1 != aaa, a fatal error would be thrown. On the other hand, if you were to pass the string 1 to that integer variable, it would convert to 1; and, since 1 == 1, there wouldn't be a problem. Converting aaa to 1 causes the error... Converting aaa to the backwards-compatible means aaa == 0 will return TRUE, and your test for reverse engineering will not help. This is still a nitpick, as I'm sure you could eventually come up with some way to validate your strict-ness of conversion. It would be more cumbersome and slower than using PCRE or ctype_* to validate or === to guarantee the data types match. But you can do it. And I'd love to see an extensive patch in an RFC rather than this endless back-and-forth. Neither Stas nor I are saying it shouldn't be done. We're saying it's been tried and failed, but if you want to be the little engine that could, the proper place is in an RFC with a community-drive patch that can be evaluated on technical merit. - In both instances, if the converted value matches the original (i.e. 1 == 1), no warning error would be displayed. Should it perhaps display a notice though? Or no error at all? I can think of reasonable arguments on both sides of that question. I'm pretty sure backwards-compatibility is going to trump, and no error at all will win out. This new term would also make it easier for us to avoid using the term strict, which would explode even in the case of 1 == 1. This is a good idea to distinguish between strict typing throughout, and judiciously applied strict typing. I fully support calling it strong for clarity purposes. Whether this should be done at the function level, the variable level, or both is an open-ended question. weak int $i = aaa; // Converts to 1 and throws a warning. What purpose would 'weak' serve? If you want the old default behavior, just leave out the 'weak'. And we already have (int) $i = aaa // converts to 0 as ztype int. Or perhaps I'm missing something where 'weak' is supposed to invert the current logic of aaa - 0 and you actually want it to be 1 and not backwards compatible? I must be missing something here, then, because that just plain doesn't make sense to me, personally. strong int $ii = aaa; // Throws a fatal error. Okay. E_FATAL seems drastic to me, but I'm not even going to use strong so don't really care either way, I suppose. I can always set my error handler to over-ride the level of your error, and even pick out the specifics to change it to whatever I want... I respectfully suggest you'll want to discuss the actual level of error among proponents of the strong typing, and put the consensus in the RFC. weak int $i = 1; // Converts to 1. Again, old-school (int) or set_type covers this. Adding new keywords to fulfill the same purpose seems like bloat to me... strong int $ii = 1; // Converts to 1. Okay. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scalar type hinting
On Mon, February 27, 2012 1:22 pm, Kris Craig wrote: Now that you've voiced your opposition, can we please dedicate this topic to discussing how this can be done? If you think we're wasting our time, then ok; it's our time to waste. I'd be happy to take you up on your challenge to try to implement this, but first we have to brainstorm what exactly we'll be doing. And that'll be much easier if we don't have to keep sifting through duplicate posts about why this is a bad idea. Let's just set that aside for now so we can brainstorm. Last post on this topic: Would you please consider creating a separate list or wiki page or incomplete RFC, so that those of us who consider the discussion fruitless from past experience can ignore it until it crystallizes a bit more? A weekly update to the list, or even daily, of the progress would be quite reasonable, and keep everybody in the loop, without the details and less flames. I truly believe this will be a more constructive use of your time, and ours, or I would not ask it of you. Thanks! -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: PHP 6 include E_NOTICE in default php.ini
On Mon, February 27, 2012 1:33 pm, Kris Craig wrote: I think it's a good idea, though I'm not sure it should be done in the production one as well. I'm not sure, but I think these errors are generally suppressed in production because of potential security concerns involved in making those errors public. I would contend that if you have any errors at any level of E_* going out over HTTP, you have done it wrong. It is true that in the days of register_globals, the E_NOTICE going to the HTML was a gold-mine for abusers of potential security threats. But all of E_* messages are also goldmines of the same ilk. That said, I would suggest amending the RFC so that it only applies to php.ini-development. Other than that, I like it. If most cheap webhosts chose php.ini-development, I'd be okay with this, as it probably is not suitable for PRODUCTION environments for the experts. Unfortunately, most cheap webhosts go with php.ini-production, as they are production environments, and the unwashed masses of users of said cheap webhosts are the target audience of the proposal. As stated in the RFC, the experts can and will change their php.ini to their taste in each environment: It's the masses of users who don't even know there is a choice that are being hurt by the current default setting, writing bad code, asking questions of obvious typos that E_NOTICE would catch, and remaining un-educated for too long that they develop bad habits. Not that I think this will eliminate newbie postings. There will always be those who don't even read or comprehend the most clear error messages. But I think it will reduce the number of postings by newbies who are tripped up by the typical mistakes E_NOTICE exposes. PS I want to thank you for your reasoned response, especially given the other thread we are involved in! -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
On Fri, February 24, 2012 1:52 pm, Tom Boutell wrote: 2. Why does php turn on thread-safety for mod_php at all on Linux, given that it apparently still doesn't work very well with various extensions in a genuinely multithreaded situation, slows things down, takes more memory, and leads to problems like this one? I can't recall who, but I have heard people who claim to run multi-threaded on Linux, but with a heck of a lot of stress testing, and a rigid control on minimal extensions added... So apparently *somebody* uses it. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Wed, February 22, 2012 8:57 am, Michael Morris wrote: Before writing up a full RFC I want to put out a feeler on something. Currently we have several input parameter objects, chief among them $_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All of them are arrays and legacy code sometimes writes to them. Locking them as read only objects would cause a major BC break. What if instead we had an Object called $_PARAMETERS which holds the read only copies of this data. In addition, this would be the first superglobal object, able to perform some filtering of inputs. Basic idea.. $_PARAMETERS -get -post -cookie -headers (The client http headers) All of these would be array objects, and all would be read only and have these methods and properties -filtered: Copy of the array according to the current set filters of the object. -setFilters(): Sets the filters of the input, an array with constant values for the allowed types. And I'll stop there. The basic idea, to add a read only input hive with some basic object functionality for filtering. I can see how you would want this, but it seems to me that you can code this easily enough in PHP, with a singleton class with private read-only properties that initialize to the various $_XXX values, and a filter method that employs PHP FILTER. Personally, I think introducing a whole new feature to be maintained and documented to save defining a couple simple classes and a page of code is not a win. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Wed, February 22, 2012 9:10 am, Michael Morris wrote: $_REQUEST does nothing of the sort, and it's use is dangerous in RESTful architecture. $_REQUEST is a smash together of $_GET, $_POST and $_COOKIE, in that order but the php.ini directive can change it. Hence there's no way of knowing if $_REQUEST['password'] came from $_COOKIE, $_POST, or $_GET, and worse, if two values in those source arrays have the same key $_REQUEST will overwrite them. $_REQUEST to be honest, is a lame shortcut and bad idea almost on par with register_globals. Given that all three of $_GET $_POST and $_COOKIE are equally suspect from a security POV, and you shouldn't really *care* which way the client delivered the value, or at least not rely on it for anything useful, I've never understood the resistance to using $_REQUEST. Yes, GET should be idempotent, but there are many APIs and functions in a large app that are idempotent by nature, and having a REST that just doesn't care how the data comes in allows the consumer of the service to use whatever they prefer. If your entire REST service is read-only, such as an RSS feed, why not allow GET or POST (or, silly as it may be COOKIE) and just use $_REQUEST. -- 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 Script Compile System
On Tue, February 21, 2012 11:49 pm, Deepak Balani wrote: I am think(actually drafting) about the compilation system of PHP scripts. I want to make a native C extension which is able to compile the scripts in the Zend Engines opcodes and execute directly when called. The extension may have two functions. bool gpc_compile($source, $target): compile file to opcodes. mixed gpc_import($target) Include file to current script. gpc_import function accepting path to the compiled file and execute file into the zend engine. I want to know perception of you all about this. It sounds intriguing to me, if it can work reliably... But what advantage is this over an opcode cache, really? Now, if you could compile it to binary with `make` that would be REALLY interesting :-) -- 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 Script Compile System
On Wed, February 22, 2012 3:45 am, Flavius Aspra wrote:
On 02/22/2012 07:29 AM, Rasmus Lerdorf wrote:
complicated optimization passes or any of those things
Would such things be welcome/needed in the engine or as an extension?
Note that he said complicated :-)
There are many trivial / easy optimizations of low-hanging fruit.
It's just the out-of-band not-in-real-time complicated ones that PHP
doesn't do, shouldn't do, and won't do.
So if you find a quick easy one, it's most welcome...
The complicated ones, not so much :-)
PS
The misinformation that opcode caches save compilation time
routinely rears it's ugly head. Opcode caches save disk reads. Using
the already-opcoded chunk is just gravy, because the cache does this
(grossly over-simplified):
if ($opcode = opcode_cache_get($filename)){ //added by opcode cache
//do no disk I/O EXPENSIVE
//Oh, and for gravy, don't compile it.
}
else{
$source = file_get_contents($filename); //EXPENSIVE
$opcode = php_compile($source);
}
php_execute($opcode);
instead of this:
if ($source = opcode_cache_get($filename)){ //added by opcode cache
//do no disk I/O EXPENSIVE
}
else{
$source = file_get_contents($filename); //EXPENSIVE
}
$opcode = php_compile($source); //cheap and easy small optimization
missed
php_execute($opcode);
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
On Thu, February 23, 2012 1:21 pm, Kris Craig wrote:
1. Is strict typing something that we should seriously consider
implementing at some point in the foreseeable future?
No.
If you want that, PHP is not the language for you, so just go use Java
and JSP.
I'm not being rude nor abusive: If anyone dislikes the way PHP works
at such a fundamental layer, they just shouldn't use it.
3. If toggleable, should this be defined at the config level, the
script
level, or both?
God no.
The insanity of dozens upon dozens of php.ini settings make
portability difficult enough already.
of sending variables (JSON-encoded/decoded from a remote
hub that he also
wrote) with inconsistent types. For example, the progress
key could be a
multidimensional array, a string, NULL, a boolean, and in one
rare case
even an object pointer. But MOST of the time, it's an array,
switch (true){
case is_array($input): break;
case is_null($input): break;
case is_boolean($input): break;
case is_string($input): break;
default:
//There is no object pointer in PHP, so I dunno what you are
talking about...
break;
}
Was that really that tricky?
- It would probably be a fairly large undertaking to implement.
Monstrously large.
But feel free to try it yourself. :-)
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] APXS LoadModule Option in configure
On Mon, February 20, 2012 7:02 pm, Kris Craig wrote: Opening discussion on RFC pertaining to adding a new option to the configure script with regard to how/whether APXS touches the httpd.conf file. This is my first RFC post so please go easy on me if I screwed-up on procedure in any way. =) Here it is: https://wiki.php.net/rfc/apxs-loadmodule This seems to me like a useful addition, with minimal risk, and many sysadmins would welcome it. Has to default to current behavior, of course, which one might want to add to the RFC explicitly. +1 until somebody explains why it's bad :-) -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Fri, February 24, 2012 4:16 pm, Larry Garfield wrote: On 2/24/12 3:28 PM, Richard Lynch wrote: Because GET and POST are not even remotely the same thing and treating them as completely interchangeable is a bug in the first place. We'll have to agree to disagree here. To me, it's just a request for some content, and in a REST API that's read-only, I just don't care if the consumer sends their request as GET or POST. I'll cheerfully give them what they wanted. It is in fact legal to have both in the same request. Then what do you do? Option A) Don't use REQUEST if you need both Option B) The GPC ordering is quite specific and reliable The idea of having a real request object in PHP is a good one; I'm not even seeing why turning the independent arrays into an object is a Good Idea, so have chopped the rest off. But I certainly agree that researching the PHP code out there is a Good Idea to compare to the RFC to see what's missing / wrong, if one wants to continue down the path. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate and remove /e modifier from preg_replace
A couple people I respect a heck of a lot have voted against, but I've heard no technical explanation of why from them... I voted Yes because I've never found a need for /e at all, personally. Not sure my vote even counts, so feel free to nuke it. :-) Or maybe I'm just not smart enough to employ it, but un-wind the text and use more PHP code to get the job done... Anyway, I'd like to hear reasoned thoughts on No votes. -- 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] Feasibility of additional support around constants.
On Mon, November 8, 2010 6:33 am, Richard Quadling wrote:
1 - Validating that the value received is in a collection of known
constants. This would allow for new constants to be added without the
layer having to be amended to verify the value. If it isn't in the
group - it's invalid.
Generally-speaking, it's valid if it's between 0 and the largest
value, rather than being in an array/list...
And, yes, updating the code to check this is really hard, unless
you're smart enough to do something like:
define('FOO_0', 0);
define('FOO_1', 1);
.
.
.
define('FOO_42', 42);
define('FOO_MAX', 42);
and then your check is on FOO_MAX, which you update when you add
another constant.
2 - For a constant value, report back the actual name of the constant.
The user supplied the value of 4 to the function. The function failed
for some reason and in the ensuing exception report, showing the name
of the constant would be extremely useful. Not all the extensions
document the value of the constants, so knowing what 4 is in't
instantly available.
It doesn't really take a lot of effort to copy/paste the constant
names and echo out their values...
Not that you *should* do that, as those might change in a new release,
if there is some kind of meaningful order to those constants by name,
and one is INSERTED and they were never intended to be stored
externally, much less embedded in your code...
In fact, the whole point of USING constants will be violated by using
the magic number to reverse-engineer the name of the constant, if
you think about it for a bit.
3 - If the collection is a set of bitmasks (error_reporting for
example), then report back the constants that make the value.
Here the valid combinations may be subject to some
application-specific logic where the range would have holes in it...
E.g., 1 4 might be an invalid bitmask, where 12 and 18 is
perfectly valid... So I can see where this maybe needs a list of
known valid values, sometimes...
But the library itself should take care of this, and provide a
function to check the validity, not the app layer.
It's putting the burden on every single app that uses the library,
which is just fundamentally wrong.
Now, you may think, why not use Reflection? Yes. I have done that but
you can't easily group the constants. There are many constants set to
the value of 2 (for example).
If you don't know which extension generated the error in the first
place, you are in REAL trouble...
So just knowing the extension and 2 ought to tell you which constant
it is...
In the rare occasion where I felt the need to reverse-engineer this,
an array like $foo_constants[ FOO_1 ] = 'FOO 1'; did the trick for me.
And, yes, updating that when constants are added is somewhat painful,
but then you'll have to update SOMETHING somewhere to get meaningful
text out of it, unless you get the parser to just slap the first
parameter to define() into the zval...
So instead of a group number, you'd have the zval storing
'INFO_CREDITS' (for example) somehow for the 2 that goes with
phpinfo()...
a - Useful
Honestly, not really...
I can see why it looks useful at first, but it just violates too many
principles to implement, at least as you describe it...
And storing the constant name in the zval at the time of the define()...
Come to think of it, whatever 'defined' does to look up the answer
implies that PHP is already storing the constant name *somewhere*...
How you would tie that back to the value of the constant is beyond me,
but doing that in the 'define' C codebase that seems far more simple
than making up some new group number...
Of course, I'm not gonna be the guy writing that code :-)
b - Doable
Seems like a lot of effort for minimal benefit to this naive reader.
--
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] PDO_DBLIB Native PHP Type binding
On Wed, November 3, 2010 8:52 pm, Stanley Sufficool wrote: Before I gut PDO_DBLIB one more time to implement native parameter binding for stored procedures, what are the thoughts on returning the column values from the database as the native PHP type when possible? Currently everything is returned as a string, incurring overhead for conversion and creating problems hinting at the desired binding type for BLOBS and numeric data types. It *SEEMS* like a Good Idea (tm) until you think it through and realize that there is NOT a one-to-one correspondence between PHP native types and DB native types. Even what seems like a no-brainer for, say, INT is not. Does PHP INT have the same range as the DB INT? Dollars to doughnuts says No. is the correct answer. BIGINT? Not a chance. PHP doesn't really do bigint, unless you want to return some GMP thing, which is probably not a Good Idea, as GMP isn't always there, I don't think. Then you start looking at things like an enum, or GeoIP, or IP address as native DB types, and it gets really ugly, really fast. -- 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] PDO_DBLIB Native PHP Type binding
On Thu, November 4, 2010 9:09 pm, Stanley Sufficool wrote: On Thu, Nov 4, 2010 at 5:37 PM, Richard Lynch c...@l-i-e.com wrote: On Wed, November 3, 2010 8:52 pm, Stanley Sufficool wrote: I realize as the guy who has to deal with the driver code and what it should do for people not following the advise below, it's probably preaching to the choir, but... Read the below comments this way: Anybody dumb enough to rely on the kind of stuff you are asking about is already in Big Trouble (tm). I realize that non Zend types would have to be returned as a string representation. At the risk of repeating myself, even Zend types aren't going to match up -- The devil is in the details. The range for an INT in the DB won't match the range for a Zend INT, for at least some databases, almost for sure. I know 2s complement is 2s complement all over, but there has to be SOME DB out there that has a range +/- 1 compared to Zend INT. The hangups I am having is with large objects returned as streams in some drivers (but not dblib) I never really use large objects, as anything that large doesn't belong in the database in the first place... :-) Rule Of Thumb: If it's a BLOB, and you aren't using it in WHERE or ORDER BY, then it doesn't belong in the DB. Put it in the custom highly-optimized specialized database engine commonly known as the file system where it belongs. :-) and inconsistent date/time string representations across drivers depending on server configuration files (freetds.conf). Ewww... I generally use the DB date format feature to format dates in a consistent manner, rather than rely on whatever random date/time output the DB/driver chooses. Another BIG issue I am having when using strings with DBLIB is that they go through iconv, destroying binary values when translated to the server character set from the assumed latin1 PHP client character set. SQL Server for some reason allows characters to be stored in a varchar/text fields even though the character is not defined in the servers code page, whereas iconv pukes with an error. I'm not an i18n expert, but... Why is iconv being injected at this point?! And why is PHP client library using latin1 for data that just isn't latin1? That's just asking for problems... I would expect any driver to just give me the raw data from the database, in the charset defined by the DB, and not to try to down-sample it to some other charset for me... Though I guess if you've told the PHP client to make it be 'latin1' the best it can do is trash it through iconv and you get what asked for... My only answer to that is to change your code to not ask for 'latin1' in the first place, when the data isn't latin1. Change the PHP client charset to what it ought to be, and get the data you wanted, not some lossy down-sampled useless conversion of the data you wanted. I cannot comment on SQL Server behaviour with respect to the servers code page [sic], whatever that is, except to say that MySQL lets you define your charset on a table by table basis, and, I think, in recent versions, even on a field by field basis. OpenSource ftw, perhaps? :-) It would be a wonderful development to have an RFC on the preferred string representation of various objects as returned by the driver so that when using ANSI SQL with PDO you can expect the same representation across all drivers. I'm all for documenting what SHOULD happen across all drivers, if a) the docs are sensible, and b) it can be implemented in all drivers I suspect that even a) would generate a TON of discussion on this list that would never be resolved, and that b) is simply not possible due to some really brain-dead drivers. But that's just my naive gut talking, with no real specific knowledge. ymmv -- 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] rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON
On Fri, October 29, 2010 7:47 pm, admin wrote: WTF is T_PAAMAYIM_NEKUDOTAYIM? This has to be THE most asked question by new php developers when they come across it. Can we please change the token name to T_DOUBLE_COLON so I don't have to hear about it constantly? Those that disagree don't do enough PHP support to know how often it is asked. it's worth it. -1 And I *have* done enough PHP support. :-) -- 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] Intermittent problem: can't write to properties of $this
On Thu, October 21, 2010 6:04 pm, Tim Steiner wrote: Greetings, I'm currently trying to troubleshoot an intermittent problem on one of our servers. After some time of running just fine (usually a couple of hours), scripts will start throwing the warning Attempt to assign property of non-object when writing to a property of the $this object. Once it starts, it seems to keep happening every few requests (with other requests running as expected). The poster at http://www.zfforums.com/zend-framework-components-13/core-infrastructure-19/warning-attempt-assign-property-non-object-zend_config-5469.html seems to be having the same issue. I've traced the warning output to line 576 of Zend/zend_execute.c, which means that something is happening to the write_property of the object. At this point, I don't have enough knowledge of the internals to continue tracking this bug down. Any help would be appreciated. Try dumping out the value of $this or your variable or the moral equivalent in C, and see exactly what it *IS* that you are trying to set a property on... Once you figure that out, you can often realize how you managed to get in this state of existence, or at least start backtracking to see how that value got in there in the first place. It probably is in Userland code, with something that you think should persist but actually doesn't... A resource, session data, an object that got destructed and is now GC-ed, etc are the usual suspects. In particular, if you have any register_shutdown_function or destructors on your classes, note that PHP does *NOT* guarantee any particular order of destruction, nor even consistency of the same from request to request. Once your server gets busy, GC may be kicking in more, and objects you think are still valid in a destructor probably aren't -- they're halfway torn apart by PHP as it shuts down the script. PS Don't try to use echo in a destructor nor shutdown function. http://php.net/error_log is your friend. -- 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] Skipping of defaulted parameters.
On Wed, October 20, 2010 6:58 am, Richard Quadling wrote: foo(10,, 30); // Parse error. I thought this used to work... I would argue that by having a null in the arguments, the intent is to NOT supply a value and have the default value used in the function. Unfortunately, no. There are times when I want to over-ride the default, and shove NULL in as the value... 1 - Do nothing in core and implement is_null() checking to reinstate the default value. I believe that this is probably Best Practice in current PHP. Validate your incoming parameters consistent with the intent of the code-base in question. 2 - Allow null to be supplied and have the default value be used for the argument. foo(10, null, 30); // would output 10, 2, 30 -1 3 - New keyword of default or void to specifically indicate the intent to use the default value for the argument. foo(10, default, 30); // would output 10, 2, 30 This seems reasonable to me. 4 - Allow missing arguments to default. foo(10,, 30); // Parse error. Also reasonable. I'd even say both 34 together are in keeping with PHP spirit, to allow the lazy scripters to use 10,,30 and the formal developers to use DEFAULT. Option 4 would probably be the worse one to go for. Looking any number of languages that support defaults and you will see code like ... someFunction(param1,param7param11) It does get ugly fast for large numbers of arguments... But any function with more than a handful of arguments is already asking for trouble... At that point you should be passing in a data structure / instance / array or something other than so many parameters. Perhaps a constant like PHP_DEFAULT rather than a new keyword? But using something like _ (yep, underscore), could be a solution here [4]. Icky. :-) Option 2, after probably having to reject option 3, would be my choice. I want null to REALLY mean nothing. Just like it would be in foo(10). Alas, NULL behaves more like an actual value sometimes, depending on which functions you use... isset versus array_key_exists, for example. -- 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] Named parameters
On Mon, October 18, 2010 2:45 am, mathieu.suen wrote: On 10/15/2010 07:26 PM, G M wrote: Okay so I am thinking about submitting a patch to PHP that would enable you to call functions like this: stuff(1, 2, 'separator' = 'br', 'clean' = true); When I suggested this to Ze'ev in PHP 3.x - 4.0 days, I believe his response ran along the lines of running away screaming into the night... After a decade of reflection, I think it over-complicates PHP, which we don't really need. Just pass in an array with whatever parameters you want, and tear it apart in the function. You can @document that array in any way you choose, naming all the valid keys, and what they ought to be. -- 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] Using child classes/interfaces as desired type hints
On Thu, October 7, 2010 12:56 am, Nathan Nobbe wrote:
?php
abstract class AbstractServer {}
class ConcreteServer extends AbstractServer {}
abstract class AbstractClient {
abstract function doStuff(AbstractServer $o);
}
class ConcreteClient extends AbstractClient {
function doStuff(ConcreteServer $o) {}
}
?
This results in a fatal
Fatal error: Declaration of ConcreteClient::doStuff() must be
compatible
with that of AbstractClient::doStuff() in
/Users/quickshiftin/gitRepos/timberline/php-api-v15-client/testOverride.php
on line 11
I was reading a few posts from way back when
http://marc.info/?t=10777490481r=1w=2
yet still find myself wondering. I think it can be said here that if
there's a contract defined by AbstractClient::doStuff, that same
contract is
honored by ConcreteClient::doStuff. I also think changing the
language to
support this notion wouldn't raise BC issues for the most part (at
all?)
since at the moment you're forced to move to the lowest common
denominator
in the tree, in this case
class ConcreteClient extends AbstractClient {
function doStuff(AbstractServer $o) {}
}
your feedback appreciated,
I can see why you think it should work, but have you considered all
the possible combinations of children/parent abstract/concrete
classes, and what happens when you do:
class QuickMixClient extends ConcreteClient {
function doStuff(AbstractServer $o) {}
}
class QuickMixServer extends AbstractServer {
}
$quickie = new QuickMixServer;
$client = new QuickMixCilent;
$client-doStuff($quickie);
Kosher? Or not?
It's kosher for the QuickMix doStuff, but does not satisfy the
ConcreteServer requirement of ConcreteClient.
So does PHP need to examine every method on every class, and then
complain at compile time?...
That sounds painful to me...
.
.
.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Comparable interface
On Tue, October 5, 2010 5:44 am, Gustavo Lopes wrote:
On Tue, 05 Oct 2010 04:31:14 +0100, Richard Lynch c...@l-i-e.com
wrote:
On Sun, October 3, 2010 12:34 pm, Gustavo Lopes wrote:
* The current behavior for , , etc. is completely useless. It's
unpredictable and it doesn't even establish a total order:
$a = new stdclass;
$a-prop = null;
$b = new stdclass;
$b-prop2 = null;
var_dump($a $b); //false
var_dump($a == $b); //false
var_dump($b $a); //false
E.
Which one of these would you expect to be true?...
They're sure not equal, right?
And what would make $a or $b greater than the other? I mean, *WHY*
would you expect one of those to be true, if you do expect one of
them to be true?
I sure can't find any logical a priori ordering, total, partial, or
otherwise.
Last time I checked, there was no rule that any set/graph or other
mathematical collection had to have a defined ordering, even
partial.
But it's been ages since I got my Honors Math degree, so maybe they
changed the rule while I wasn't looking... :-)
Without addressing the appeal to authority argument, the problem is
not
that there must be an ordering, partial or total.
The problem is that several algorithms expect a total order criterion
to
exist; a notable example are sorting functions. While many will still
terminate when given a partial order, the results will be
unpredictable.
So basically you have comparison function for objects, but you cannot,
in
general, use it to sort even objects of the same class (seem my
example).
But surely the generic case of an Object simply doesn't HAVE a
partial much less total ordering.
Forcing one to exist because a function exists that requires a stable
full ordering in order to call that function...
That's like forcing any string to be a valid JPEG because you might
feed it to imagecreatefromstring(), in my eyes.
Note that e.g. Java and .NET require a total order, see:
PHP is not Java.
PHP is not .Net
I really don't see a valid reason why any given random collection of
OOP instances would a priori have to have a total ordering available
to them.
Certainly, I can see a zillion cases where domain-specific knowledge
of the objects and a comparison function/operator should be definable.
But I strongly object to forcing EVERY random collection of objects to
have a total ordering. It's creating order where order does not
exist.
It would be somewhat useful to be able to sort objects by some
(arbitrary)
total ordering criterion, e.g. to do a binary search afterwards, but
that's marginal to my argument, which is that the current object
comparison behavior ranges from limited to useless. Therefore, some
addition that would allow the user to give meaningful behavior to the
operators in some limited circumstances (e.g. comparisons inside
classes
with inheritance relationships only) would be a good idea.
I can certainly see why it would be useful to allow it in some cases.
But how tricky is it to write:
function foo_cmp($foo1, $foo2){ ... }
and hand that to usort?
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Comparable interface
On Sun, October 3, 2010 12:34 pm, Gustavo Lopes wrote: * The current behavior for , , etc. is completely useless. It's unpredictable and it doesn't even establish a total order: $a = new stdclass; $a-prop = null; $b = new stdclass; $b-prop2 = null; var_dump($a $b); //false var_dump($a == $b); //false var_dump($b $a); //false E. Which one of these would you expect to be true?... They're sure not equal, right? And what would make $a or $b greater than the other? I mean, *WHY* would you expect one of those to be true, if you do expect one of them to be true? I sure can't find any logical a priori ordering, total, partial, or otherwise. Last time I checked, there was no rule that any set/graph or other mathematical collection had to have a defined ordering, even partial. But it's been ages since I got my Honors Math degree, so maybe they changed the rule while I wasn't looking... :-) -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Comparable interface
On Sun, October 3, 2010 6:18 pm, Stas Malyshev wrote: $a = new stdclass; $a-prop = null; $b = new stdclass; $b-prop2 = null; var_dump($a $b); //false var_dump($a == $b); //false var_dump($b $a); //false That's because there's no total ordering of generic objects that can make sense. Only very specific objects - such as ones representing numeric qualities or having numeric properties - can be ordered, most of objects are unordered. And comparing objects with scalars automagically might bring a lot of surprises as nobody really expects $a == $b and $b == $a to be different now. If you make == not reflexive, I'd be pretty cranky... :-) HOWEVER, here's an idea from left field... If PHP is comparing OBJECTS and cannot discern an ordering, perhaps returning NULL instead of FALSE would make sense. I have NO IDEA if this is do-able, sensible, or reasonable... It just struck me that when PHP doesn't know $a $b should be TRUE/FALSE, returning NULL instead would be a reasonable course of action, from this naive scripter's POV. -- 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
