Re: [PHP-DEV] UPDATED RFC version 1.1: source files without opening ?php tag
Hello, On Wed, Apr 11, 2012 at 11:47 AM, Luke Scott l...@cywh.com wrote: The .php extension really isn't used by PHP, but it's used by a web server to identify PHP code and send it to the interpreter. Any mention of file extensions in the RFC would have to be nothing more than a recommendation. I do understand that if a .php file didn't have a starting ?php it could unintentionally get printed... But it's nothing we can really gurantee. That's why template mode has to remain the default. However, I think it's prudent to provide an environmental variable to let the web server choose what mode to use. That way you can instruct Apache/Nginx to interpret .phpc as pure code mode and .php as the current template mode. The most exciting thing for me in this RFC is disallowing the use of ?. A starting ?php should be optional for portability, as long as it comes first. I wouldn't be opposed to making the starting ?php required in code mode, but that's not what Tom wants. I just want a mode where you don't have ?...?php somewhere in the middle. I occasionally see this, and it just leaves me with a WTF moment (After all we have heredoc/nowdoc). I very much understand how the extension relates to various web servers. The thing is every single distribution, rpm, deb package etc that shared servers and private repos have around the world are configured to use .php. If PHP Version X. releases with a new feature advocating the use of a new extension a burden is placed on those various distributions and package maintainers for security reasons to add this new extension to the web server configurations. Who / how is that being communicated to them? That is why a RFC including extensions as a convention seems a little off / unsafe for me. Again not something I feel strongly about, but something to be considered. When I use get_defined_constants(TRUE); I didn't see any PHP_ constants. There are many built in constants that don¹t' follow this rule, and follow their own conventions. T_* for example is reserved for tokens. If this is indeed a requirement, I don't mind as long as these constants aren't insanely long. But if it's not a requirement, I'd prefer not to have the PHP_*. It's a bit redundant. Most extensions have their own constant space The T_* space parser tokens are listed in the documentation and are registered under the tokenizer space. Some other extensions might may not be highly consistent with how they prefix their constants, that is up to the developer of the extension. However include/require are reserved words and part of the php core, as such it would make sense to me that they would be registered under the core constant name space which is mostly understood as PHP_. No reason this couldn't be deviated from, as UPLOAD_* and ZEND_* have their own spaces, but INCLUDE_* seems pretty generic to reserve and seems safer under PHP_* to me. This is a small detail I don't feel strongly about, but it is a detail that should be considered. -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
Hello, On Mon, Apr 9, 2012 at 10:43 AM, Ralph Schindler ra...@ralphschindler.com wrote: Hey Tom, An idea, why not overload require/include with a second parameter that simply enforces an include mode. For example // in some autoloader (include, requires, and *_onces) include $pathToFile, INCLUDE_MODE_PHP_ONLY; This would tell the parser/executor to start in PHP mode and never leave it, that way, ending tags would throw a runtime/execution error. Other constants and behaviors could be: INCLUDE_MODE_PHP_START; INCLUDE_MODE_PASSTRHOUGH_START; (the current and default behavior) This would have the least amount of impact on BC, and seeminlyg would be a friendly change to the lexer/syntax. Thoughts? -ralph Although I am not very interested in this feature, if it is implemented I like the idea of flags instead of introducing new keywords. Maintaining backwards compatibility would be great considering the benefit to the feature to be completely honest (and in disagreement to many people, but I do understand the reasoning for everyone's interest in it) is extremely minor in my eyes. In addition I would suggest maybe using PHP_INCLUDE_* as a place for these constants to live. -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: source files without opening tag
Hello, 2012/4/9 Ángel González keis...@gmail.com: On 09/04/12 20:23, Chris Stockton wrote: Hello, Although I am not very interested in this feature, if it is implemented I like the idea of flags instead of introducing new keywords. Maintaining backwards compatibility would be great considering the benefit to the feature to be completely honest (and in disagreement to many people, but I do understand the reasoning for everyone's interest in it) is extremely minor in my eyes. In addition I would suggest maybe using PHP_INCLUDE_* as a place for these constants to live. -Chris That would still be a parse error. Either include file.php, 5; or include (file.php, 42); Fails with a parse error about unexpected ',' On the other hand, a new keyword can be written in a backwards compatible way by making it look like a function call in a non-taken branch: *if ( version_compare(PHP_VERSION*, '5.5', '') ) include_once $file; else require_code($file, array( 'once'=true, 'warn' = 'ignore' ) ); I am not sure I am following you here Angel, are you confusing backwards and forward compatibility? I wouldn't expect a feature to ever work forward compatibly. I.E. Can't use traits in php 4 and can't play a blu ray disc in a dvd player. The goal here is that if you have a large code base which has a hand rolled include_code function already, your change is backwards compatible with that code base. Same to be said for any constants, which is why I recommended using the reserved PHP_* space. -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP as a template language
Hello, On Fri, Apr 6, 2012 at 3:08 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 06.04.2012 23:54, schrieb Tom Boutell: On Fri, Apr 6, 2012 at 5:39 PM, Reindl Harald h.rei...@thelounge.net wrote: the who in such cases are ALL developers out there damned can i send you the invoice for my time if your ideas would be realizedß if no shut up! Why is it every single time I see your name in the discussions here it is shortly followed by hostile personal attacks. Do you have no idea how to maintain a level of professionalism when interacting with the opinions and ideas of other developers? Does your company, http://www.thelounge.net/ represent itself in this way? If I was a prospecting customer who had a idea for a relevant technology venture and was willing to pay for it would I receive personal attacks for mentioning something you disagree with? Why don't you act not just like a industry professional, but a decent human being when you talk to people. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Enum proposal (yet another)
Why is it every time this comes up people need to get butt hurt and passionate? Re-read past discussions and provide new arguments or move on. This is likely a feature that will never exist, but don't worry... You can still make websites using PHP :) On Feb 25, 2012 6:59 PM, Kris Craig kris.cr...@gmail.com wrote: Inline, we go --Kris On Sat, Feb 25, 2012 at 4:54 PM, Stas Malyshev smalys...@sugarcrm.com wrote: 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). 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. 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. Your assumption that anyone who disagrees with you must not have read or even be aware of the existence of previous threads on this topic is a good example of your arrogant belittling of and disrespect toward them. Your premise seems to rely on the notion that, since this was previously discussed but not implemented, this idea was resoundingly rejected. 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. remotely like that. On the contrary, the PHP language would remain largely unchanged; we'd merely be adding a new element to it. 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. The same logic you're using could be used to say that solid OO classes shouldn't be implemented because it would then render procedural scripting impossible. After all, all parts influence each other, as you put it. However, everything didn't blow up when PHP 5 was released. People can still write purely procedural code just like they did before. Language is complex, yes; but it is also flexible. We've already discussed previously in this thread how these interactions between strinct and dynamic functions could take place. So, your argument that this would be guaranteed to blow up in runtime and that, therefore, we would be stuck with a purely
Re: [PHP-DEV] A potential patch for Bug#60668
Hello,
On Wed, Jan 25, 2012 at 5:43 PM, Kiyoto Tamura m...@ktamura.com wrote:
vrana has raise a good point in a potentially dangerous behavior with
ini_set() in https://bugs.php.net/bug.php?id=60668.
Here is my proposed patch. Feedback is appreciated. Thanks!
Kiyoto Tamura
diff --git a/Zend/zend_ini.c b/Zend/zend_ini.c
index a7ec5d7..89b1287 100644
--- a/Zend/zend_ini.c
+++ b/Zend/zend_ini.c
@@ -83,6 +83,23 @@ static int zend_restore_ini_entry_wrapper(zend_ini_entry
**ini_entry TSRMLS_DC)
}
/* }}} */
+static uint zend_trim_after_carriage_return(char *value, uint value_length)
/* {{{ */
+{
+ uint ii;
+ char prev_c = '\0', curr_c;
+ for (ii = 0; ii value_length; ++ii) {
+ curr_c = *value;
+ if (prev_c == '\r' curr_c == '\n') {
+ return ii - 1;
+ }
+ prev_c = curr_c;
+ ++value;
+ }
+
+ return value_length;
+}
+/* }}} */
+
To comment specifically on the patch itself; I am not sure you need a
new zend func here, I think it would be more convenient (and safer) to
use php_trim in standard/string.c. Although I must say looking at the
bug, I am not sure this is exactly something that should be fixed.
It could be a BC break and in my opinion is just a demonstration of
failure to properly sanitize user input as opposed to a security flaw
in php design itself.
-Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A potential patch for Bug#60668
Hello, On Wed, Jan 25, 2012 at 9:32 PM, Kiyoto Tamura m...@ktamura.com wrote: Also, I am not sure if php_trim is what we want here. It looks like vrana's initial proposal was to discard everything after CR-LF. This is different from trimming CR/LF/whitespace at the end of the string. Ah I see didn't think enough about it, basically my point is for such a simple string op there is likely something already to do it, probably still is a function in strings to take care of it. As for the feature of \r\n working in user-agent init set, my main point is that is a BC break, since it is slightly advocated to use it as a hack in the docs here [1]. At the end of the day passing _any_ user input to literally any php function without sanitization can be dangerous given the right context. I think this specific one would fall under the developers hands, but hey it's just my opinion you can see what the core devs say I might be a bit off base. -Chris [1] http://php.net/wrappers.http#wrappers.http.example.custom.headers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP website having issues?
Hello, is it just me or is the php website having issues doing function lookups etc? I checked several mirrors and they return no results for many functions and many links from Google are broke to. Just a heads up.
Re: [PHP-DEV] Phalanger
Hello, On Thu, Dec 8, 2011 at 4:28 PM, Rasmus Schultz ras...@mindplay.dk wrote: Don't take this the wrong way, I'm merely trying to provoke your thoughts a bit with this e-mail! :-) Has it occurred to anyone, to abandon the official PHP codebase and adopt Phalanger instead? Some convincing (to me) points: - Phalanger runs on Mono, meaning similar platform-reach as PHP. (but eliminating most platform-specific implementations.) - It's fast. (probably fast enough to mostly eliminate the need for native extensions in general.) - The community would be able to write modules/extensions in PHP or other CLR languages. - It's secure. (not that C/FFI PHP extensions tend not to be trustworthy, but they do tend to come from a relatively small group of authors.) - Access to more languages means a much bigger community who can contribute extensions and core patches. - Access to existing CLR codebases means more third-party libraries can be readily integrated without writing and maintainting C/FFI wrappers. - The codebase is new, clean and modern (it's not dragging around a lot of legacy baggage.) - Fully take advantage of new 64-bit hardware (vector computations and larger address space) in all aspects. (core, extensions, PHP scripts). I'm not going to try to sell you on the fact that the integration with the Windows world is tighter in Phalanger than in PHP - but it is a point that carries considerable weight to many businesses. People I know have had a tendency to view Phalanger as PHP for Windows - it's really not. It's PHP for CLR - and CLR is not (only) Windows. And it is readily available on most modern operating systems with good support for various hardware platforms. Now, before you start flaming me - I'd love to hear precisely why you're eager to hang on to the C codebase. What are the benefits of the C codebase over Phalanger? I understand the licensing may be an issue. It may be the argument that outweighs everything else, but I'm curious to hear what else would keep you from moving to Phalanger? I am not sure the response you are expecting, suggesting to abandon the PHP project with over a decade of tried and proven work to architecture that prohibits a great portion of the implementations very attraction for a majority of large projects... furthermore doing it on a list full of the very developers who have put in all this time and effort is almost a bit ridiculous. If PHP ever took away my freedom to write efficient C extensions for domain specific problems, library integration or was better favored to a windows world I would unfortunately have to move to another technology. I would like to make note in no disrespect to anyone that I think some graphs showing some bars larger then others, are meaningless to me in the current state of technology. I haven't had to write a C extension for performance improvements in years. Scaling web applications is just so easy, the bottlenecks are almost NEVER in the web tier anymore and when it does reach capacity provision a new web box and voila. What is expensive ($$) is data storage and network communication (performance) to external service providers (fb api, openid, twitter, internal enterprise services, pick your api). Just a couple thoughts from me and my experience, in a nut shell it's great to see work on alternative implementations that better fit a specific group or set of groups problem domains, but such a drastic statement as to drop the current implementation and start anew is pretty far away from logical :- ) -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] who can vote
Hello, On Thu, Nov 10, 2011 at 11:45 AM, Pierre Joye pierre@gmail.com wrote: We are not talking about giving a voice to totally irrelevant people but well known PHP project leaders, who already contribute to PHP in one way or another. We are not either talking about them telling us what to implement, or what to do next. That won't change and did not change for what we have done in the past, as you can see in 5.4.0. I would like to chime in by saying pretty much anyone who posts to this list is taking time out of there schedule and if the feedback is constructive, that person is relevant. If they own a fortune 500 company, or are a jr developer for a small startup, they are surely providing feedback that is valuable to the PHP Group and to introduce a method of measurement of a voices worth is only going to further widen the communication gap we have seen in the past; that has recently seen small measures of improvement. I think voting on features shouldn't be so cut and dry as it is looked at now. Really there should be two parts, first each person who responds to this list should count towards measuring the php communitys desire for a given proposal. That is really the only way give PHP the community feeling you would expect from a open source project, this will also provide people with motivation for contributing what just may be PHP's next best thing. The second part is adoption and implementation, it isn't fair or even possible to implement every feature that has overwhelming community support, so a core contributors sponsorship is required, this is basically what we already see now for most things. By what I am reading, we are just cutting out the community voice through arbitrary measures of importance. The long story short, start nit picking the importance of community feedback and I see it having a negative impact on PHP. The last thing I want to do is see people start sending resumes to the list to have there votes count. -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Time zone database shut down by legal threat
Hello, On Thu, Oct 6, 2011 at 4:45 PM, J. Adams zardozro...@gmail.com wrote: Perhaps we could all contact Astrolabe and voice our complaints? http://alabe.com/ Not sure how copyright can apply to time? If so put me in for copyright on Mondays.. once I own them I can get rid of them forever! But really, I believe the claim seems to have little ground to stand on in. -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bug with static property access
Hello, On Tue, Oct 4, 2011 at 11:28 PM, Christian Kaps christian.k...@mohiva.com wrote: It's available since PHP 5.3. This feature is called late static binding. Before anyone else responds to my post, please read the entire message! It's simple really, the error message is odd and misleading for the example code I gave. In addition I pointed out later in the thread that LSB is not supported for class constants, something that could perhaps be added, although it is likely disabled as a (good) design decision, I could see use cases where it would be useful. Thanks, -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Bug with static property access
Hello, On Tue, Oct 4, 2011 at 11:33 AM, Matthew Weier O'Phinney weierophin...@php.net wrote: That makes complete sense to me -- ClassA is referring to self, which resolves to ClassA... which does not define a VERSION constant. Change to this: public $version = static::VERSION; and it should be fine. Hi Matt, I knew what was wrong with the code as soon as I saw it :- ), the code itself was part of a much more complicated system and I was using it in a unexpected way. The reason it was difficult to troubleshoot is because the constant being whined about was not any (of the several) constants being evaluated at the line the error was for. I think the error should be thrown at compile time, not at runtime ONLY when a constant is being accessed. This could cause dangerous hard to catch errors that make it into production. In addition, as I understand and would like to make you aware that static is not allowed in compile time class constants. Which is slightly unusual and perhaps could be changed because it seems that there is already runtime resolving taking place here. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug with static property access
Hello,
I noticed the following odd behavior earlier today, there is
definitely a bug here in my opinion, the bug is either the error
message or the behavior. I think the behavior is possibly expected.
I'll let some others comment.
The reason I think the error is odd is because it is very misleading
in a much larger code base (what I was debugging) you go to the line
it is complaining about and are perplexed because you are not
attempting to access the mentioned constant. I'm sure the engine does
some kind of lazy/runtime determination that causes this, that area
may need a look at?
Example:
?php
abstract class ClassA {
static protected $_cache = Array();
public $version = self::VERSION;
final static public function MethodOne() {
return __METHOD__;
}
final static public function MethodTwo() {
self::$_cache;
return __METHOD__;
}
}
abstract class ClassB extends ClassA {
const VERSION = 1;
}
var_dump(ClassB::MethodOne());
var_dump(ClassB::MethodTwo());
?
// prints
string(17) ClassA::MethodOne
Fatal error: Undefined class constant 'self::VERSION' in
SNIP/testbug.php on line 14
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Revert Tokenizer behavior for 5.4
Hello, On Thu, Sep 15, 2011 at 8:13 AM, Nikita Popov nikita@googlemail.com wrote: On Thu, Sep 15, 2011 at 5:05 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: Wait wait wait. Thats the point here? __COMPILER_HALT_OFFSET__ already tells you where the data starts. __COMPILER_HALT_OFFSET__ tells you the offset if you are running the file. It is only available in the file that does the actual __halt_compiler(); statement. When using the Tokenizer (this is what this is about; this is *not* about PHP's own lexing/parsing behavior) you don't have that constant available. Though, again, I don't think the second patch is strictly necessary. I'd be happy without, if it creates too many problems / is not intuitive. Nikita What I am really hearing in this thread is some people have interest in a way to easily access the __COMPILER_HALT_OFFSET__ offset from another file's context. Why don't we simply create a function for this? Something like get_compiler_halt_offset(filename) or a similar function specifically for this, maybe a function which returns the data after the offset or a combination of the two. Whatever solves these use cases. Then the tokenizer may stay precisely what it is, a tokenizer. Changing the behavior of the tokenizer based off the contents of the file seem very incorrect to me. -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] transversing associative arrays from C
Hello, On Thu, Aug 25, 2011 at 2:57 PM, Aaron Gray ang.use...@gmail.com wrote: Hi, I am working on a C extension module for PHP and am wondering about an API issue. I can see how to add to an associative array :- Most everything you need to know about manipulating arrays can be found in ext/standard/array.c -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Function autoloading through spl_autoload*
Hello, On Mon, Aug 15, 2011 at 2:30 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2011-08-14, Derick Rethans der...@php.net wrote: On Sat, 6 Aug 2011, Ferenc Kovacs wrote: I would like to introduce this RFC which would provide function autoloading through the spl_autoload facility without userland BC breakage. https://wiki.php.net/rfc/autofunc I must say a few of the suggestions I have seen appear a bit odd, however I believe that the proposed RFC suggestion using SPL is perfectly in alignment with how I would expect auto-loading to work. This would be a nice feature to have for a lot of code bases I am sure. -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Function autoloading through spl_autoload*
Hello Stas, On Mon, Aug 15, 2011 at 1:26 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! It's not a shortcoming, it was designed that way, and for very serious reasons. If you want to know the reasons, there were discussed extensively when namespaces were discussed. Please re-read that discussion. And all things you propose now were already discussed back then too. If you hope people would write \strlen instead of strlen, this discussion is pointless because it won't happen. -- I see your viewpoint from a architectural/design perspective and they are valid, but I think the impact and design could be lightened with some simple rules of precedence. I think it would be fair to say, autoloader will not be called on a function like strpos, or any builtin compiled extension. Only once those are cycled through will autoloader for functions be called. At this point the performance penalty doesn't exist, because at this point the program execution would have halted with a fatal error anyways. -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] The behavior of get_object_vars and array casting when extending ArrayObject
I was curious if this behavior was expected, it caught me by surprise.
A base object I use extends ArrayObject, that class is extended
heavily throughout my code and I recently wanted to use
get_object_vars, but noticed it returning an empty array. I do not
expect get_object_vars to return the properties I set via a
ArrayObject, but I would expect explicitly defined properties in
sub-classes and even in the ArrayObject extending class to be
returned. Is this thinking correct? If everyone agrees this is a bug I
can report it and write a patch assuming its not a deep complicated
problem.
--Code
class TestOne {
public $TestOne_1 = 1;
}
class TestTwo extends ArrayObject {
public $TestTwo_1 = 1;
}
class TestThree extends TestTwo {
public $TestThree_1 = 1;
}
$t1 = new TestOne;
var_dump((array) $t1, get_object_vars($t1));
$t2 = new TestTwo;
var_dump((array) $t2, get_object_vars($t2));
$t3 = new TestThree;
var_dump((array) $t3, get_object_vars($t3));
--Produces
array(1) {
[TestOne_1]=
int(1)
}
array(1) {
[TestOne_1]=
int(1)
}
array(0) {
}
array(0) {
}
array(0) {
}
array(0) {
}
Thanks,
-Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] The behavior of get_object_vars and array casting when extending ArrayObject
Hello, On Thu, Aug 11, 2011 at 11:58 AM, Etienne Kneuss col...@php.net wrote: Hello, ArrayObject extends the handler responsible for giving you such information. So it might very well be a bug. You should report it! Best, Thanks Etienne, I went ahead and made a bug report and patch here: https://bugs.php.net/bug.php?id=55406 -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Hello, On Thu, Aug 4, 2011 at 1:53 PM, Ferenc Kovacs tyr...@gmail.com wrote: so as I see you didn't really addressed the proposed use-case of the Weak References, just stated what everybody is aware of: one can cache and free objects manually without the need of Weak References. and while that is true, I still think that this could be a great asset for creating high quality components. I myself oppose WeakReference in java and I do not see my opinion changing for PHP ... unfortunately I think WeakReference's are even nastier in PHP because of it's error handling. You see it is very common when weak references are used in java too follow one of two paradigms, fall through with NPE's, or state/null checks. With PHP, you may not test the validity of a weak reference simply by accessing it, you will get a uncatchable fatal error. So in PHP your only option when consumers are obtaining weak reference handles, is to check their validity before use, whether that is a call into some registry, or a null check of the reference itself, whatever.. it still leads to checks to make sure that reference wasn't collected. This added complexity in the WeakReference consumer makes me unable see any purpose through the inconvenience and unpredictability they bring. btw. it was suggested before, but I really think, that it would be a good idea to have a register_ function which would allow you to pass a callable, which will be called when the memory usage reaches a given value. that would make a good addition to resolve some of use cases mentioned in this thread. I use ticks to do this in a CLI daemon I wrote, worked out pretty well. Not saying a specialized function isn't needed but I think ticks aren't to far from convenient to require such. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Hello, On Tue, Aug 2, 2011 at 11:06 AM, Hannes Landeholm landeh...@gmail.com wrote: I've talked to Etienne and he still believes we should vote on this so the vote is still up. He just replied to quickly. If the vote fails the patch can still be implemented in a PECL extension. There's no point canceling the vote or the RFC - it's still valid and ongoing, and there is still time for discussion. .. snip ... I think at this point everyone is well aware that you would like this feature implemented. I would like to make a couple points here, first I is that PECL is not a place for a extension to rot, that statement makes absolutely no sense to me. PDO I recall years ago getting from PECL, Http a extension I often use, was recently on this list if I recall to be moved into the core. I'm sure there are plenty of people on this list that were part of extension's PECL - CORE lifecycles that could add several more examples to the list. I believe PECL Would be a great place for something like this that was is entirely understood or has overwhelming support in my opinion. I am really not sure how comfortable I am with a feature as new as this being in the PHP on my servers. Some form of incubation, testing and use feedback only makes sense to me. Second I would like to talk a little bit about weak references for those who are not familiar with them or have thus far only read your very strong pro-opinion. I would like to make it very clear with the simple fact that weak references are not required, ever by any language. They are a convenience, not a solution to a unsolvable problem. I believe that if anything weak references encourage laziness in design, it causes the referential integrity that I am accustomed to is broken, and can often lead to more code and checks then it relieves. It is very easy to run into unexpected bugs and in a language like PHP, where you don't get a NPE when you try to access a NULL method of a non object, you get a fatal error, this doesn't seem very appealing to me. Only under very specific cases of caching patterns as you have previously mentioned is such a pattern even recognized to -have a place for use that isn't just plain wrong- -not a requirement- by me. In PHP, I believe a web or cli app that uses enough resources to bomb memory limits on a server, needs to be re-factored. I have definitely written multi-process PHP daemons that go to disk or over the network for taxing operations that need cached and had very little trouble with rudimentary memory management patterns, so from my perspective I can't really see why given the toolset PHP provides that this is such a problem. This is just my opinion, I don't have a strong opposition to this feature, anything new to PHP I usually get excited about, I simply wanted to give a few counter arguments as the fact that this feature is being presented as a dire and long over due missing feature to the language is a bit dramatic. Not saying its useless and doesn't belong in PHP or I would never want it to exists, I just would hate to see something rushed through that didn't get a bit of testing and typical QA from a language that affects millions of people. -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Variable scopes for language constructs (foreach, ...)
Hello,
On Thu, Jun 23, 2011 at 8:49 AM, Martin Scotta martinsco...@gmail.com wrote:
Martin Scotta
foreach ($values as $value) {
// use $value
}
unset ($value); // -- unset done inside core
foreach ($values as $key = $value) {
// use $key and $value
}
unset ($key, $value); // -- unset done inside core
will this just do the trick?
I think proposed change is extremely counter intuitive to the design
of PHP in regard to scoping and would be a very large bc break, PHP is
doing exactly what it is suppose to do here and I wouldn't want it any
other way.
-Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [IDEA/PRE-RFC] PHP Core Mentorship Program
Hello, On Fri, Jun 10, 2011 at 9:39 AM, David Coallier dav...@php.net wrote: Hey all, Let me start by saying that this is merely an idea I'm trying to put together and before doing so, I need to see who would be interested. First let me start by saying I like the initiative to get more active internals development. If you ask me, PHP could be much better if it was easier to participate and the system for doing so was better. One key I think to your proposal is the mentors portion, if I had direct access to a developer with karma I would much more inclined to help and submit patches. One thing that should be remembered about open source projects is the only real incentive a mentee has for working on it (for most) is that little bit of satisfaction gained from contributing a small piece to a project that you regularly use or believe in. I personally have tried several times over the years to get more involved but patches usually sit for months, or years inside the bug tracker till they are out of date or fixed by a core developer. Even submitting them to this list ends up rotting at times (I.E. [1]). This ends up being discouraging and likely has blocked me from making some serious contributions, I know I am not alone here. There are plenty of developers who may know the internals of PHP very well from working for private companies or recreational hacking, but feel such a resistance or large gap between core developers and themselves they give up or move on. Couple things I would love to see from this program, and in general.. - It would just be great to work out some heavier internal documentation. C Code is good documentation I get that, but would be nice for some high level documentation on the more cryptic areas of PHP (zendmm, execution life cycle, etc) - Process for new developers to get their patches and work in, the bug tracker could be this maybe it just needs more eyes? I want to make it clear that I have been very pleased to see all the RFCS that developed over the years and the gap between core developers and everyone else has seemed to close a lot. I hope this continues and some of the kinks of this idea are worked out of this Mentor/Mentee program and it develops into something great so we can see faster adoption of new technologies into PHP and maybe some kind of target zero goal for all bugs. -Chris [1] http://marc.info/?l=php-internalsm=125589606407945 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
Hello,
On Mon, Jun 6, 2011 at 12:41 PM, Hannes Magnusson
hannes.magnus...@gmail.com wrote:
Hi
As quickly mentioned in the '$arr = array('Hello', 'world'); $arr();'
thread[1], we are hitting the need for a callable typehint.
This brings a clear and concise enhancement to PHP which I would
benefit from .I have been watching our API provide more and more
functions with callbacks as arguments and it would be nice to have a
specific type for those to clean up the is_callable error handling.
It is my opinion that comparing it to previous type hinting proposals
is like comparing apples and oranges. I think it falls in align
justification wise between Class Name and Array type hints.
I.E.
function test1(StdClass $p) ..
function test2(Closure $p) ... == doesn't this seem more justified
then Array given the argument of previous type hinting proposals?
function test3(Array $arr)
+1 from me
-Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
Hello,
On Mon, Jun 6, 2011 at 3:51 PM, Chris Stockton
chrisstockto...@gmail.com wrote:
Hello,
On Mon, Jun 6, 2011 at 12:41 PM, Hannes Magnusson
hannes.magnus...@gmail.com wrote:
Hi
As quickly mentioned in the '$arr = array('Hello', 'world'); $arr();'
thread[1], we are hitting the need for a callable typehint.
This brings a clear and concise enhancement to PHP which I would
benefit from .I have been watching our API provide more and more
functions with callbacks as arguments and it would be nice to have a
specific type for those to clean up the is_callable error handling.
It is my opinion that comparing it to previous type hinting proposals
is like comparing apples and oranges. I think it falls in align
justification wise between Class Name and Array type hints.
I.E.
function test1(StdClass $p) ..
function test2(Closure $p) ... == doesn't this seem more justified
then Array given the argument of previous type hinting proposals?
function test3(Array $arr)
+1 from me
-Chris
s/Closure/Callable/g
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
Hi Stas,
On Mon, Jun 6, 2011 at 4:02 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
I wouldn't love it a bit, frankly, as rely on PHP's native error handling
in this context means bombing out in runtime without any idea what went
wrong. When you have exception, you could make it print what happened and
recover, if you want. When you have fatal error, you can't do much at all.
The patch as you probably know throws a E_RECOVERABLE_ERROR, which in
my humble opinion doesn't quite fall under the end-of-world category
you seem to explain there :- )
I.E.
function bar($a, $b, $c, $d)
{ return true; }
set_error_handler(bar);
class Foo
{
public function test(Array $arr) {}
}
$foo = new Foo; $foo-test('invalid');
echo Everything will be okay.. :p;
-Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object and Array Literals
Hello,
On Sun, Jun 5, 2011 at 2:03 PM, Jordi Boggiano j.boggi...@seld.be wrote:
Thanks for working on this.
On Sun, Jun 5, 2011 at 3:30 AM, Sean Coates s...@seancoates.com wrote:
Please read, and if you have a comment that is not already covered in the
RFC, raise it here. I'm definitely open to discussion, but I would really
love to keep this discussion civil.
TBH, I dropped half-way through the original topic, so I'm sorry if I
missed something, but why don't we just treat {foo:bar} as an
array? json_decode() can do it, and it makes complete sense since PHP
arrays are hashes too. I don't see much benefit to having this create
an object by default, especially since even if you use that notation
to send data to a JSON API, json_encode'ing a hash will create an
object.
It's the only pain point I really have, that I can't use true
json-syntax without ending up with this messy pile of objects/arrays
mixed together. If we do this, IMO the hashes should not be able to be
defined with [], but that'll probably upset people, so I don't really
care if it is possible.
• Strictness of unquoted keys.
This is just legacy crap honestly, if we make up new syntax, we
shouldn't include the old mess in it. I think everyone is quoting
their strings by now..
• Support = in addition to : as a key:value separator.
Same as my point on [] above, I think adopting the JSON notation
should be done fully, keeping this stuff in might be ok to make people
happy, but it does not make much sense.
• possibility of simply not supporting the \u### syntax for Unicode
characters in literal strings (just like the rest of PHP).
This is still PHP strings, they should behave as such. Sounds good to me.
• Should mixed-format (numeric and associative arrays) be allowed?
(e.g. [1,'two':2, 3])
Assuming we keep [] to arrays and {} to hashes as I said above, I'd
say no. In the rare cases that it is useful you can still use array()
if you really feel this is necessary..
I'm sure many people will disagree with this, and I don't really mind
how it ends up syntactically speaking, but please really consider
dropping the stdClass part, that'd really suck :/
Cheers
I think there is a clear benefit to allow {} as well as [] being
StdClass and array respectively. However, I understand your point as
well as the point of others when they speak of the usefulness of
StdClass, really this tells me perhaps we should look at adding some
basic enhancements to StdClass (I.E. some methods for example), or
perhaps a new class for default object creation. At the very least
maybe a way to specify the default class.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
Hello, On Wed, Jun 1, 2011 at 10:19 AM, Pierre Joye pierre@gmail.com wrote: Reminder: Pls add your votes here: https://wiki.php.net/rfc/shortsyntaxforarrays/vote May I please have wiki rights restored to my user cstockton if possible, I would like to vote. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
Hi Lester, On Wed, Jun 1, 2011 at 11:19 AM, Lester Caine les...@lsces.co.uk wrote: Chris Stockton wrote: Reminder: Pls add your votes here: https://wiki.php.net/rfc/shortsyntaxforarrays/vote May I please have wiki rights restored to my user cstockton if possible, I would like to vote. It would seem some people have not been watching the news? http://www.php.net/ top news item ... But it would seem that the 'change password' processes is not being flagged properly? I did read that a couple months back, reset my password and logged in numerous times since (I am logged in now). However I am not able to edit articles anymore (or maybe never could?). Getting that access would be appreciated. Thanks, -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
Hello, On Wed, Jun 1, 2011 at 1:37 PM, Michael Shadle mike...@gmail.com wrote: On Wed, Jun 1, 2011 at 1:01 PM, Pierre Joye pierre@gmail.com wrote: 5 character difference for each array being saved. That's it. At the expense of syntax highlighters, IDEs, books, all becoming outdated and need to be updated. For a language construct that has been around for what, 10 years? My desire and perhaps the viewpoint of many others to use : over = has very little to do with typing a extra character. This feature I have seen brought up on the list time and time again, some 8 years ago being the first. Just recently more people are in favor of it I'm sure largely due to the common use and readability of JSON. I understand this discussion is for array shorthand syntax.. but I think really people just want to define their data structures like they do in JSON, I would hate to see such a common and familiar syntax be changed just for the sake of principal/familiarity. The take away from this is simply: I think we would be butchering a very clean, precise and extremely familiar syntax if we use = just to be PHP. -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
Hello,
On Wed, Jun 1, 2011 at 2:17 PM, Anthony Ferrara ircmax...@gmail.com wrote:
Personally, I think focusing on a character savings is the wrong
reason to take on any problem. I don't care how long it takes for me
to type code. I don't care how much extra hdd space it takes. But
what I do care about is how readable it is.
To me, the array shortcut syntax is pointless. Do you really mean to
tell me that `[1, 2]` is more readable/easier to understand than
`array(1,2)`? To me, it's about a wash.
However, the object shortcut syntax is a major win. For example:
$person = new stdClass();
$person-city = 'ogden';
$person-state = 'ut';
$perspn-country = 'usa';
$person-favoriteNumbers = array(4, 12, 37, 42);
$person-somethingWithNumbers();
$person-unluckyNumbers = array(6, 13, 21);
$person-likesPhp = 'very much so';
vs
$person = { 'name' = 'Justin',
'city' = 'ogden',
'state' = 'ut',
'country' = 'usa',
'favoriteNumbers' = [ 4, 12, 37, 42],
'unluckyNumbers' = [ 6, 13, 21],
'likesPhp' = 'very much so'
}
Did you notice what happened there? There's two differences. Try to
find them. Neither would be possible with the shortcut syntax.
I don't think doing this is a very big deal, even in the case of Array().
$person = (object) [ 'name' = 'Justin',
'city' = 'ogden',
'state' = 'ut',
'country' = 'usa',
'favoriteNumbers' = [ 4, 12, 37, 42],
'unluckyNumbers' = [ 6, 13, 21],
'likesPhp' = 'very much so'
]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
Hello, On Tue, May 31, 2011 at 11:42 AM, Brian Moon br...@moonspot.net wrote: https://wiki.php.net/rfc/shortsyntaxforarrays Since this was brought again recently by Rasmus (http://markmail.org/message/fx3brcm4ekh645se) and on Twitter where several people including Andi chimed in on it and Ilia seemed to reverse his thoughts as well (with caveats), I thought I would start a real thread about it. The reason the RFC stalled was stated as: I am very much +1 for this. I would also like to note the sooner we get it in the sooner it can actually be adopted as most hosting providers are a couple years behind of latest release, so I hope we can build some momentum this time around and get a solid feature that the user base wants. In addition I think the Square bracket array shortcut - keys and values are separated by colons: is the way to go. Thanks, -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] proposed access modifier silent ... was: Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
Hello,
On Mon, Apr 11, 2011 at 11:47 AM, Matthew Weier O'Phinney
weierophin...@php.net wrote:
On 2011-04-11, Stas Malyshev smalys...@sugarcrm.com wrote:
I might come off rather crumudgeonly here, but these last few
threads I've seen going across to silence notices have a common
theme - I wanna be a lazier coder.
My suggestion to use ?? I will say has little to do with laziness. I
would be happy with any solution that solves my problem, I just know
that implementing a patch for ?? would be simple enough (I could even
do so if requested). Everyone has different use patterns as shown in
other examples, this is natural and just comes with the domain.
However, you may find 415,000 reasons why this feature could be useful
for developers in [1].
I also really like the whatevername($foo['not exists'], $config['not
exists'], $foo, $bar, 'default') function. I personally only usually
need 1 default value but I feel like many people may find uses for
this as well.
In addition I would like to mention that the checking being isset
for such a feature would be a very reasonable option, seeing as empty
[2], array_key_exists [3] (7000 uses found only) etc type use cases
are probably going to be a big minority. Most of the time checks done
with empty() seem to be done on known or already isset() checked, I.E.
isset($foo['bar']) !empty($foo['bar']) anyways.
Just some food for thought,
-Chris
[1]
http://www.google.com/codesearch?hl=enlr=q=.*isset\%28.%2B%3F\%29[\s]{0%2C1}\%3Fsbtn=Search
[2]
http://www.google.com/codesearch?hl=enlr=q=file%3A.*php+.*empty\%28.%2B%3F\%29[\s]{0%2C1}\%3Fsbtn=Search
[3]
http://www.google.com/codesearch?hl=enlr=q=.*array_key_exists\%28.%2B%3F\%29[\s]{0%2C1}\%3Fsbtn=Search
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
Hello,
On Thu, Apr 7, 2011 at 3:03 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 4/7/11 5:59 PM, Matthew Weier O'Phinney wrote:
It may change the semantics as they stand, but I'd argue that the
_expectation_ from the shorthand ternary is to shorten code that
currently uses isset(). As it is, I have almost no use for it at this
point, as I end up needing to do:
I don't think that changing it to do a implicit isset really fixes the
reason developers use it as previously mentioned. My code is littered
with isset checks, I would rather see a syntax or operator
specifically for this purpose, like ?? since ?: has already been
implemented in a different (and in my opinion in all to many cases not
a useful) way. Syntax doesn't matter to me though long as it serves my
purpose.
$var = Array('foo' = 'I am set');
$value = $var['foo'] ?? 'Foo was not set'; // value = I am set
$value = $var['bar'] ?? 'Bar was not set'; // value =Bar was not
set; !!no warning!!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] A quick consensus on magic method idea
Hello,
I haven't seen a magic method proposed in a while so I am not sure how
people feel about them, obviously adding them can break BC (although
it is recommended people should not use __). I'm sure a good amount of
use/desire needs to be shown for inclusion. Here is what I decided I
would like to have and just implemented:
Loader.php:
--
class Loader {
static public function __compiled() {
echo I was ran at the end of zend_do_end_class_declaration;
}
}
Run script:
?php
include Loader.php;
Prints:
I was ran at the end of zend_do_end_class_declaration
At first thought I figured this would be pretty simple to implement,
which it is.. for a basic use case. It seems I will need a bit more
work to handle issues when you do certain things inside __compiled. If
anyone has any interest I would fix it and make a clean patch, so
would anyone find this useful?
-Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A quick consensus on magic method idea
Hello,
On Thu, Feb 3, 2011 at 8:38 PM, Ben Schmidt
mail_ben_schm...@yahoo.com.au wrote:
Do you yourself have any situation where this is useful? Does it solve
some problem? Does it enable you to do things better than before?
Ben.
It does not provide a solution to a currently unsolvable problem, it
is simply a convenience for situations when you want a class to
perform any kind of initialization directly after compilation/loading
(whatever term you find easier on the ears).
It provides a cleaner more encapsulated approach to a (not entirely
uncommon) case such as:
Foo.php:
class Foo {
// class body
}
Foo::registerSomeStuff();
Just a idea I wanted to share,
-Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A quick consensus on magic method idea
Hello, On Thu, Feb 3, 2011 at 8:53 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: This creates problems for opcode caches since the classes are all precompiled and usually optimized to the point where the opcodes that loads them are NOP'ed away and you just have the full class table cached in memory for each op_array. Walking through that class table on every request and looking for these magic methods to call would be quite annoying, especially since most of them wouldn't have such a method to begin with. That is a good point and something I didn't think about. The pain that would create immediately negates the small luxury it would add. Thanks, -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] fix extract w.r.t GLOBALS again
On Fri, Nov 19, 2010 at 8:43 AM, Joe Orton jor...@redhat.com wrote: The check to prevent extract() overwriting $GLOBALS got broken at some point - here's a fix: I remember http://bugs.php.net/47409 for this some time ago and seeing it marked applied. After taking a peak it looks like the patch in the bug report was ignored. One more reason why I stopped contributing I guess. -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] deprecation status of $str{42} versus $str[42], revisited
Hello,
On Wed, Sep 22, 2010 at 2:34 PM, Philip Olson phi...@roshambo.org wrote:
Greetings geeks,
Also, Andi mentioned[1] the possibility of optimizing {} for string use (the
original intent) in which case keeping {} would be wise.
It was over two years ago I commented on my interest in keeping {} and
offering/exploring the potential to performance or feature
improvements to the syntax, I still have the same opinion personally.
-Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Allowing an array as a parameter for snmpget()/snmpgetnext()
Hello,
On Mon, Sep 20, 2010 at 2:17 PM, Michael Maclean m...@php.net wrote:
On 20/09/10 20:46, Jorrit Kronjee wrote:
Dear list,
To better reflect the behavior of the snmpget command that comes with
the Net-SNMP package the patch attached makes an array of OIDs as a
parameter for the snmpget()/snmpgetnext() function possible.
snip
Looks good to me, for what it's worth. Anyone got objections?
I think the patch at a first glance looks good, although it is a minor
cosmetic nitpick, I did catch a line with a couple of extra
semi-colons.
static void php_snmpv3(INTERNAL_FUNCTION_PARAMETERS, int st)
{
- char *a1, *a2, *a3, *a4, *a5, *a6, *a7, *a8;
- int a1_len, a2_len, a3_len, a4_len, a5_len, a6_len, a7_len, a8_len;
+ char *a1, *a2, *a3, *a4, *a5, *a6, *a7, *a8;;
+ int a1_len, a2_len, a3_len, a4_len, a5_len, a6_len, a7_len, a8_len;;
This patch does move around a bit of code, are there some tests to go
along with this patch?
-Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] inheritance check too strict?
Hello, On Thu, Aug 19, 2010 at 12:33 PM, Nathan Rixham nrix...@gmail.com wrote: Guys, this is going a bit nuts, let's swap all the Foo and Bar's for a real example - Zeev I've copied the way you specified above. I think your misunderstanding his position. To summarize my understanding: he clearly states that in such a use case a warning is in order, however currently the warning is overly aggressive. I think in general this is a small fish in the pond but I see his point. Kind Regards, -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
My biggest issue as a user is the fatal errors. Why are we blowing up on something that should throw some kind of useful argument exception? I end up in my applications using instanceof everywhere because their is important cleanup to be done before the end of the request. For example I can't afford for php to just blow up in our account setup script, we are reaching out to multiple non-transactional external resources. Some of our long running command line processes have the same issue. I am all for type hinting but the fatal errors or catchabale fatal errors are just silly. Exceptions make so much more sense to me. -Chris On May 29, 2010 10:19 AM, Zeev Suraski z...@zend.com wrote: At 11:33 29/05/2010, Sebastian Bergmann wrote: The optional scalar type hinting [snip] Sebastian, I understand why proponents of strict typing are putting 'optional' next to it to suggest that people don't have to use it, ergo those who don't intend to use it shouldn't care. As numerous people (myself included) explained, any feature we add to the language ends up being necessary for users to understand - far beyond those who may have wanted to intentionally use it in the first place. Of course it's optional. Using for loops is also optional - nobody forces you to use them. Even functions are optional. Objects? Completely optional. Why ont add some optional Ruby syntax support, along with optional Perl syntax support? Optional malloc() free() functions? Optional pointer arithmetic? Those who don't want to use it wouldn't have to. Let's not fool ourselves by saying an optional feature doesn't bring clutter to the language. It does. Auto-converting type hints included - but unlike strict type checking - the value they bring is arguably higher than the clutter complexity associated with them. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.ne...
Re: [PHP-DEV] TODO List
Hello, I would like to add it would be in your interest to try to touch base with a core-dev or someone with commit access to act as a mentor. I noticed when I took initiative to start working through bugs they mostly rotted in the bug tracker. -Chris On May 12, 2010 1:24 PM, Mathias Grimm mathiasgr...@gmail.com wrote: What is the correct todo list ? I want to help us but a need to see the todo list to select my work! Any sugestion to start? -- Att. Mathias Grimm http://mathiasgrimm.com.br http://phpempregos.com.br
Re: [PHP-DEV] Hi
Hello, On Tue, Mar 30, 2010 at 10:27 AM, GM greg...@gregory.net wrote: I would love to write an RFC, but I don't seem to have write access to the wiki. At the very least, I'm not able to create page, but I'm pretty sure I can't even edit them (at least not in the namespaces I've tried). SNIP Well proposed, I recall a discussion more recent then the one I found on marc.info [1] but can't recall if a patch was ever made, regardless I am interested in this feature but I think the big argument against it will be the fact we already support it through alternate (albeit non-native) means. Typically convenience is not a well supported argument in language syntax/feature proposals from what I have seen. -Chris [1] http://marc.info/?t=1151431r=1w=2 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5 Bug Summary Report
Hello, Those are some good ideas, another thing I think might help get some bugs closed is a way to detect which bugs have patches/diffs attached or included. Honestly I stopped submitting patches when I noticed they rot for months :) -Chris On Jan 25, 2010 9:37 AM, Guilherme Blanco guilhermebla...@gmail.com wrote: I usually look at the count of issues and compare to the previous week. Then after a quick eye-diff, I check which ones were fixed. I think I'm the only one that does that... =) Your changed would be very well accepted, specially by me. Cheers, On Mon, Jan 25, 2010 at 2:26 PM, Philip Olson phi...@roshambo.org wrote: On Jan 25, 2010, at ... -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/...
Re: [PHP-DEV] function call chaining
Hello, On Mon, Jan 18, 2010 at 5:27 PM, Stanislav Malyshev s...@zend.com wrote: I wrote a small patch that enables this kind of syntax in PHP: foo()(); ... I think language enhancements with no BC breaks that offer a wider toolset to programmers is a good thing. I would also like to see the other ideas in this thread implemented such as array access object creation. The only thing I do not like about this is I do not beleive it fits the PHP error model. Lets just say Bar::foo($arg) returns a function callback or FALSE/NULL on a error condition. So you end up with a function call to something that is not callable, the PHP way under this case is to have a fatal error. I would rather not see more ways to cause fatal errors in PHP (call to undefined method has gotten a bit more popular since object chaining has risen in popularity as well). Of course I know exceptions are likely out of the question for these kinds of cases as well. These thoughts do not apply to array access or object creation. Regards, -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] function call chaining
Hello, On Tue, Jan 19, 2010 at 10:07 AM, Lukas Kahwe Smith m...@pooteeweet.org wrote: On 19.01.2010, at 18:03, Chris Stockton wrote: enhancements in the sense that they enable things that were not possible before, sure. syntax sugar that hurts readability, not really. if you are worried about key strokes switch to an IDE. if you are worried about performance use a byte code cache. I am not worried about key strokes or performance of my code, neither were arguments I made. The points I am making is I believe array access and object creation are fairly good utilities that would naturally fit inside the language without looking like they do not belong, I do not call those syntax sugar. The function calls I believe could also be a utility that if not for PHP's error model could also fit more naturally. Regardless of my belief on syntax highlighting I think that the function patch could be useful and used responsibly by the PHP user base and would be a good enhancement, yes, I said enhancement. Syntax sugar already exists in PHP, and they call it syntax sugar, because it is sweet, not bitter, duh. :-) Regards, -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString(), __toArray()
Hello,
On Mon, Jan 11, 2010 at 8:32 PM, mm w 0xcafef...@gmail.com wrote:
cast is not needed in PHP
i 'd rather be more interesting in
class Obj {
function __catch($data, $type) {
//$type [ static_method, method, get_property, set_property]
if (observed $type == set_property somevalueIsObserved) {
$observer-notify(somevalue::valueWillChanged);
$this-somevalue = $data['somevalue'];
$observer-notify(somevalue::valueDidChanged);
} else {
continue__call();
}
}
}
What? ...
Etienne Kneuss wrote:
This is where operator over-loading would be useful however perhaps only
explicit casts would make sense here.
I beleive adding a __cast(string $type) would be a useful feature for
me, very often I have a toArray method defined. I agree with you that
due to unexpected edge cases with operator precedence and general type
juggling that __cast should only be called on explicit (cast).
I.E.:
class Int { public function __cast($type) { return 'int' == $type ? 15 : 0; } }
$r = new Int;
var_dump($r + 1); // 2
var_dump((int) $r + 1); // 16
var_dump((bool) $r + 1); // 1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString(), __toArray()
I don't move any magics, I'm worried your knowledge of social skills? Theirs people be your friends? Weird On Jan 12, 2010 9:10 PM, mm w 0xcafef...@gmail.com wrote: I don't move any magics,I am worried about your knowledge of php, there's people to give you money ? weird, set get call are only call when something doesn't exist catch or catch-able concept is to be able to catch any existing calls no the dynamic ones. On Tue, Jan 12, 2010 at 6:59 PM, Clint Priest cpri...@warpmail.net wrote: Eddie Drapkin wr... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub...
Re: [PHP-DEV] Intl extension class MessageFormatter instantiation returns NULL
Hello,
2009/12/9 Jared Williams jared.willia...@ntlworld.com:
Try...
$fmt = MessageFormatter::create('en_GB', 'There are {0,choice,0#are no
files|1#is one file|1are many files} ok');
...
Thank you, the piece I was missing is {0,choice ... I appreciate
the response and the link.
On Wed, Dec 9, 2009 at 11:33 PM, Tomas Kuliavas
to...@users.sourceforge.net wrote:
What's the point of using i18n code for basic zero, one and many
decision. Your sample text does not have numbers and does not use plural
forms. If that function can handle plural forms, then it should know
My example was straight from the documentation [1] but I missed a key
piece, as mentioned above
- $r = new MessageFormatter(en, There are {0≤are no files|1≤is
one file|1are many files} ok);
- $r = new MessageFormatter(en, There are {0,choice,0≤are no
files|1≤is one file|1are many files} ok);
This was non-obvious based off the research I did, a overlook perhaps
on my part. Furthermore NULL was not the expected result from a object
instantiation; hence my mail to this list. Obviously my snippet was
reduced from within a more complex internationalisation
implementation.
formating rules based on language set in first argument and second
argument should only set array of strings formated according to language
rules. Second argument should not have to evaluate number every time
translator wants to use plural form.
Pluralism is definitely a legitimate use case that is required within
my employers application; most seamlessly integrated by translation
services at the message formatter level. But hey, maybe your right...
ICU should just remove pluralism all together and we should use
arrays. Thanks for your useless response!
-Chris
[1] http://icu-project.org/apiref/icu4c/classChoiceFormat.html
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Intl extension class MessageFormatter instantiation returns NULL
Hello,
I am trying to use ChoiceFormat in the Intl extension. When I try to
do something like:
$r = new MessageFormatter(en, There are {0≤are no files|1≤is one
file|1are many files} ok);
// $r is NULL
This may be a incorrect use, but my thought is that regardless null
should not be returned because no error code or error message can be
returned. I also can not think of a single case off the top of my head
when new does not return a object (aside from a exception being thrown
on instantiation).
I am struggling to find documentation on plural usage. There is no
ChoiceFormatter class so it is my assumption that message formatter
parses that format. I would very much appreciate if someone was able
to point me in the right direction. My apologies if this may have been
better suited on PECL list, but subscribing appears down and I am
hastily in search for a answer.
-Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures and $this
Hello,
On Wed, Nov 18, 2009 at 11:44 AM, Stanislav Malyshev s...@zend.com wrote:
I have very hard time imagining somebody that would be comfortable using
such a construct. What happened to keeping it simple? And why every tiniest
feature of every remotest imaginable use case has to be brought into the
language syntax?
That syntax made my eyes hurt, but I think really the problem is that
people want to dynamically add methods with $this in the closure
pointing the the object it has been attached too. Really I like A. but
can see cases for rebinding (C). Maybe a magic method like
__attach(string methodName, function method) that would rebind $this
in closures would be a solution. But it would be the first magic
method I can think of that isn't overridden by the defining class.
$o = new StdClass;
$o-bar = 'bar';
$o-__attach('foo', function() { echo $this-bar; });
$o-foo(); // bar
Just a thought.
-Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Closures and $this
Hello, On Tue, Nov 17, 2009 at 2:59 AM, Mathieu Suen mathieu.s...@easyflirt.com wrote: Christian Seiler a écrit : Hi, since a few months have passed since the last discussion on this topic and perhaps people had time to gather some experience with the current closure implementation in PHP 5.3 I'd like to restart the debate on $this in closures and object extension. I believe that (D) wins my vote, and it convinces me twice. Once because I believe it is the most intuitive for users (A), and twice because I believe it is also the most useful (C) for users. In my opinion It seems the most PHP way. -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6's future
Hello, On Mon, Nov 16, 2009 at 6:13 PM, Kalle Sommer Nielsen ka...@php.net wrote: But what is every ones input on the matter of attempting to boost PHP6's development? I'm willing to give my part in whatever I can to help getting up on the feet to get this ball rolling. I think that some more focus on PHP6 would be great! Though I am not sure if 5.2 could stop development (although perhaps a resource shift to 5.3/6, starving new 5.2 features/backports for 5.2 security/bug fixes only). I would hate to see PHP6 become P(erl)HP6 :p -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] A few bug fixes and question on apache related tests
Hello, I have created a few small patches for a few unassigned bugs I saw in the bug report summary. These may not be 100% correct, or best practice and if someone has the time I would not mind feedback on anything incorrect, I would like to start fixing bugs on occasion in my free time. I was able to create tests in what I believe to be the appropriate places, however #48597 and some grep'n/poking around I was unable to see anything in the test system that supported apache testing. I may have just overlooked something, if so please let me know how to make a test case for it. I think it is possible to maybe test it without using apache (maybe something with the cli?) but off the top of my head can not think of anything. -Chris -- Bug #47409 (extract() problem with array containing word this) http://cstockton.org/php/patches/bug47409-5.3.patch Bug #48418 (NaN NaN, NaN 0, NaN 0 return true) http://cstockton.org/php/patches/bug48418-5.3.patch Bug #48484 (array_product(array()) returns 0 instead of 1) http://cstockton.org/php/patches/bug48484-5.3.patch Bug #48597 (Unclosed array keys break space escaping in $_GET/POST/REQUEST) http://cstockton.org/php/patches/bug48597-5.3.patch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why is ereg being deprecated?
Hello, On Mon, Oct 12, 2009 at 10:36 AM, Mark Krenz m...@suso.org wrote: Whenever I bring up an issue like this with the PHP devs, I feel like you guys never experience having to support PHP. Among other things, I am the main sysadmin for my web hosting company and have been supporting PHP since version 3 there. When 4.0 came out, I had to help people change their code accordingly to fix any changes and so on with subsequent versions. .. snip ... So for the project developers to just say screw you, we're dropping ereg in 6 and you can't do anything about it without giving a chance for that information to make its way downstream is pretty cold and will lead to a lot of angry people that maybe you don't have to deal with, but the rest of us that run servers and maintain code have to deal with. Just because you did not find the information does not mean it was unavailable. Assuming developers are saying screw you is just ignorant. No one says you have to upgrade to PHP6 the moment it is available. you could run PHP5 another 10 years if you choose. If you choose to go through whatever measures you find necessary then no one is at fault except for you. Many web hosting companies waited until after PHP4 was entirely deprecated to upgrade to PHP5, and some, likely still run PHP4 on some servers for customers to stubborn to upgrade. Your assumption of responsibility I find incorrect, your general approach to this discussion I find distasteful. If it bothers you this much put a patch out, that can be discussed and perhaps applied depending on the consensus. -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] reference caller object
On Wed, Sep 16, 2009 at 1:59 PM, Chris Trahey ctra...@csisd.org wrote:
(Please direct me elsewhere if necessary, this is a feature request)
It would be handy to allow a method to behave differently based on who is
calling it.
the function I am looking for would essentially do this:
.. snip ..
Type hinting would be a clean approach, I can not see a argument why
the below would be less correct.
public function registerMe(Loadable $oLoadable) {
if( ! ($this-authenticateMod($oLoadable))) throw new
admin_exception('module
not active');
$this-loadedMods[$oLoadable-module_id()] = $oLoadable;
return $oLoadable-onLoad();
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] reference caller object
On Thu, Sep 17, 2009 at 10:05 AM, Chris Trahey ctra...@csisd.org wrote: For each use case, there are going to be ways to acheive results without new functionality. I think this feature doesn't make the impossible possible, it gives developers a consistent interface to access an object that is potentially very relevant, and perhaps not desired to be necessary in the method signature. The decision to include a feature like this should not be made based on a particular use-case, but instead on the idea that the sender of a message should be able to be identified without enforcing a certain method signature or pulling a full backtrace. To me, this feels like a basic element of OOP. I do not think your example provides a consistent interface but simply a way to be less consistent. I think it would lead to users relying on caller to implement certain methods and may not do the necessary type checking before calling. Furthermore by requiring type checking in the body of the caller, you are adding a step that IMO is less clean then passing the instance. Using type hinting and passing objects make the developer very aware of the api they are using, that in itself enforces consistency. I would like to say I appreciate reading all feature suggestions on this list as well as yours and am not debating to debate; but am not very interested in having to deal with the possible bad design choices and tracking down call to undefined method errors this would lead to as a user of PHP. -Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Regarding serialize
Hello,
I have came across some strange behavior today, after some time I got
it to the simplest form to reproduce. I have not yet attempted to
patch/investigate the code within php source, I want to first confirm
this is indeed a problem and I haven't just had a long day, as well as
verify it is not a known issue. I have searched the bug tracker; found
nothing similar.
Below is reproducible code, tested on php 5.3.0 release build, as well
as the latest snapshot and a random version installed in a yum
repository (5.1.6).
Regards,
-Chris
--
class testSerialize
{
protected $_foo = Array();
}
$base = new testSerialize;
$str1 = 'O:13:testSerialize:1:{s:7:*_foo;a:0:{}}';
$str2 = serialize($base);
var_dump($str1);
var_dump($str2);
var_dump($str1 == $str2);
var_dump(escapeshellarg($str1));
var_dump(escapeshellarg($str2));
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Regarding serialize
Apologies for the double post, but the output might help... long day.
Notice the strlen is different, as well as the truncation on
escapeshellarg.
--
string(43) O:13:testSerialize:1:{s:7:*_foo;a:0:{}}
string(45) O:13:testSerialize:1:{s:7:*_foo;a:0:{}}
bool(false)
string(45) 'O:13:testSerialize:1:{s:7:*_foo;a:0:{}}'
string(31) 'O:13:testSerialize:1:{s:7:'
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Replacing errors with Exceptions
Sorry for top post, on my android. I disagree that php has perl phobia, but I agree that a alternative to errors needs to be made. Your example is nice but might have some tricky implementation details if php continued to throw errors when it didn't detect $!. I.E. fopen(...) or throw new CustomException($!); when custom exception writes to a log file that also writes to $! Perhaps for file not found, For example, does the first fopen throw the error or supress it as the user likely wanted. However it becomes a moot point if errors are still thrown. On Jul 24, 2009 9:01 AM, Matt Wilson sha...@gmail.com wrote: I agree, however there are certain aspects of PHP's errors that leave a lot to be desired. For instance, a failed fopen or a failed socket will often result in an uncatchable warning from php. Sure, you can add a @ to the line but that's slow and doesn't tell you anything about what happened. I've been saying for years that PHP needs to get over its perl phobia and implement something like $! fopen(file, r) or throw new Exception(Error: . $!); Wouldn't that be nice? On Jul 24, 2009, at 10:51 AM, Brian Moon wrote: On 7/24/09 6:43 AM, Ben Scholzen 'DASPRiD' wrot...
Re: [PHP-DEV] Update to Zend Highlighter
On Thu, Apr 2, 2009 at 8:02 AM, Robert Cummings rob...@interjinn.com wrote:
Wrap the whole highlighted block in a div with a class:
div class=php-highlighted-code
/div
Add one more INI setting to change that class. Let users leverage
hierarchical CSS rules:
div.php-highlighted-code span.keyword { color: red; }
I like that, and would further elaborate instead of INI changes etc,
allow a key-value pair array to be passed as a third argument. Perhaps
ini changes could be the default names.
mixed highlight_file (string $filename [, bool $return= false [, array
$class_names]]);
comment|default|keyword|html|string)
Array(
'div_wrapper' = 'xyz-cms-div-wrapper',
'default' = 'xyz-cms-default',
'etc' = 'xyz-cms-etc',
);
The good thing about this as well, is for some odd or logical reason
if your using highlighting multiple times, you can change the class
names of each highlight without something like ini_set.
-Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Sanity tally #2
I would like to vote for #3. On Fri, Oct 17, 2008 at 7:42 AM, Steph Fox [EMAIL PROTECTED] wrote: Hi Lukas, We are not ready yet. So for now I will not force a decision just yet. Hopefully next week ... I'm going to stop this tally at 50 responses. That should be enough to show us where people generally are coming from. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
I have been watching the namespace conversations for months and I can not get my head around this fixation on a new separator. Other languages get by without separate resolution syntax, why not solve these ambiguities through rules of precedence like everyone else? Throw possible ambiguity warnings if we don't mind looking ahead for the performance hit and give users the ability to alias their namespaces with AS when conflicts do occur they can be easily fixed. using BadNamedLib as BetterNamedLib; using BadNamedLib; Resolve using :: as a separator, have some simple rules and document them, first namespace's loaded classes takes precedence over the last. Constansts are more important then classes, or vice versa. Document the determined precedence. Giving users a tool to alias namespaces solves a lot of the namespace resolution issues. Just my thoughts, -Chris
Re: [PHP-DEV] PHP 4.4.9 Released!
Hello, Is the link in the changelog pointing to the wrong bug? Seems mb related but speaks of mysqli. Just something small I noticed. -Chris On Thu, Aug 7, 2008 at 1:47 PM, Derick Rethans [EMAIL PROTECTED] wrote: Hello, The PHP development team would like to announce the immediate availability of PHP 4.4.9. It continues to improve the security and the stability of the 4.4 branch and all users are strongly encouraged to upgrade to it as soon as possible. This release wraps up all the outstanding patches for the PHP 4.4 series, and is therefore the last PHP 4.4 release. Security Enhancements and Fixes in PHP 4.4.9: * Updated PCRE to version 7.7. * Fixed overflow in memnstr(). * Fixed crash in imageloadfont when an invalid font is given. * Fixed open_basedir handling issue in the curl extension. * Fixed mbstring.func_overload set in .htaccess becomes global. A separate release announcement is also available. For changes in PHP 4.4.9 since PHP 4.4.8, please consult the PHP 4 ChangeLog. Release Announcement: http://www.php.net/release_4_4_9.php Downloads:http://www.php.net/downloads.php#v4 Changelog:http://www.php.net/ChangeLog-4.php#4.4.9 regards, Derick -- http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] enabling everything by default
The more extensions enabled by default, the more extensions many developers can count on being in common builds. Part of PHP's success is the extension system and the variety of tools it gives the user-base. It is also a nice peace of mind for library developers to be fairly sure the typical php build has X ext. Is their a particular reason you are against giving users such a variety of tools? If performance or binary size I would be interested in stats/benchmarks. I have done some testing in the past when we disabled all extensions we did not use at a previous employer to squeeze some performance out and the benefit was non-existent. -Chris On Fri, Aug 1, 2008 at 4:53 AM, Antony Dovgal [EMAIL PROTECTED] wrote: On 01.08.2008 15:44, Pierre Joye wrote: It is not about being 100% true or 100% false. We have a couple of ways to see that, extension usage stastistics and own experiences (mines in the PEAR time, with htscanner feedbacks on what they use, and a couple of other things). I provided one source and it reflects what I said (see nexen.net base configuration stats). Lots of hostings and single servers use default packages from their distributions and distributions tend to include much more than what's enabled by default, so hostings use what's enabled by default is just as fake argument as is hostings are afraid of PECL. Also, even if all of the hosting companies in the world would use simple ./configure, I still couldn't think of a reason to enable ext/sqlite3 by default. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP
Hello,
No one at all thinks:
function foo($x, $y) use $a, $b, $c {
}
Looks awkward and a little out of place when compared to:
vs
function foo($x, $y) {
lexical $a, $b, $c;
}
Although the fact we have to import variables from the parent scope kinda
stinks and is not typical in closer implementations, we should at least
import into the scope in a way consistent with how we do it already with
GLOBAL right? Just seems a lot cleaner IMO.
-Chris
Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP
Hello, I am curious if is_callable will be able to detect these? Or do we need a is_lamba, or is_function or something. You may have mentioned it but reading through I did not notice. I am only curious how to know when someone passed me one of these. Maybe a type hint would be nice too but that is a different conversation I guess. -Chris
Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP
Hello, Great patch and a much needed feature. One thing I do not agree with is the point in the lexical key word, seems it should be natural to inherit the outer scope. I guess the choice of adding lexical and going slightly against the grain of typical closure implementations like scheme or ecmascript is that is not really consistent with php so i can understand disagreement and your note you made on performance. Seems like the right choice to force manual inheritance of outer scope. But great work on this, hope it gets added and none of the core developers say it is not the php way or is only useful in brainless languages. -Chris
Re: [PHP-DEV] deprecation status of $str{42} versus $str[42]
On Tue, Jun 17, 2008 at 2:21 AM, Steph Fox [EMAIL PROTECTED] wrote:
Hi,
Seems like you are missing some PHP programming basics. Strings are not an
array of chars, please go back to making ping pong in java c# or whatever
other little comp sci classes you took. PHP is not any of them.
Foreach(foo as $key = $char) {}, after learning, please be quiet and
let
andi answer my question on his ideas he had for improvements to the
existing
and once favored syntax.
Please, keep this kind of personal abuse off the core development list. It
adds absolutely nothing to the debate, and we're all very, very bored with
it
I was trying to have a productive discussion on the topic, his response is
the one that added no value, was nothing but a troll.
Anyways, I like the fact my response brought up iterating strings, which I
think as far as code points or bytes etc, go, really its the same problem as
$str{0} on a Unicode string, im sure PHP6 will fix this with Unicode
strings. Still, I wish this was not being removed I have a lot of legacy
code around that uses it and am sure many companies do as well, and it has
always felt more correct _to_me_ but it is what it is. Case closed I guess.
-Chris
Re: [PHP-DEV] deprecation status of $str{42} versus $str[42]
Hello,
On Sun, Jun 15, 2008 at 11:20 PM, Arvids Godjuks [EMAIL PROTECTED]
wrote:
String is an array of chars, always was and is such in any programming
language. So I see argument for {} as missing knowledge for some programming
basics.
And I don't understand why are you arguing on this. This was decided for
removal long ago - so just do it.
Seems like you are missing some PHP programming basics. Strings are not an
array of chars, please go back to making ping pong in java c# or whatever
other little comp sci classes you took. PHP is not any of them.
Foreach(foo as $key = $char) {}, after learning, please be quiet and let
andi answer my question on his ideas he had for improvements to the existing
and once favored syntax.
-Chris
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Mon, Jun 16, 2008 at 2:02 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: Hi! So you just ignored the special cases part. Yes, if you have special case where you interface with very brain-dead strictly typed system that absolutely can't understand that '1' and 1 is the same - then you need to _convert_. So how failing when you get '1' instead of 1 helps you? You'd need _conversion_, not _failure_ - and if you write strictly-typed API, you'd move the conversion responsibility to the user, instead of having it where it belongs - in the API. That's *exactly* why I see strict typing in PHP so dangerous - it promotes lazyness and sloppiness in API writing, and those APIs will be a nightmare to use, since they would bomb out on slightest disagreement about internal engine types, which the API user shouldn't care about at all. What happened with be liberal at what you accept? In strict compiled languages, the compiler and IDE will guide you through this, in PHP you'd just have it explode in your face in production. How this is good for anybody? I get this, really, I do, again. Like the previous post I (likely we) understand. Did you not get or read my post? You say again and again 1 == '1', but you are forgetting those OTHER operators, === and !==. 1 !== '1' does it? Add numeric hinting like I said 50 posts ago and your 1 == '1' problem is solved People who want to make more simple API's will make simple API's offsetting the complexity of your precious 1 '1' to the API level. People who want to make it strictly integer, will continue to do so as they do now. You can not, and should not want to, control the way people program. But I know this will never happen because no one cares what users want... your logic of We should allow user to check for is_int and is_numeric, resource, object, array, string, etc, within any conditional statement under a function or method. Allow checking for object or array in functions or methods paramters. Disallow anything else from being checked in functions or methods paramters. Follow a philosophy that a user should not be concerned with internal data types. Make sure the user has access to internal data types. User should not have to talk to strict typed systems. But if they do have to make it more difficult then it needs to be because it makes more sense, plus those systems are brain dead. How in the world, does this remotely, possibly, even slightly make sense? -Chris
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
Hello, On Sun, May 25, 2008 at 1:57 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote: I see absolutely no use in strict mode. Moreover, I consider it harmful as it teaches people not to use dynamic nature of PHP but instead pepper their code with unnecessary checks and irrelevant errors. As I said, I see no difference that could matter to PHP programmer between '1' and 1, and I don't see why we should encourage making this difference. I know there could be very special cases when it could matter, but importance and frequency of such cases do not warrant, in my opinion, their support by the syntax and the standard library of the language Maybe we should stop using the 1 and '1' argument, yes, they can be juggled to the same thing and I as well as others do see your point man. But try to remember, 1 !== '1' and PHP is not an end all language, often we have to communicate to strictly type systems, we need to be positive of what we send. I.E. XMLRPC Client sends string instead of integer to some merchant API changing the meaning of the request or voiding the transaction. PHP Made a design decision long ago to allow developers to have script types, by this decision with OOP5 and such strict type parameters would be made feature complete and be a additional feature for people to use who want to use it. IMO -Chris
Re: [PHP-DEV] deprecation status of $str{42} versus $str[42]
Hello,
On Tue, Jun 10, 2008 at 9:11 PM, Andi Gutmans [EMAIL PROTECTED] wrote:
Hi,
$str{} was considered a best practice for a while so as you can see via
Google Code Search it's been used quite a bit.
I take the blame for introducing it with the intention to not only
create a better separation between arrays and string offsets but by also
then allowing for a cleaner implementation for string offsets.
Unfortunately I never delivered that cleaner implementation esp. as
there didn't seem a huge benefit
I don't have strong feelings either way esp. as moving from $str{} to
$str[] is scriptable but given that so many people have used it and
there are benefits to separating the two (it also resolves an ambiguity)
I'd like to put another option out there which is to try and see if we
can actually follow through on original intentions of also delivering
technical benefit in addition to the syntax separation.
I personally have always used {} for string offsets because it just felt
right. [] seems like it is for arrays, for me, using it on strings makes me
feel dirty.
Could we maybe visit some of the ideas you have had with {} syntax offering
some benefit? That I do not completely understand and would be nice to know
what you mean.
Maybe something like built in substr? since it wouldn't break existing use
of {}, tough thing is the ambiguity between {1} regular and {1} substr,
dunno:
$str = abcdef;
$result = $str{1}; // returns b, but substr would be something like bcdef
$result = $str{1, 2} // returns bc, this we know what to return for sure
$result = $str{1,} // maybe to make up for lack of {1} returning remaining
portion, its a little ugly almost feels like a syntax error
Just trying to figure out how you could have technical benefit with it,
maybe you just meant performance optimization or something.
-Chris
Re: [PHP-DEV] Re: Short syntax for array literals [...]
Not like they will be listened to unless they are commiters. -Chris On Sat, May 31, 2008 at 5:27 AM, Lars Strojny [EMAIL PROTECTED] wrote: Hi Sebastian, Am Freitag, den 30.05.2008, 18:23 +0200 schrieb Sebastian Deutsch: [...] Nonetheless I feel that the userland is less represented on the internals list - do you have a proposal to hear their voice? Well, they can subscribe, can't they? http://www.php.net/mailing-lists.php cu, Lars
Re: [PHP-DEV] Unicode and XML
I think that internal string handling so be very respective to the specification as you said. Perhaps code points which are not valid for a separate specification, protocol etc, the conversion should be done in the functions dealing with those formats. Like if extension family xmlfoo does not like null bytes or bom or high surrogates, whatever, then have xmlfoo_strip_invalid (bad name too ;p). -Chris On Wed, May 28, 2008 at 9:23 PM, Edward Z. Yang [EMAIL PROTECTED] wrote: In PHP 6, incoming user data will automatically be in (unicode) form. (That is, assuming that the JIT functionality for converting gets implemented). One of the implementation details I'd like to consider involves non-XML and/or non-SGML codepoints inside markup. As per the Unicode specification, it is perfectly valid for a Unicode string to contain the codepoints U+ (null byte), U+ (non-character) and friends. However, it is not valid for an XML document to contain these characters; either of these will result in a fatal error. Classically, it was very difficult for PHP scripts to implement UTF-8 support completely correctly. Many implementations check that the UTF-8 is well-formed, but neglect to strip out null-bytes and the like. I consider validation/filtering against the XML char production (or perhaps even more restrictive, as that allows some control characters not allowed in HTML). How should we go about making this easy in PHP 6? Perhaps a web_encoding (terrible name, I know) function is in order? -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier http://htmlpurifier.org Anti-XSS Filter [[ 3FA8 E9A9 7385 B691 A6FC B3CB A933 BE7D 869C 48DA ]] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Short syntax for array literals [...]
Hello, On Thu, May 29, 2008 at 11:55 AM, Johannes Schlüter [EMAIL PROTECTED] wrote: Hi, On Thu, 2008-05-22 at 05:12 +0300, Stan Vassilev | FM wrote: It looks as there may not be a specific reason not to allow the JS syntax as an alternative syntax (while keeping the current one in parallel): $a = [[1, 2], [3, 4], 5, 6]; $b = ['a' = 1, 'b' =2]; ok, in a previous post I mentioned this was discussed short time ago (in January to be precise) but well, then once again with more details: When I learned more about PHP one of the things I learned was that PHP was proud to be a bit more verbose than other languages while not as verbose as others. By using the array()-Syntax newcomers had a thing to look for when reading code which I always saw as a central design principal of the language. Now we can change such principals from time to time, the world changes, so can PHP. But for changing such principals we need a clear consensus imo. In the January discussion the result was around 50:50 which isn't a clear consensus. Back then there was a small difference between committers and non-committers. In the group of the committers there were a few more -1 than +1 votes, within the non-committers-group it was the other way round (your favorite search engine should give you the exact numbers, don't have it at hand). Now my second assumption is that committers have thought a little bit more about language than random commenters of course there are exceptions but I think the general picture should be like that. So in January this change wasn't accepted. So, now, less than half a year later the discussion restarts and we aren't much further, from what I see it still looks like a 50:50 to me - without counting. Now to my own opinion: I read way more code than I write, code from different people using different coding styles etc. so I like a more verbose syntax. My only question, is what does PHP want. When I say PHP, of course I am referring to the tens-of-thousands of users that make PHP a success. Lets remember that random commenters which I would like to refer to as PHP's actual user base, which I would further annotate that the committers graciously power, respectively; In general tend to favor introducing the syntax. So, if you were to apply that ratio to the tens(hundreds?) of thousands of people actually using PHP 50:50 does not not seem correct. Further, we need to vote for the future PHP, people who have not yet learned PHP, how can this benefit them. We need to also look at other languages, the most commonly used languages, how will the migration FROM XLANG to PHP be, as well as ZLANG to PHP. Lets have some true thought and analysis before another feature is rejected. I have been watching the mailing list for long as I can remember and seems that features and such are never truly voted for. Perhaps a PHP.net voting system should be made, so PHP can progress based off what the community wants, not what a group of committers want. I respect fully the time and effort put into the project but time to time I see the vote of PHP (in the afore mentioned context) lost and discounted for. Just my opinion. -Chris
Re: [PHP-DEV] Re: Short syntax for array literals [...]
+1 for: ['foo' = 'bar'], Not sure if it was decided but -1 for ['foo':
'bar']
Here is why,
Array(), is much more confusing to someone coming with no experience in php
then []. Array() in most languages looks like a function call. So
Array('foo' = 'bar'), verse ['foo' = 'bar'], most people will more easily
understand the latter when entering into the language fresh.
I.E.:
$f = Array('foo' = 'bar');
$f('foo'); // comes to mind first right, might not for a php developer but
for a new comer maybe?
$f = ['foo' = 'bar'];
$f['foo']; // great
Gives our users options, and does not break any existing code or enforce new
programming paradigm. The change is minor and no real cost in performance.
As for existing users, I find the completely negative comments a real
hindrance on the evolution of php as a language. If something does not
damage the language but will offer benefits for a broad user base, as well
as existing code, then let it be. I for one will change every line of code I
have that uses the Array() syntax for the shorter, more WIDELY readable []
syntax.
My only curiosity is if this will turn into a ecmascript morphism and we
wind up with a new object proposal instead of stdclass, like
$oStd = {'foo' = 'bar'};
echo $oStd-foo;
... doesn't even look all that bad but feels wrong and dirty, I think I
would rather (object) ['foo' = 'bar']; :p
-Chris
Re: [PHP-DEV] Re: Short syntax for array literals [...]
Hello,
On Wed, May 28, 2008 at 10:25 AM, Jani Taskinen [EMAIL PROTECTED]
wrote:
Exactly. Open this can of worms and soon PHP is something else than easy to
learn.. someone already mentioned that {} thing for objects.. :)
Sidenote: There are more important things to solve in PHP 5.3 (and
especially HEAD) than adding this little syntax sugar..
--Jani
It's not syntax sugar, it's a construct which is used across many other
languages. It will improve the language for other people and might help
people to learn PHP. If we have resource issues commiting one line of
grammar the project has other issues to deal with.
Mike wrote:
In my opinion I don't think PHP would be where it is today if it wasn't
for being so easy to learn and use.
I attribute this directly to the fact that it didn't use a lot of
syntax sugar that is unreadable and can't be Googled for. You can't
Google [], and my guess is searching PHP.net for [] won't return
anything useful either.
Using Array() is SELF EXPLANATORY! Anyone can see that, search Google
for Array and learn something about it.
How many man hours are going to be wasted:
1. Searching for what the heck [] actually is.
Anyone who has gotten to a level of knowing how to assign php variables will
likely have any troubles understanding what:
$config = ['smtpHost' = 'example.org'];
$oSmtp = someSmtpTransport($config['smtpHost']);
Is doing, and if you have a super complex multi-dimensional array,
regardless of brackets or array syntax it will be hard to understand by a
php new comer.
2. Explaining to people that [] is the same as Array.
$foo = Array('foo' = 'bar');
var_dump($foo);
$foo = ['foo' = 'bar'];
var_dump($foo);
Explained.
3. Changing coding standards for projects to prevent [] from being
used.
4. Enforcing coding standards for projects to prevent [] from being
used.
$str = $var {$foo} . $bar . $see . ' tconst ' . $not . ' $parsed ';
We already face issues with more then one way to do things, we deal with it
and it has not proven to be to difficult.
5. Trying to change [] back to Array in hopes of getting code to work on
older versions of PHP.
If your projects target versions are older versions then create backwards
compatible code just like you do with PHP4 classes and PHP5 classes.
6. All the man hours wasted on it ALREADY that I'm sure could be much
better spent getting PHP 5.3/6.0 out.
The discussion is the wasted time, not the code or implementation.
There are enough roadblocks and other things to worry about already, why
would we want to add MORE? Especially for something with so little to
gain (if anything at all).
Gain to whom? Remember, their is an entire community of developers out
their besides the people on this list who are accustomed to such use for
arrays. Also, a community of developers who would like an alternative syntax
to array to clean up their code a little, like me.
This isn't about well if you don't like it, don't use it either,
because no matter what it will be forced on people who don't like it
eventually. People who like it will be constantly changing Array() - []
and people who hate it will be constantly changing [] - Array(). More
wasted time.
Just like string literals $str = 'foo'; and $str = foo;
class Foo {
public $bar;
public $baz;
public $qux;
VS
class Foo {
public $bar, $baz, $qux;
$obj = new Stdclass;
$obj = (object) NULL;
Really guys my only point is that we should not disregard a proposal for the
sake of having more then one way to do something. That is the beauty of PHP
and any successful language, it appeals to a wide variety of coding
standards, methodologies and paradigms. If you just think about it you can
name tons of things in PHP that let you do the same thing with two syntax's.
This is part of php's success. Some things are easier for people to learn
then they are for others.
-Chris
Re: [PHP-DEV] Re: Short syntax for array literals [...]
Hello,
On Wed, May 28, 2008 at 12:12 PM, Gregory Beaver [EMAIL PROTECTED]
wrote:
I've thought about allowing [] for a while and personally have come up
with my own litmus test for new features.
1) is the syntax missing from the language?
2) if so, does the syntax add missing functionality or significant
maintenance benefit?
2) if not, does the new syntax add significant value?
#1 no, array() is the same [-1]
This is not a valid argument, in my opinion.
#2 not applicable [0]
How can you dismiss whether the syntax adds benefit? If a single person
finds it beneficial it has a benefit, maybe not a majority benefit, but a
benefit none the less. Lots of people will find it easier to pick up coming
from other languages.
#3 [-.5]
* can't google []
If we are going to use google search as a determinative for language
decisions we got some major cleanup to do, lets start by removing curly
braces..
* makes arrays simpler to type and take up less space
* adds potential for confusion between array access and creation:
$a['hi'];
$a;['hi'];
both are now suddenly valid PHP
As far as $a;[0]; goes, that is just a problem with useless contexts allowed
in PHP. Same can be done for $a;Array(0), which I doubt would cause
debugging problems (i do get your point). Really their are many places for
syntax errors, and php does allow a lot of useless syntax, like:
$a;;;$b;;;$c{{;;;{{;;;... that is perfectly valid
code. At the end of the day the developer needs to have sufficient ability
to debug their code.
* syncs with javascript and other languages
* opens pandoras box - PHP is simpler than Perl because there are not
20 ways of doing the same thing with different punctuation shorthands
See my previous post, 20 ways of doing one thing is part of the language
already, and what makes programming interesting.
So I find #1 is -1, #2 is 0, #3 is about -.5
Although the idea is somewhat attractive, I've found no drawbacks to
array() syntax, and plenty of dangers with adding any new alternate
syntax, and this ultimately makes my vote -1
Just my opinion.
-Chris
Re: [PHP-DEV] Class Properties in Interfaces?
If you guys don't like the way interfaces work then do not use them. If your
going to talk about cycles, just lose the abstraction all together.
Important for some. You once again, with all your hand flapping, assume
we want some kind of operation on the data. If we do not, and this
happens a lot, then we're just wasting cycles... and order of magnitude
more cycles.
You speak of cycles, but I downloaded your framework that you created and
grepped for get and set methods, and what did I find? Thinks like:
function getId()
{
return $this-sessionId;
}
function setId( $newId )
{
$this-sessionId = $newId;
}
function setNew( $status=true )
{
$this-newSession = true;
}
function isNew()
{
return $this-newSession;
}
function getDataStructure()
{
return $this-data;
}
This is wasting space in my mailbox, this conversation is pointless. I'm
trying to read about thinks that are important like language changes.
-Chris
Re: [PHP-DEV] Re: RE : [PHP-DEV] Return type hinting patch
Hello Sam.
Would you agree in general the function int name() { syntax is favored? If
you need help working out the grammar for such changes let me know. This is
something that I think would add value to PHP as a whole and would not mind
lending some time for.
-Chris
On Wed, Apr 30, 2008 at 4:51 AM, Sam Barrow [EMAIL PROTECTED] wrote:
On Wed, 2008-04-30 at 12:58 +0200, LAUPRETRE François (P) wrote:
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
First is that function
definition and code is usually written by the same person in the same
(very small) context, and this person has to be somewhat
absent-minded
to forget what function returns from definition to return a
dozen lines
below. Supporting such absent-mindedness with language constructs
doesn't appear appropriate.
Right, return type hinting is useless in such cases, but it is
interesting when we check whether a method is compatible with an implemented
interface or an extended/abstract class. In this case, both codes are
typically not written by the same person and specifying the methods' return
types in an interface makes sense.
This is my number one use, abstract methods that are later implemented.
Francois
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RE : [PHP-DEV] Return type hinting patch
You have added is_int, is_numeric, and === operator. I've been reading your
posts and you should really stop confusing using that argument. Truth is,
types are relevant.
$foo = 1;
$bar = '1';
if($foo === $bar) {
echo I am never echo'ed;
}
Until you make $foo === $bar, you should really stop telling everyone how
strict param/return types have no place in php.
-Chris
On Wed, Apr 30, 2008 at 9:36 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Hi!
Right, return type hinting is useless in such cases, but it is
interesting when we check whether a method is compatible with an
implemented interface or an extended/abstract class. In this case,
When exactly you check that? PHP has no static type checking, and in
runtime actual values, not function definitions, are checked. If you mean
checking by tools like IDE, phpdoc is more than enough for that.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hinting patch
*cough* lambda *cough*
On Sat, Apr 26, 2008 at 4:26 PM, David Zülke [EMAIL PROTECTED] wrote:
Am 27.04.2008 um 00:24 schrieb Nathan Nobbe:
On Sat, Apr 26, 2008 at 2:06 PM, David Zülke [EMAIL PROTECTED] wrote:
Wouldn't the most consistent way be to omit function altogether when
using a return type hint?
public static function zomg() {
return $somethingArbitrary;
}
public static string foo() {
return $mustBeString;
}
i think leaving 'function' in there makes sense because thats the way
php
currently works.
Well that was my point. Functions without return type hints use
function, to indicate that they are generic in this respect, and
functions/methods with a type hint omit it to signal the difference. Having
both would be redundant. But then...:
otoh, should there ever be a type function (e.g. for anonymous funcs)
down
the road, that'd mean trouble ;)
wow; good point! maybe if anonymous functions are ever supported the
type
could be capitalized as in 'Function'
public function Function doStuff() {
return function() {}
}
Absolutely not. Right now, all PHP native types are lowercase. Can't see
why anon functions should be different.
Actually, both ways have problems:
public function gimmeThat() {
return function() { echo 'yay'; }
}
is ambiguous if return type hints require omitting function, and
public function function gimmeThat() {
...
}
is just plain ugly.
So maybe anon funcs should have a different type name :p
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Return type hinting patch
Anonymous functions as you know them today come from lambda calculus which
was created before computers were even made. Generally it is agreed anon
func == labmda can be used interchangeably.
Most developers will understand what:
public function lambda sowat () { return function OR lambda, whatever () { }
}
Seems more natural then whatever nightmare people could think of, like
public function Function or public function ANONFUNCLOL...
The thing that I hate about that idea is not a reserved word, any there is
surely plenty of people with functions named them. Perhaps that detail can
be worked out in the grammar without breaking bc.
-Chris
On Sat, Apr 26, 2008 at 5:20 PM, David Zülke [EMAIL PROTECTED] wrote:
But anonymous functions and lambda expressions are not the same thing...
Re: [PHP-DEV] Return type hinting patch
On Fri, Apr 25, 2008 at 12:25 PM, Sam Barrow [EMAIL PROTECTED] wrote:
On Fri, 2008-04-25 at 13:24 -0600, Nathan Nobbe wrote:
On Fri, Apr 25, 2008 at 1:15 PM, Sam Barrow [EMAIL PROTECTED] wrote:
On Fri, 2008-04-25 at 14:08 -0500, Jeremy Privett wrote:
Sam Barrow wrote:
I figured it out, the syntax is now as follows:
function a($b, $c) returns d {
}
I'll post an update soon.
That's certainly a non-intuitive syntax. How about we take a
page out of
the book of other C-style languages before trying to invent
something
else? I agree with Stas, return and returns are not part
of a
function definition.
I don't think it's non-intuitive at all, and even so, it's the
most intuitive we have. This ordering makes more sense to me
at first glance (in the order I would think about things;
scope, name, arguments, return).
im not sure the following has been explicitly proposed, but how about
omitting the 'return' keyword and placing the return type hint before
the function identifier
function int a($b, $c) {}
This is, but I don't think this is possible, due to confusion with the
keywords (public, private, static, abstract, etc). Plus this leads to
long strings of keywords.
There can be no technical reason why this more adopted and understood syntax
should not be possible. Adding returns as a keyword would completely break
tons of code. Why are the proposals on something that is so consistent
across many languages being changed so obscurely? Why a seperate
non-intuitive syntax.
public function int (string $foo) { return 1; }
Can't we keep the sanity?
[ ... ] Plus this leads to
long strings of keywords.
Are you kidding? strlen('returns int') strlen('int'); .
-Chris
Re: [PHP-DEV] Return type hinting patch
Hello Sam,
I think you misunderstand, let me retype for you.
strlen('abstract protected function string dostuff()') strlen('abstract
protected function dostuff() return string')
Making your argument on length void, also, maybe we should not base a
language change decision on typing extra characters..
Sorry man, but to me the code below looks so unusual for what it is meant to
represent:
abstract protected function bar($foo) return string {
// code
}
The above, actually kind of makes me think something non-conventional is
going to happen like return string specifies that it will be auto type
casted to a string for me or something. like:
abstract protected function bar($foo) return string {
return $foo;
// is auto magically like: return (string) $foo;
}
vs the below code that tells me function returns a string like in many
popular languages.
abstract protected function string bar($foo) {
return (string) $foo;
}
-Chris
On Fri, Apr 25, 2008 at 3:04 PM, Sam Barrow [EMAIL PROTECTED] wrote:
I don't know, maybe it does work. But either way I'm not introducing a
new keyword, I changed the patch to reuse the return keyword.
Yes, long strings of keywords:
abstract protected string function dostuff()
On Fri, 2008-04-25 at 14:22 -0700, Chris Stockton wrote:
On Fri, Apr 25, 2008 at 12:25 PM, Sam Barrow [EMAIL PROTECTED]
wrote:
On Fri, 2008-04-25 at 13:24 -0600, Nathan Nobbe wrote:
On Fri, Apr 25, 2008 at 1:15 PM, Sam Barrow
[EMAIL PROTECTED] wrote:
On Fri, 2008-04-25 at 14:08 -0500, Jeremy Privett
wrote:
Sam Barrow wrote:
I figured it out, the syntax is now as follows:
function a($b, $c) returns d {
}
I'll post an update soon.
That's certainly a non-intuitive syntax. How about
we take a
page out of
the book of other C-style languages before trying
to invent
something
else? I agree with Stas, return and returns
are not part
of a
function definition.
I don't think it's non-intuitive at all, and even
so, it's the
most intuitive we have. This ordering makes more
sense to me
at first glance (in the order I would think about
things;
scope, name, arguments, return).
im not sure the following has been explicitly proposed, but
how about
omitting the 'return' keyword and placing the return type
hint before
the function identifier
function int a($b, $c) {}
This is, but I don't think this is possible, due to confusion
with the
keywords (public, private, static, abstract, etc). Plus this
leads to
long strings of keywords.
There can be no technical reason why this more adopted and understood
syntax should not be possible. Adding returns as a keyword would
completely break tons of code. Why are the proposals on something that
is so consistent across many languages being changed so obscurely? Why
a seperate non-intuitive syntax.
public function int (string $foo) { return 1; }
Can't we keep the sanity?
[ ... ] Plus this leads to
long strings of keywords.
Are you kidding? strlen('returns int') strlen('int'); .
-Chris
Re: [PHP-DEV] Re: [RFC] Strict type hints (parameter and return value)
I like this patch, it adds a feature which a lot of companies and code base
would surely implement without breaking anything. The only thing I do not
like has already been mentioned, numeric and scalar are not included.
The one thing I don't dislike, but am unsure of the ease to understand by
users is the return type hinting syntax, using type casting. Maybe I am
wrong but do you think users might get confused by it since it already has
an existing purpose of transforming values to other types, maybe they will
think at glance it transforms the return type to something else? Of course
it would be fault of there own for not reading, but is it NATURAL to use the
existing type hints for it?
Why not:
function int foo($foo) { }
I understand the problem with adding the INT as a keyword, and how that
maybe:
function int int($foo) { }
is awkward, but would be rare and seems to be more correct. I know it would
be more difficult to implement the latter but it should not be impossible
should it?
Just throwing it out there, it is a nice patch and a nice feature for A LOT
of people even though it is not exactly the php way, but all things must
evolve.
-Chris
Re: [PHP-DEV] Re: [RFC] Strict type hints (parameter and return value)
On Thu, Apr 17, 2008 at 9:01 AM, Sam Barrow [EMAIL PROTECTED] wrote: I like this alot better too, the only downside is compatibility problems. Can you explain, I understand; in partial the problem but I am curious what can not be solved through added logic?
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, Apr 17, 2008 at 9:33 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Just for the record, I see absolutely no sense in strict type hints. While
there might be some use cases when you want to save typing by having
function convert the arguments instead of you doing it manually - there's
absolutely no sense to check types strictly in PHP, especially taking into
attention that no API ever worked that way, and that it would force users to
surround each call to such function with checks for argument types, since
PHP can not have static type control. Using such feature would be a
nightmare.
You have a good point, but I think it might have slightly more benefit then
we may think. Less code bloat for the checks many of us already enforce is
one.
Doing some greps in the Zend Framework is a good example.
grep -riE -A2
is_(binary|bool|double|float|int|long|null|numeric|object|real|resource|scalar|string|unicode)
*
I get tons of parameter checks which throw exceptions, so users already have
to check there code prior to sending it up the chain. And by Check a good
framework, like Zend, will do the boundary checking for you, so as long as
it is the right type you are ok.
So:
function foo($var) { if(!is_int($var)) { throw new exception('not int'); }}
Turns to:
function foo(int $bar) { }
which is called like this in both cases, maybe with a try catch etc etc:
foo((int) $baz['bar']);
-Chris
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, Apr 17, 2008 at 9:57 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
What's the use of such code? If $var is '1' and not 1, what's the use of
throwing an exception and having to handle it later (basically by failing
the task, since you don't know how to do foo() now) - instead of just doing
with that 1 what was intended for? There's no any difference between 1 and
'1' that can be important to anybody. Only difference is the way it is
represented in underlying bits in zvals, about which nobody should ever
care. That's like making function that would accept only arguments that has
3'rd bit of pointer set to 1 and 5th bit set to 0, and reject all others. No
sane application should ever behave this way. Writing such function is just
plain wrong, it replaces the substance of programming with nitpicking over
the details that are not important. Whole phenomenon of dynamic languages
has grown on the principle of liberating people from caring for bits and
concentrate on substance, and now you try to drag the bits back in.
So every time you call foo you need try/catch? And that's supposed to be
_good_?
Somebody missed the point...
Seeing how you work for zend I thought maybe you have used the zend
framework = ) Sorry in my example I used int instead of numeric, but my
point is the same, grep in zend framework for is_bool.
It does what you are complaining about:
From: Zend_Pdf_Element_Numeric
public function __construct($val)
{
if ( !is_numeric($val) ) {
throw new Zend_Pdf_Exception('Argument must be numeric');
}
$this-value = $val;
}
That could be...
public function __construct(numeric $val)
{
$this-value = $val;
}
So, let's re-visit my point of less code bloat
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, Apr 17, 2008 at 10:11 AM, Sam Barrow [EMAIL PROTECTED] wrote: Actually, is_numeric checks for strings that contain numeric values, it's not the same as is_bool, is_int, is_float, etc, which check the variable's type. Hence my second example = ) Your point is very valid for is_int and similar functions, just not is_numeric(). I just did a grep on zend framework for is_int and there were tons of results. I think it is valid for anything, numeric type hinting is very appropriate in php.
Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value)
On Thu, Apr 17, 2008 at 10:59 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote: Hi! Seeing how you work for zend I thought maybe you have used the zend framework = ) Sorry in my example I used int instead of numeric, but my point is the same, grep in zend framework for is_bool. It might come as a surprise to you, but I did not write whole Zend Framework personally :) Moreover, as even more surprise I did not even inspect personally each line of code. As a final shock, I am not convinced functions in PHP should throw exceptions when parameters don't match - and even if they do, first they should attempt to make sense of parameters (which makes string hints like integer and string make no sense - you can convert a lot of things to int or string). Even if they can't, it's much better to be handled on user code level with error message that makes sense and way that makes sense for application - but I could kind of live with the scenario where these hints would work as internal function types work now. However, that's not what is proposed - what is proposed is that if you've got int typehint, '1' would be rejected. Having such restriction makes no sense and goes contrary to what PHP and dynamic languages in general are. That first part made me laugh, hehe. I wanted to just point out that your company was a good example of how code could be minimized using type checks. I understand your philosophy with dynamic types in php, but there are times that these dynamic types have really shot people in the foot and added exploits and bad coding practices, which is why high-quality frameworks push users to use correct types, zf is just one of many examples my friend. I get your point of 12 and '12', which is why I proposed earlier numeric hinting would be very appropriate. -Chris
Re: [PHP-DEV] Return type hints
You are missing the point, why be strict on return types, and liberal on
parameters? Be strict consistently or be liberal consistently. Or, keep php,
php. I could care less as long as things are consistent, although I think
only supporting scalar is silly regardless of type juggling.
-Chris
On Mon, Apr 14, 2008 at 7:28 AM, Christian Schneider [EMAIL PROTECTED]
wrote:
Chris Stockton schrieb:
Why on earth would you have int, string, resource, etc return type
hints
and then turn around and suggest for parameter hinting just add a scalar
type? That makes no sense and is so inconsistent.
static int function retarded(scalar $value) {
return (int) $value; // lol
}
Let me turn your question around: Why on earth would someone restrict a
function to int when string works just as well?
function int foo_flexible(scalar $x) { return $x + 42; }
$foo = foo_flexible($value);
function int foo_retarded(int $x) { return $x + 42; }
$foo = foo_retarded((int)$value); # :-(
That said, I'll be using
function foo($x) { return $x + 42; }
anyway and let PHP warnings take care of the rest ;-)
- Chris
Re: [PHP-DEV] Return type hints
Why on earth would you have int, string, resource, etc return type hints
and then turn around and suggest for parameter hinting just add a scalar
type? That makes no sense and is so inconsistent.
static int function retarded(scalar $value) {
return (int) $value; // lol
}
Re: [PHP-DEV] [RFC] Conditional INI support
When I think INI I think constants. What happens when I log into some
server I have to debug some app instance and one of the first things I
might do is check the INI and I see.
[IF ${value} == 1]
setting = 1
[ELIF ${value} == 2]
[IF ${valuex} == 1]
setting = 1
[ELIF ${valuex} == 2]
settingx = ${valuexc?1: ${valuexcl?1:2}}
[ELSE]
[ELSE]
setting = 3
[ENDIF]
What is setting and settingx? Do I have to debug within the app with
ini_get? Or can I dump the ini values very easily somewhere, I guess
php_info() maybe?I won't deny it could be useful specially for
cross-platform cross-version INI setup, but it just won't feel like a
configuration file anymore is all. I almost think you should just
allow PHP tags lol..
-Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
It might be to late to keep it simple, once you add basic language
components like IF-ELSE as you can see people already want basically
another programming language embedded into it. It is my opinion that
the INI files should be simple configuration files. Otherwise they
will become more and more feature rich and people will start shifting
program complexity from the PHP application to the INI file. This
might not be the intention of the people in this list as you are all
pretty sharp, but have you read some of the online tutorials on php? I
just think this kind of feature would be badly abused...
-Chris
On Fri, Feb 15, 2008 at 7:40 AM, Jani Taskinen [EMAIL PROTECTED] wrote:
Dmitry, please don't throw gasoline on the flames.
We have to keep the ini files as simple as possible, this isn't the job of
the ini file.
--Jani
Dmitry Stogov kirjoitti:
The idea makes sense too, but mix of C and SH syntax isn't good.
Dmitry.
BuildSmart wrote:
Now that what-if's are occurring in the theoretical world of
intelligent INI, what about file testing capabilities so that the
following can be used to preload extensions by existance?
#if -f ${EXTENSIONS_DIR}/gd.so
extension=gd.so
#endif
or some other syntax that allows testing to include an extension
On Feb 15, 2008, at 8:19 AM, Jani Taskinen wrote:
Currently UNDEFINED would be just string 'UNDEFINED'.
Doesn't atoi() for non-numeric string make it 0 ??
(or null..:) So that would work without changing anything..
--Jani
Dmitry Stogov kirjoitti:
I think it will work.
#ifdef UNDEFINED 5 (false)
#ifdef UNDEFINED = 5 (true)
(but anyway I think it is possible to find out an unclear condition)
Dmitry.
Marcus Boerger wrote:
Hello Dmitry,
shouldn't this be like in C/C++ where a non existing value is
treated like
an empty string which behaves like false in boolean evaluations?
marcus
Friday, February 15, 2008, 11:25:42 AM, you wrote:
#if defined(PHP_MAJOR_VERSION) PHP_MAJOR_VERSION = 6
extension=unicode.so
#endif
Here PHP_MAJOR_VERSION is a PHP constant that is not defined in
php-5.3 but might be defined in the future version.
Dmitry.
Jani Taskinen wrote:
On Fri, 2008-02-15 at 13:02 +0300, Dmitry Stogov wrote:
Jani Taskinen wrote:
c) We can use just value insted of ${value} in conditions.
Yup. ${foobar} is actually not any variable per se, but just a
reference to existing ini entry in the file. And I don't think
that
needs to change.
Oh, I see. Then we can use just $string (or $str.str) for
ini entries and string for PHP constants. We can also
implement defined() macro-function, to check if constant defined.
Why? Don't make php.ini parsing any more complex than it already
is(n't).
Any string which can pass as constant will have that constant's (or
environment variable) value. Why do you need any variable in there
anyway? And why do you need defined() ??? (examples please? :)
--Jani
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-- Dale
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting
To me it does not make sense to have a scalar type hint. For the
simple reason it's inconsistent with PHP, and it adds no value other
then the fact you then know the value is not on array (or maybe not a
resource?). It's also inconsistent with PHP, array type hinting, is
complemented by array type-casting like print_r((array) foobar), you
can not echo (scalar) Array('FooBar'); for obvious reasons. I
understand type hinting is not type casting (duh) but I think they
should correlate more then they do, it just makes sense.
I have no idea the technicals behind not being able to add stricter
type hints, like; float int string, etc. But that would make a lot
more sense then the proposed scalar type hint. Do it right, or don't
add a hack is my opinion.
-Chris
On Feb 6, 2008 6:20 AM, Derick Rethans [EMAIL PROTECTED] wrote:
On Wed, 6 Feb 2008, Sam Barrow wrote:
On Wed, 2008-02-06 at 09:31 +0100, Derick Rethans wrote:
I still we should add simple static typehints (ie. just the types that
we use in the manual) - and they should behave in the same way as the
other type hints that we laready have.
True, but we have to consider the fact that we don't have enough support
on that side.
This is not some election campaign were you change what you believe in
just to go get followers. So no, I will not take that into
consideration.
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting
Ok. Well the array type hint ensures that it is an array. This just does
the opposite then, I don't see a problem with that. I like to be able to
protected my code from having arrays/objects accidentally inserted into
databases or outputted.
I completely understand you want to create (easier) more solid code;
However the feature is missing and I think scalar is the wrong
supplement for this missing feature IMO.
Who wants to do print_r((array) foobar)?
I've never seen array type casting, it's pointless. You're proving my
point here.
// accepts array of ids, or a single id
function notPointless($mixed) {
$ids = (Array) $mixed;
// do $ids stuff
}
notPointless(Array(13,41,81));
notPointless(31);
This is not casting at all, it's a completely different concept with a
completely different purpose.
Quote: I understand type hinting is not type casting (duh)
Why is a scalar type hint not acceptable if an array type hint is?
That's what I really want to know.
In my opinion have type hinting, or don't. I've found use for array
type hinting, to bad we have no other type hinting to go along with
it. So it's basically a half feature. Sam, I think your points of
creating a more string PHP API using type hinting are fine, but doing
it using Array or Scalar is wrong. It should Be Int, Bool, Resource,
String, etc, it just makes more sense _TO_ME_. That is, if you do it
at all, because type hinting all together I do understand goes against
a lot of the php dynamic type philosophy bla bla. But in my opinion if
it makes the language stronger and more attractive and it DOES NOT
break B/C then its probably a good idea. PHP6 is suppose to be a
improvement right?
On Feb 6, 2008 6:37 AM, Sam Barrow [EMAIL PROTECTED] wrote:
On Wed, 2008-02-06 at 06:30 -0700, Chris Stockton wrote:
To me it does not make sense to have a scalar type hint. For the
simple reason it's inconsistent with PHP, and it adds no value other
then the fact you then know the value is not on array (or maybe not a
Ok. Well the array type hint ensures that it is an array. This just does
the opposite then, I don't see a problem with that. I like to be able to
protected my code from having arrays/objects accidentally inserted into
databases or outputted.
resource?). It's also inconsistent with PHP, array type hinting, is
complemented by array type-casting like print_r((array) foobar), you
Who wants to do print_r((array) foobar)?
I've never seen array type casting, it's pointless. You're proving my
point here.
can not echo (scalar) Array('FooBar'); for obvious reasons. I
understand type hinting is not type casting (duh) but I think they
should correlate more then they do, it just makes sense.
This is not casting at all, it's a completely different concept with a
completely different purpose. A scalar type cast is useless you're
right, but a scalar type hint is completely different.
I have no idea the technicals behind not being able to add stricter
type hints, like; float int string, etc. But that would make a lot
more sense then the proposed scalar type hint. Do it right, or don't
add a hack is my opinion.
Why is a scalar type hint not acceptable if an array type hint is?
That's what I really want to know.
-Chris
On Feb 6, 2008 6:20 AM, Derick Rethans [EMAIL PROTECTED] wrote:
On Wed, 6 Feb 2008, Sam Barrow wrote:
On Wed, 2008-02-06 at 09:31 +0100, Derick Rethans wrote:
I still we should add simple static typehints (ie. just the types that
we use in the manual) - and they should behave in the same way as the
other type hints that we laready have.
True, but we have to consider the fact that we don't have enough support
on that side.
This is not some election campaign were you change what you believe in
just to go get followers. So no, I will not take that into
consideration.
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
