[PHP-DEV] FPM not cleaning up modified ini settings – starting pointers needed
Dear internals, recently I was hurt badly by https://bugs.php.net/bug.php?id=53611. In short, the FCGI variables PHP_VALUE and PHP_ADMIN_VALUE can be used to pass ini settings to FPM. This feature was added in https://github.com/php/php-src/commit/34ba9e39fafa3a980a1b69285f68b0e12ad6b876. These values can come from Apache virtual hosts, that is, they should be treated as being request-specific. Apparently, the clean-up is missing, so configuration settings passed that way will persist and affect the next request(s) served by the particular FPM worker process. This is surprising at best, since the settings can come from unrelated virtual hosts and seem to "come and go", depending on which worker process happens to serve a request. My guess is that since userland ini_set() settings are reverted at the end of the request, this should be possible in this case as well. As my experience with the php-src codebase is very limited, may I kindly ask for some starting pointers, first hints what to look out for or examples of other modules or SAPIs that already perform similar clean-up tasks? Thank you! -mp.
AW: AW: [PHP-DEV] Namespace resolution
-Ursprüngliche Nachricht- Von: Stanislav Malyshev [mailto:[EMAIL PROTECTED] If the class for which autoloaded request is issued *exists*. However, we are discussing the case where this class *does not exist*, so it can not be loaded. Thus, autoload request will be repeated on each access to such class. Just a quick idea - what if requiring that autoloaders behave deterministically, that is, once a certain autoloader implementation has been given the possibility to find a class it will never be asked again (because it wouldn't find it later on either). That might allow for caching the decision, so the next time you hit the same unqualified name you know what is meant? Does that make sense? -mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: AW: AW: [PHP-DEV] Namespace resolution
Just a quick idea - what if requiring that autoloaders behave deterministically, that is, once a certain autoloader implementation has been given the possibility to find a class it will never be asked again (because it wouldn't find it later on either). I'm not sure if it's a correct assumption to make in general case - files can be created. Currently, when an autoload handler is given the chance to load a class and it does not, maybe another handler will do. Either way, the script will terminate if no handler can find the class or the class will be available after that - so already now it is impossible that any given handler is called twice during the same execution for the same class name. Maybe I'm missing some weird cases for opcode caches or otherwise embedded PHP though? -mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: AW: [PHP-DEV] Namespace resolution
Von: David Zülke [mailto:[EMAIL PROTECTED] The problem I see with that is that if I have an application that uses a 3rd-party library which does not use namespaces, I need to use ::LibClass everywhere. Until they switch to namespaces - then I need to touch hundreds and thousands lines of code. If LibClass were looked up in the global namespace, too, I could simply add the appropriate import statements at the top of each file. You got a point. Anyways, the process you described seems flawed in another fashion: It looks up a class in the namespace first, then an internal php class, then it tries an autoload. That does not make sense. Lets say I run some code as you described, and there is a class C(), but it's not been autoloaded yet. The internal class C is used. Then, later, the autoloading of A::B::C() is somehow forced. Now, if the same code runs again, a different class is used. That sounds like nonsense. Exactly what Chuck and Greg tried to point out, providing examples for what you describe. http://www.mail-archive.com/internals@lists.php.net/msg31217.html In my opinion one of the biggest weak points. In order to make things work consistently and reliable (behaviour does not change because of the order in which files are included or because new core classes are added), you need to 1) make sure all the stuff you use is already known (that is, refrain from using __autoload and revert to require() at the top of your files) or 2) explicitly use/import all your classes, even the ones from your namespace inside your namespace. That is because __autoload comes after internal classes (which comes after already known classes from the current NS) for unqualified names. Approach 1) makes the names already known, 2) turns the unqualified names into qualified ones by means of aliasing. :( -mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: AW: [PHP-DEV] Namespace resolution
Von: Stanislav Malyshev [mailto:[EMAIL PROTECTED] But you could achiever the same just by avoiding naming classes the same as internal classes, you surely know which classes are in your own namespace? ... Not using names of classes same as internal classes is not a big deal either - all PHP programmers do it right now :) Rumor exists that sometimes new internal classes show up in late RCs. And as you try to name your classes so that the name describes the modeled construct best, it is not surprising that core wants to name such a new class Date just as userland folks had their classes named Date as well before (shame on them). I always thought that one of the prime reasons for providing namespaces was to mitigate this risk of breakage in a simple, predictable and user-friendly manner. -mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Namespace resolution
-Ursprüngliche Nachricht- Von: Sam Barrow [mailto:[EMAIL PROTECTED] Gesendet: Montag, 10. Dezember 2007 22:48 An: internals@lists.php.net Betreff: [PHP-DEV] Namespace resolution Ok, it's supposed to be this way right? If i define a custom class in the global namespace called myClass and I'm in another namespace, I can only access it using ::myClass, not just myClass (without the colons)? Seems to me that it should check the local namespace and then the global, but it only checks the globl if i specifically tell it to with the preceding ::. From http://www.php.net/manual/en/language.namespaces.rules.php: -- Inside namespace (say A::B), calls to unqualified class names are resolved at run-time. Here is how a call to new C() is resolved: 1. It looks for a class from the current namespace : A::B::C(). 2. It tries to find and call the internal class C(). 3. It attemts to autoload A::B::C(). C(). To reference a user defined class in the global namespace, new ::C() has to be used. -- Which is exactly what you observed. -mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] A rebuttal to Re: RFC: Dropping Namespace
1) recommend all global non-namespaced code that wishes to import
namespaced code via use Namespace::Classname add a namespace
__php__; at the top of the file, and that the __php__ namespace be
reserved for use by end-user applications.
5) namespaces provide these benefits that are not available in PHP:
a) short, unqualified descriptive class names can be used without
fear of conflicting with an internal class
Interesting as I was not aware before that when a namespace is active the
import goes into that namespace and not into global scope (clashing with core
classes there).
But please consider:
-- Date.php --
?php
namespace __php__;
class Date {}
?
-- test.php --
?php
namespace __php__;
require_once('autoload.php'); // assume it would require Date.php when
asked to do so
print get_class(new Date());
?
Although this code has been future-proofed by adding the namespace __php__,
it will break if the core introduces a class named Date (will use the wrong
class!). It also breaks without the namespace, and maybe it is a mistake to
rely on autload here. But this is a case where using namespaces does not
protect you from surprises unless you explicitly import (use) all the classes
you need. But that is not as simple as putting a namespace statement on top of
all your files to be save.
If new, future core extensions showed up in a reserved PHP:: namespace, you
would be :-).
-mp.
AW: [PHP-DEV] A rebuttal to Re: RFC: Dropping Namespace
Von: Gregory Beaver [mailto:[EMAIL PROTECTED] Exactly - which is why you should never put classes, functions or constants in the __php__ namespace. The convention I am proposing is to only use __php__ for code that *uses* re-usable components, not *declares* them. Let alone __php__. If you just put all of your code into namespace Mylib, you're not safe because according to the name resolution rules, internal classes come after imported ones but before trying to find classes in the current namespace. 1) library code is always explicitly used 2) name conflicts are impossible 1) is the crucial one because that puts your classes ahead of the internal ones in the resolution list. That is not only library code you explicitly use, but also all code from your own namespace. Having to explicitly enumerate all classes you use in your own namespace in every file may be tedious. So just to get that straight: Having a namespace statement and no use (because all you use is from your library) is a discouraged practise? Thanks! -mp.
AW: [PHP-DEV] Re: RFC: Dropping Namespace
Von: Steph Fox [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 5. Dezember 2007 02:34 import nstest::test as whatever; This works in the global space, right? Now along comes, say, Pierre or Derick or Marcus with this class they just have to add to an existing (non-namespaced) core extension, and the obvious and perfect name for this class happens to be 'whatever'. I upgrade PHP and suddenly I start seeing Fatal error: Import name 'whatever' conflicts with defined class in ... Indeed it's pretty pointless if future additions to the core break (namespace-aware) code that previously worked. I am probably alone with that point of view, but: Given that it was technically feasible, (future) core classes should be in namespaces as well. The whole namespace thing depends on that everybody (users, library providers and the core) collaborates and puts their stuff in their namespace so that everyone can decide in their file which classes are needed. Global namespace is precious, so let the user decide which classes to have there. For the same reason, supporting use Library::* is a bad idea because that might break working code the same way as above if the Library introduces a new class. -mp.
AW: [PHP-DEV] Garbage collector patch
To summarize the patch lead to approx. 5% slowdown and 3% memory overhead for typical applications (as always, you mileage may vary depending on your system's architecture and OS although my guesstimate is that you will see even worse results in a 64bit environment). Does that slowdown result from housekeeping tasks alone that are a prerequisite for GCing or does it include running the new algorithm? Is it possible to always perform (unconditionally compile in) the necessary housekeeping tasks but stick with the current GC, so that cycle-detection only happens when the user calls a gc_go_find_cycles() function? Would that significantly improve the above numbers? -mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: AW: [PHP-DEV] Garbage collector patch
Is it possible to always perform (unconditionally compile in) the necessary housekeeping tasks but stick with the current GC, so that cycle-detection only happens when the user calls a gc_go_find_cycles() function? Would that significantly improve the above numbers? Yes, that would be possible, but it wouldn't speed anything up in case you don't have any cycles. Not sure I got you right. That is, the speed penalty comes from housekeeping? Does the new GC try to find cycles automatically whenever a refcount goes down to zero? If building and maintaining data structures for the algorithm costs only a little memory but speed impact is neglegible unless the algorithm actually runs, then you could stick with the non-cycle-detecting legacy GC (= speed) unless you know you have cycles and/or want to trade a little processing time (a call to gc_go_find_cycles()) for the memory it will/might free. -mp.
[PHP-DEV] preg_match and shared libpcre3 bug
I know this is weird and off-topic but I hope that someone here can give
me a starting pointer.
With installing a security update for the pcre3 library on Debian
(http://lists.debian.org/debian-security-announce/debian-security-announ
ce-2007/msg00177.html), preg_match('|^\(|', 'xxx') suddenly returns 1
instead of 0 using PHP 5.1.6.
The thing is - I have built PHP using the bundled PCRE library and the
error happens only with the apache2 module, not with a CLI binary.
phpinfo() shows PCRE 6.6 and ldd shows no dependencies against the
shared libpcre.so.3, neither for the php-cli binary nor for the apache
module.
Any ideas what might cause that? I can't see why the shared library
update makes a difference at all.
Thanks!
-mp.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] foreach with referenced values
Hi internals,
please consider:
?php
print PHP_VERSION . \n;
$a = array('a', 'b');
foreach ($a as $ref) ;
$b = $a;
$a[0] = '*';
print_r($b);
?
Result:
5.2.0
Array
(
[0] = *
[1] = b
)
Same with 5.1.4 and 5.1.6. I suppose that using foreach and referencing
the values turns the elements in $a into references, $b is a copy of the
array containing *references* and thus chaning the value of the first
element in $a is visible in $b because both arrays reference the the
same value?
When moving the $b assignment before the foreach, everything works as
expected.
Is this really intended behaviour?
Kind regards,
mp.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] foreach with referenced values
Did you try a snapshot? 5.2.1-dev Array ( [0] = a [1] = b ) Thanks, sorry for the noise. mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Re: [RFC] Magic Method that handles unset($object)
-Ursprüngliche Nachricht- Von: Ants Aasma [mailto:[EMAIL PROTECTED] That would indeed be too slow. The standard way to handle this, is to only check visibility periodically. That is how Java, .NET, Python and countless others do that. Check http://www.hpl.hp.com/personal/Hans_Boehm/gc/ for a sample of how an implementation might look like. The whole issue comes up regularly on various lists, e. g. Propel or Phing suffer from it. Also see http://bugs.php.net/bug.php?id=33595. Working around this in userland may be possible but is at least painful and messy. If the only problem is that detection is slow, wouldn't it be possible to add a gc_cleanup() function that performs the scan? Those who use PHP in a request/response environment need not care (everything is freed at the end of the request). Those who don't and hit the problem regularly will find a good place to make this call and certainly won't complain about the delay. mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] [RFC] Magic Method that handles unset($object)
-Ursprüngliche Nachricht- Von: Etienne Kneuss [mailto:[EMAIL PROTECTED] Gesendet: Sonntag, 10. Dezember 2006 15:55 Cc: internals@lists.php.net Betreff: Re: [PHP-DEV] [RFC] Magic Method that handles unset($object) You could use references, you would have to move some code around, though. I'm not sure that's exactly what you want, but give it a shot: ... $parent = setup(); $parent = null; This happens to work in this case because when you assign null to $parent you break the reference circle in the parent/child-relationship by the way because you work with references. It's not a general solution, though. mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] file_exists() and safe_mode
Hi all,
I'm afraid that recent changes in filestat.c [1] that were meant to fix
a bug [2] with file_exists() also altered the behaviour of
is_readable(). According to the docs [3] [4], is_readable should *not*
take safe_mode limitations into account, whereas file_exists should do.
?php
print PHP_VERSION . \n;
var_dump(ini_get('safe_mode'));
var_dump(file_exists('/etc/hosts'));
var_dump(is_readable('/etc/hosts'));
?
[EMAIL PROTECTED]:~$ php bug.php
5.1.6
string(0)
bool(true)
bool(true)
[EMAIL PROTECTED]:~$ php -d safe_mode=1 bug.php
5.1.6
string(1) 1
bool(false)
bool(false)
Is this intended behaviour? If not, I'd be glad to file it as a bug.
Kind regards,
mp.
[1] http://cvs.php.net/viewvc.cgi/php-src/ext/standard/filestat.c
[2] http://bugs.php.net/bug.php?id=37987
[3] http://de2.php.net/manual/en/function.is-readable.php
[4] http://de2.php.net/manual/en/function.file-exists.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] file_exists() and safe_mode
I think the current behavior solves made old bug reports, where by people used is_readable() to see if they could read from a file, only to have the operation file due to safe_mode/open_basedir restrictions. Taking the check away would also mean it would be possible to explore file file system bypassing PHP's file system restrictions. So this is a documentation bug and there is no way to check beforehand whether an include($filepath) will succeed or not when safe_mode is on? Kind regards mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] AW: file_exists() and safe_mode
i dont think this is a recent change. i think its only an oversite in the documentation. [EMAIL PROTECTED]:~$ php ./bug.php 5.1.4 string(0) bool(true) bool(true) [EMAIL PROTECTED]:~$ php -d safe_mode=1 ./bug.php 5.1.4 string(1) 1 bool(true) bool(true) With 5.1.4 both file_exists() and is_readable() ignored safe_mode restrictions, so the docs were wrong for file_exists() (which is what bug #37987 was about) and correct for is_readable(). Both functions changed their behaviour, now either this behaviour or is_readable() docs are wrong. mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RfC: rethink OO inheritance strictness
From: Soenke Ruempler [mailto:[EMAIL PROTECTED] BUT let derived constructors change parameters a) as constructors are never called from the parent, but optionally from a child class, it's completely valid IHMO b) constructors are usally not used in object aggregation / setters, but called only _ONCE_ at object creation = the creating code knows the exact (sub-)class and it's constructor. You gave the reason why the restrictions don't apply for constructors (also not in PHP) and probably nobody will change that for academic reasons :) Constructors are the special case in OOP as you can call constructors only by instantiating classes. When using them you always refer to a concrete class and never have to deal with polymorphic subtypes (of course constructors can be overloaded in languages that support it). Thus constructors are a place where differences between subtypes tend to pile up so that the LSP holds for the rest of the inherited methods. If you *want* to enforce constructor signatures PHP allows for defining them in interfaces which makes no sense from the academic pov, but may be useful when using the PHP feature of new $classname($arg) where you want to make sure first that $classname instanceof ISomehowConstructable (where instanceof must take a string as the first operand and work accordingly). Regards, Matthias -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Basic Namespace Requirements
Von: Jessie Hernandez
So, the question is, can we scrap both namespace constants
and namespace functions and just stay with classes (as was
agreed on several months ago, Andi himself agreeing to it)?
...
I think this is the best solution thus far. If any one of you
still feels a need for constants/functions, PLEASE show me a
_valid_ example that cannot be accomplished by just simply
putting the constant/function inside a class in the namespace.
Bart de Boer came up with a good reason for them so I'd like to re-post
his statement.
quote
Namespace constants can be handy if you'd want to include some library
that uses predefined constants and classes that might conflict with
other classes and constants in the script.
namespace someLib {
include('huge_conflicting_library_that_I_dont_want_to_reverse_engineer')
;
}
/quote
Of course, that would not only require to put defines [=constants?] and
functions in namespaces, but variables as well.
namespace X {
var $foo = 1;
function bar($p) {}
}
X::bar(X::$foo);
which can, of course, not easily be distinguished from static class
members.
So is the whole include-legacy-stuff-into-namespace-approach beyond
the scope of what you're trying to do?
-mp.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there)
I have to back Sebastian with what he said. Obviously the release methodology currently applied does NOT work, neither for the project nor the community around it. Do it how ever you like - discuss whether it's legal to add new features on HEAD only or on release branches like Jani said. BUT: Once you agree the work is done on a branch and you make something available that has a RC in it's version name, it's GAME OVER. No more features. Only bugfixes. That is the only way for ppl to make sure there will be no unnecessary and unexpected changes anymore. Once my software passes tests with an RC, I can assume in good faith that it's very unlikely to break again. You cannot expect folks to re-test everything with every new RC, and so it's not PEAR's fault if they were not the first to notice the problems. Remember the discussion about curlies? I also never understood why that had to be tackled in an RC5. Should you find out late in this process a feature has been forgotten (i.e. #ifdef'd out) and you all agree that it has to go in - abort the RC phase, put it in again, restart (maybe with another RC name) to make ppl clear that they *do* need to re-test. If you're kind, assert that there will be a certain time between RCs and releases, or communicate with your major community projects out there to make sure they do their work or do whatever. But there is just a single simple basic rule that needs to be adhered to - that's all Sebastian pointed out. -mp. -Ursprüngliche Nachricht- Von: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] Gesendet: Samstag, 26. November 2005 16:49 An: Sebastian Bergmann Cc: internals@lists.php.net Betreff: Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there) No one project follows the same release methodoly, everyone uses what works for them and the community around the project. Ilia -- 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
AW: [PHP-DEV] Re: PDM Meeting Notes
Well, safe_mode could prevent someone of doing a shell_exec(cat /home/otheruser/web/config.php); open_basedir can't do the same thing. We were in a continual losing race against that sort of thing though. In pretty much every single release there have been ways to do this that got around safe-mode. Because of bugs in the safe_mode implementation (forgetting some checks?) or conceptual problems? I have always maintained that shared hosts should be running per-security context Apache instances as different users. The problem with that is that it makes name-based virtual hosts pretty pointless because each apache instance will at least need an ip address on its own. -mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Re: PDM Meeting Notes
Well, safe_mode could prevent someone of doing a shell_exec(cat /home/otheruser/web/config.php); open_basedir can't do the same thing. disabled_functions=shell_exec, etc But safe_mode is more safe because it disables these functions altogether? It's difficult to maintain a complete list of bad functions in php.ini. -mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there)
Or a) am I missing something b) is it the core developers' opinion that core classes have the right of way? kidding If things behave like that at least there should be a list of reserved class names just like with other keywords. And of course that list must not be changed as it is considered practical. /kidding I don't think PEAR has done anything wrong here; it was never disallowed to have a class named Date. And it's not only a PEAR problem but affects pretty much everyone out there with more than a few hundred lines of OO code. If it was a failure of QA, clearly one of the language core QA itself. Maybe namespaces are a solution, but until there is a good solution for the basic problem, stop adding classes to the core that way. Often it's hard enough to find short yet precise class names; and there is also a set of commonly used or agreed-on class names (just think of the common patterns). In no case anything done in the core must inflict with or otherwise touch that set - or forget about that enterprise ready stuff altogether. -mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps outthere)
Then I have to ask both of you: why is there no mentioning in the release notes or the upgrading guide regarding Date being reserved for PHP now? I was also curious as to that. Once again the release announcement (more precisely, the upgrade document) greatly understates the impact: 9b. Class constants in new PHP 5.1 extensions [...]in order to minimise pollution of the global namespace in PHP. Note that the new Date class exists at this point purely to allow the core date extension to adhere to the above convention, although extended functionality is planned for the the class in the future. At least I'd say this is diplomatic. You need to have a delicate understanding to even notice it, let alone understand the impact. And as to polluting the global namespace - well, this one is a supertanker that has just sunk at the shore of OOP. The language/base library might want to reserve certain simple classnames for itself. That is its right. Not, not even that when it comes to most obvious names like Date (or Page; User; Form...) or to commonly used ones (like Controller, Database, DAO, Singleton, Observer...). But: Doing so in a minor release is absolutely bad timing. It gets worde because there apparently has been _no_ documentation of the fact at all. How shall our users prepare themselves appropiately? Not even in a minor relase, but with the very last RCs. This is a smack in the face of all who even tried to keep up. -mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps outthere)
Yes, and that will break code again as I just explained to Sebastian Kettler. And it will break *my* code ;-) Too bad I don't find the right mail to qoute you now literally - but nobody forces you to use the official PHP codebase for your stuff; go ahead and maintain releases for yourself. Unfortunately my english vocabulary lacks words powerful enough to express what I think about your code and your damn arrogance. In no way I have contributed as much as you but that does not stop me from stating that this is once again a maximum credible accident for the PHP project as a whole; and once again the way you comment on this as one of the very core developers is major PR disaster. The way things went is so incredibly ridiculous that everyone being responsible for major IT budgets, investments or decisions will be laughing at the project and its community as a whole. -mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there)
obviously one problem is that PEAR does ignore coding standards. Classes should be prefixed in both pear and core. And neither Date nor File is in any way prefixed. Err, how are we supposed to prefix PEAR::Date? PEAR_Date? Date_Date? Lala_Date? The whole thing is nothing PEAR is to blame for. Even if PEAR had noticed it earlier and renamed it to supercalifragilistic_Date and had gotten out the update to everyone fast enough - still it would require everyone using the PEAR class to reflect the change in their very own codebases. -mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps outthere)
I didn't say that my code is more important, but if we don't get the date class now, we will get it in 5.1.1 and then break your code - so that doesn't really matter. THe only correct solution is to start prefixing the pear date class, as that needs to be done in the long run anyway. Derick, this is not only about the PEAR date class but about pretty much every larger PHP codebase/project. You don't seem to understand the impact. No no, the core reserves the right to name whatever they want, it's the userland code that is responsible for prefixing their classes. Actually I just decided to work through my 100,000 lines of code and rename every class; for the sake of forwards compatibility, I'll generate GUIDs for each class and keep a mapping table on my desktop. Oh, and while I'm at it, I'll switch over to some other language as well. -mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: AW: [PHP-DEV] Re: PDM Meeting Notes
I have always maintained that shared hosts should be running per-security context Apache instances as different users. The problem with that is that it makes name-based virtual hosts pretty pointless because each apache instance will at least need an ip address on its own. It seems you've never heard of suexec, FastCGI, MPM Perchild (ok, this one is broken) and Zeus (has nothing to do with Apache, but is a good product). It's possible to have name based virtual hosts in Apache2 and PHP processes running in the context of every user with a patched suexec, mod_fastcgi and one single IP. I do have - but to me the recommendation above sounded like running a difference apache instance (i. e. main server process) for every security context. -mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Re: PHP 5.1 (Or How to break thousands of appsout there)
Von: Andi Gutmans [mailto:[EMAIL PROTECTED] BTW, just to clarify, I am not against a Date class (whatever its name) in the long run but I think it'd probably be a combination of work Derick, Pierre and new contributions. It would be nice if there would be some 'official' statement as to there will be some kind of namespacing concept before the time where the language core will start picking and reserving class names in a broad manner. To me it seems that right now the inner circle seems to agree that the core may pick names at random and has a right of way, so that it is up to the php infantry (us coders) to use prefixed class names or whatever to at least mitigate the risk of name collisions. Anyways, I think there should be a discussion about policy issues: - Deadlines for new features/BC breaks - What may be changed in RCs, when will a RC have to be revoked and the release process re-started - How can we make sure at least some of the more popular projects have enough time to resolve problems - Who may do what and who will have to agree/sign/back the decisions made? - How changes/BC breaks will be recorded and announced in an clear, non-understating manner - What long-term enhancement/feature/change/migration/BC-breaks plans are there? I still don't understand why - despite all the discussion here - the 5.1 release is still on the php.net website, being publicy announced and there is not even a single hint what problems users might run into. Every major company has a disaster recovery plan to make things go quick in case of emergencies. The release is out for almost 24h now and nothing happens. -mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Re: PDM Meeting Notes
-Ursprüngliche Nachricht-
Von: Jani Taskinen [mailto:[EMAIL PROTECTED]
We could start with making it an E_ERR..erm..E_STRICT notice
if you use {} with arrays or [] with strings. And really separate
them in PHP 6. But does it make any sense?
At least some people here would appreciate it :)
This would be consistent with what has been advised in the past, and making []
on strings an E_STRICT is the logical step after deprecating it as of PHP4 and
before disallowing it in PHP6.
Maybe there's more code out there incorrectly using [] on strings rather than
using {}, but that doesn't make it more right. And nobody would complain about
an E_STRICT.
Removing {} is ultimately the right thing to do, whatever the
anti-purists may think.
That is, purism is to have as little different language elements as possible at
the cost of overloading? At least I agree that [] and {} being the same is not
pure.
{$str{1}} vs. {$str[1]}, you decide..
Admittedly this is ugly to read but the same thing on the other side is
$var[$x][$y] vs. $var[$x]{$y}.
Just as checking if there's more code out there using $x[1] or $x{1}, you could
check if {} is used more in string contexts or in standalone expressions (not
seriously).
-mp.
Oh, btw: http://en.wikipedia.org/wiki/Linguistic_purism: Linguistic purism is
the opposition to any changes of a given language, or the desire to undo some
changes the language has undergone in the past. So what do the anti-purists
want here? Anti-purism: A puristic reaction to a manifestation of purism,
directed at the removal of neologisms originating from a puristic intervention.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] PDM Meeting Notes
Anyway, I see only one use case for interface constructors: ... I also thought about that: $whichClass = ... if ($whichClass instanceof ISomehowConstructable) $foo = new $whichClass(...); would even work without reflection, but of coure would require to change instanceof a little, too - similar to the way is_subclass_of works right now. -mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] PDM Meeting Notes
Great, I have been waiting for this list sine Derick mentioned the meeting in his talk at the conference :) @Derick: There have been some questions and issues raised during your talk... Dou you remember them? It was about reading from files with the new unicode semantics, and you said these were some things you need to discuss. I don't see anything that looks related... Do you remember what it was about? 2.10 Dynamic class inheritance Can someone elaborate a little on what this is supposed to be ;)? 5.2 Allow interfaces to specify the __construct() signature Discussion: We didn't see a reason why this shouldn't be allowed, but Andi seems to have a reason for it. Conclusions: Zeev asks Andi why he doesn't want constructors in the interface. If there is no sound reason we add this possibility. I had a discussion about this with a colleague recently. IMHO specifying construcor signature does not make sense at all in interfaces... What is that supposed to do at all? I mean - conceptually, what does it express? 5.3 Implement inheritance rules for type hints Issue: Currently we don't check inheritance rules for type-hinted parameters. Could someone please explain what exactly is/is not checked? 5.4 Late static binding using this without $ (or perhaps with a different name) Interesting feature :) I've been missing that on C# recently ;) As to type hinting, has there ever been a discussion about allowing string/int/... type hints? These could perform appropriate casts so you don't need to make such checks at the beginning of every method you write. -mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: AW: [PHP-DEV] PDM Meeting Notes
Now that was a quick reply :)
Also known as runtime inheritance, or late binding. It's not a new
thing, we have it today. The discussion was about whether to
have a way
...
That is, one can write
if (...) class A extends X {} else class A extends Y {}
right now? Seriously ;)?
Every now and then I'm surprised what weird sort of stuff is allowed in
PHP :), but most probably you don't really want to write this sort of
code in the first place? ;)
Just like any other signature in an instance, it tells anything that
implements the interface that it must have a constructor and that
constructor must meet the definition in the interface. Useful for
object factories. In most cases you don't want to force a specific
constructor in which case you wouldn't specify it in the
interface, but
I see no reason why you shouldn't be allowed to specify it
there if you
want to.
The point is that interfaces are nothing you could anything with - that
is, if you have something that implements an interface, it has already
been constructed. You never construct instances through an interface
(you would have to choose an implementation, the interface isn't one)...
I just cannot explain it in a better way ;) It's somewhat similar to
that you cannot make static calls on interfaces.
Maybe someone could explain what they intend to use it for and what they
suspect it to do ;)?
-mp.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] PDM Meeting Notes
I don't see why you can't specify that a class definition must have a constructor. Obviously the constructor is not for the interface itself. Ok, that is, having __construct in the interface asserts that everything you get passed (as an implementation of the interface) has been constructed by a constructor that has a certain signature? :--/ Of course it also doesn't make sense to call __construct on the implementation passed along. Luckily this is nothing I'm forced to write in my code ;). I only wanted to utter I have a Bad Feeling(TM) if you invest time and effort to make stuff like this work if the result is something that seems to make no sense [to me only?]. And once you allow it, be sure ppl out there use abuse it and will complain should you ever have to remove it again. .. I'm just trying to make up a scenario where the above might make sense - it could be where you have something like a factory method. It has a type hint on it's argument to make sure what gets passed in implements a certain interface. That interface defines the signature of __construct, so the method can construct instances of the thing - only knowing that the instances constructed will implement the interface (?), but not knowing their implementation. But how should it construct instances? new INameOfTheInterface()? And besides that, problem is again that the thing passed in would have to be something representing a class, and not an instance of the class itself. You could always (gut feeling) re-design this to work the usual way by passing in something representing a class and providing behaviour to construct instances. I hope Andi backs me :) -mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Curlies again [was: Upgrade notes for PHP 5.1 - final draft]
If I got that right, you still want to discourage {} and un-deprecate []
again, despite all the good reasons given on this list not to do so?
PHP5.1 would be accomplishing facts as to this one. (Let's remove {}
altogether in 6 - nobody should be using them anyway as they were
deprecated since 5.1).
The discussion on this list would be silenced and take place out there
with a much broader audience instead.
Changing language syntax that way back and forth again will cause a loss
in credibility - once again after the 4.4.0 release.
-mp.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Curlies again [was: Upgrade notes for PHP 5.1 - final draft]
Derick, If you prefer a PHP which causes strange crashses and memory corruptions, please downgrade to 4.3.11. I am getting tired about this bickering about this **FIX** that makes PHP stable. You got me wrong here. I did not want to say anything against the 4.4.0 fix or even blame you for it. But: nobody doubts that there has been a lot of public discussion about it, that people were upset because they felt the language has been changed in a way that caused them a lot of work and because their scripts suddenly broke (and if only a by showing a warning or notice, however). I was only saying that you (i. e. the people who have enough karma to make the final decisions here) should not light-heartedly make such a change - and in this case, with no obvious need for it (apart from cleaning up - I know myself that sometimes this is tempting for developers). As to the possible impact - I did a quick scan of Smarty and phpDocumentor (because I used to have CVS HEAD checkouts of them at hand) and found that both of them would be affected. Please, do not make such a change that late in an RC5 and push it out with PHP5.1. At least give the maintainers of popular PHP based projects some time to pick it up and test it. As with the 4.4.0, this is nothing you cannot fix or workaround or suppress with an appropriate config. But once again the average user out there might once again feel lost out there simply because his hoster did the upgrade. -mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: AW: [PHP-DEV] Curlies again [was: Upgrade notes for PHP 5.1 - final draft]
This is a non-issue for phpDocumentor. All we need is at
least 6 months
to a year of lead time on the final decision in order to
adjust the code.
As I wrote, I happend to have Smarty and phpDocumentor checkouts at
hand. I just checked a recently installed version of Mediawiki and they
also use curlies (although only in a very few places). But at least this
should be a good argument against nobody out there is using them
anyway. Let alone all the other good reasons. Oh, btw, phpMyAdmin also
uses them.
However, it is obvious that a script is needed that iterates over a
script and changes things that are easy to fix like the
$a{blah} one. I
Yeah, someone just started a thread regarding this idea. As to this
special case, maybe you can automagically find exactly the affected or
possibly affected lines of code and update them.
But more generally, I think writing the general purpose automagical
updater is infeasible because sooner or later you'll run into issues
you cannot detect or fix with a lint-type analysis but that require real
execution of all possible code paths (e.g. stricter function argument
parsing, changes in handling of NULL when used in array functions,
passing non-array to array_merge...). Even worse, something like
reordering function arguments (as somebody mentioned shortly mentioned
here?) can only be detected by having specifically written test cases at
hand.
2) be thankful this is transparent enough that we can have
enough lead
time to make small changes to legacy scripts as needed - this
is why the
E_STRICT is added to PHP 5.1 now. Would you prefer a sudden break in
PHP 6 without any warning?
Apart from that nobody has given a sound reason yet (maybe I missed it)
why it needs a change at all, as we know from recent history there are
people out there who happen to get notices on their sites and consider
that breaking things.
So for these people, this issue by itself is why things might break as
soon as their hosters upgrade to 5.1.
3) ALWAYS test RCs of releases when they come out with our critical
applications and note any breaks here, to determine whether they are
bugs or intentional changes in PHP.
That was yet another thing I felt disturbing and complained about but
noone has commented on that yet - why do you need to make changes like
this one in RC5? Every change that is later than an RC1 is more likely
to be missed by people, even those who are diligently testing their
stuff. Additionally, RC5 is damn pretty close to a release and that puts
unnecessary pressure on people to get it fixed.
Sorry for being so annoying.
-mp.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Upgrade notes for PHP 5.1 - 4th draft
- abstract is no longer valid in interfaces. - that curly brace thing? I've some fear of terrifying would-be upgraders with an unnecessarily long list here :) You're kidding. If you're intentionally not adding things to that list, better do not compile the list at all. If people use it as a pre-upgrade checklist and still get in trouble because of some item not mentioned, guess what they will do the next time? Upgrade, but to another language. You need a list like this to gain trust in that it's worth upgrading and in sticking to PHP. mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] dropping curly braces
Anybody interested in my two cents? (I shouldn't have asked as I'm going
to tell you anyway.)
rant mode on
You will break many more scripts by dropping [] for strings than the
other way around. Do you agree? - Heck, this sounds as if you're doing
a let's drop stuff for some technical reason no average PHP coder will
understand contest and choosing which one to remove based on some rough
estimates.
You're simply deciding for the one you expect a lower collateral damage
from. You're ignoring that it's the one you proclaimed as the new right
way to do things.
Your credibility gets lost. Credibility is the foundation for broad
acceptance of projects like PHP.
New users will simply be upset and try the other language currently
hyped (guess what). If you tell professionals making the IT decisions in
larger companies about the stuff that recently happened or happens here,
guess what they will tell you? They don't dare to use PHP because nobody
guarantees them that the language itself is reasonably stable and
predictable; they want something to rely on, with upgrade paths that
will cause them no problems (and they're willing to spend money on
license costs or whatever as long as they don't have to touch or rewrite
their code every half a year).
Take a more professional attitude. You cannot say things like well,
that was a mistake, nobody picked it up anyways, we just revert it.
This is a smack
in the face of developers acting in good faith and following your
recommendations. You can do stuff like that on unstable code or in CVS
head - but you cannot add {} and deprecate [] on PHP4, keep it on PHP5
and revert on PHP5.1.
Honestly, during the last few months I got the impression that people
making such decisions only see whether they need a feature or how much
it affects their own projects or their own company's codebase.
Maybe there are simple ways to scan codebases and find possibly affected
lines of code. Maybe the workaround is simple. Maybe it is as silly as
it was with return new Foo(); = return $tmp = new Foo();. But, you
can make this once, but you cannot tell people to touch their code over
and over again with every new release.
--
And yet another thing: why is a change like this made in RC5 at all?
In the best case, people with large projects/codebases out there will
test their code before the release comes out. Early snapshot tests help
to find out about fundamental changes so you can tackle fundamental
problems early. But the new release may not be stable enough so this
cannot be the final test.
RC1 is a point in time where you would definetly start testing your
apps, as it won't be too long for the release to come out. OTOH, you
should expect the RCs to be sufficiently stable, to that if your code
passes tests with RC1, you can lean back. Everything else that follows
should just fix small glitches that have been overlooked before.
Even the attempt of trying to change or remove some language feature
like the {} thing IN A RC5 is unbelievably unprofessional.
You cannot happily attach RC to the version number when you feel that
you're almost done. Oh, hm, lets make another modification, roll a new
RC. The RC suffix is worth nothing in this case.
When it's a RC, it's feature freeze. Test. Fix small bugs. No more
additions. No changes. If a major problem is detected, abort, go back to
workbench and correct it. Remove the RC from the version unless you're
done.
Anything else is like trying to quickly put in some newly designed
engine parts on the space shuttle - while it is at the launch pad at T-4
seconds. And keep the countdown running.
rant mode off
Sorry, but I just swallowed that bitter 4.4.0 pill. I tried to see the
migration to PHP5 as an opportunity to review old code. But the way this
possible change was introduced now is making me go nuts.
-mp.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
AW: AW: [PHP-DEV] dropping curly braces
For the 13th time. {} is not going away in 5.1.
From the NEWS file:
16 Nov 2005, PHP 5.1 Release Candidate 5
- Added an E_STRICT warning on the usage of {} for accessing of string
offsets.
(Ilia)
That is, code that has been tested with RC4 and that worked (not even a
notice on whatever error reporting level) might suddenly misbehave
(produce warnings) as of RC5.
Now don't start that stupid disable error output on production systems
discussion again. I want my code to work on whatever setup my customers
use and I have no control over that.
Even if it's as simple as emitting a warning - it is a stupid,
unnecessary change in the RC phase. That is about professionalism.
-mp.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
AW: AW: AW: [PHP-DEV] dropping curly braces
I suggest removing that warning immediately until the matter is resolved. +1 ( times the discount-for-rants-factor ) -mp -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] interface method visibility.
why does the engine care about the visibility of interface methods I declare? I understand the argument that interface methods only have 'meaning' when applied as public methods of objects - but thats rather academic and personally I can think of useful ways to abuse interfaces using protected methods at the very least why am I not allowed to do this just because someone decided that its not correct? Having anything else than public in an interface simply does not make any sense - an interface serves as a contract to external clients. It guarantees them that there will be a set of methods they can call on an object instance. What should be the semantic meaning of non-public elements in interfaces? and given that I can implement a non-static method without using $this or any other symbol/code related to the instantiated object (effectively creating a static method) which I can call using static notation why not allow static interface methods? As to static interface methods - same as above. An interface is an interface :), not an implementation. So you will never have methods implemented in an interface. The interface just says the class implementing the interface has a method named xy() that you can call. So how would you make the static call on the interface? ISomewhat::someMethod()? Where should that be implemented? This is why you always need an instance that implements the interface and you make a normal call on this instance. PHP allows - as opposed to C# or Java (IIRC) - to call static methods on instances. I think the fact that you can call nonstatic methods statically is BC with early days; you don't want to do that in your code because it will get you problems sooner or later. In older code you could not mark methods as static, so the language could not check if a static call is allowed. It simply permitted the call, not setting $this. also I noticed that using the keyword 'abstract' with a interface method declaration is all of a sudden (5.1RC5dev) causing a fatal error where before (5.0.2 - 5.0.4) no error what so ever. I thought I would never write anything like that - but: What sense does abstract make in an interface at all? You shouldn't have been writing abstract in an interface in the first place. :) If 'static', 'protected', 'private' are not allowed with interfaces (very unpragmatic imho) then why the fatal errors? why not an E_STRICT and just ignore those declaration... As I understand it, E_STRICT is for complaining about stuff like var that was ok with PHP4 but is discouraged in PHP5. But you are using PHP5 elements in a way that make no sense to the language, so it's simply an error. especially because not declaring a method static and leaving off the visibility leaves you with a method that is non-static and public - exactly what an interface 'requires'. You're explicitly requesting something that is not possible - an fatal error is the only thing that can be the result. Matthias -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] interface method visibility.
Jochem, the point with most of these issues is that there's no common understanding of what things like protected or static interface members mean; from an OO point of view, they make no sense, and I was only trying to explain why. Unless there is a common understanding what a certain language construct means, every way of implementing it is pretty arbitrary. So not implementing it at all is not self-imposed purism. should be - it worked in the 5.0RC1, I understood what I was doing and I was happy doing it. If these things were legal with 5.0.0 (were they really? I dunno...), one could argue wheter it's good practise to 'suddenly' make them E_FATAL in a minor release. However, even if they ever worked, at best it was undocumented (=random) behaviour. right which meant in one particular case I had to create an object especially to call the given method, very wasteful, pointless and the only good reason there seems to be is some academic crud which you have reiterated here. I don't get that should have worked otherwise, but if you want to let's discuss this one off-list. In older code you could not mark methods as static, so the language could not check if a static call is allowed. It simply permitted the call, not setting $this. everything I mention here is related only to my experience with php5 and up since Nov'03. If a method does not access $this, it can be used statically. So best would be to have the static modifier in place to make things clear, but that would require _you_ to add it to your pre-php5 'legacy' code. So, although academically not correct, the engine still permits it - simply because it did so in the past in an agreed-on manner. With E_STRICT it will addidionally tell you that as of PHP5 you have a keyword to get it right. also I noticed that using the keyword 'abstract' with a interface method declaration is all of a sudden (5.1RC5dev) causing a fatal error where before (5.0.2 - 5.0.4) no error what so ever. I thought I would never write anything like that - but: What sense does abstract make in an interface at all? the point is it doesn't hurt _you_ to let _me_ do it. if it makes sense to me but nobody else thats no reason not to allow it on grounds of principle when it is clear that it has worked without problem. Worked without problem is not necessarily a good argument for such things. However, I just found that abstract was also once legal in Java (http://java.sun.com/docs/books/tutorial/java/interpack/interfaceDef.htm l, note at the bottom). They removed it because it makes no sense (interfaces are abstract by nature). Now I know that this is by no means a better argument ;), but maybe a notice instead of fatal would be enough? As I understand it, E_STRICT is for complaining about stuff like var that was ok with PHP4 but is discouraged in PHP5. But you are using PHP5 elements in a way that make no sense to the language, so it's simply an error. and as I understand it E_STRICT is for pedantic checking - i.e. check if every t is crossed and every i dotted (so to speak) nothing perse to do with php4 (or will E_STRICT be dropped when support for php4 code is dropped from the engine?) I am not really familiar with engine internals, so maybe someone more enlighted than me could comment on this one and decide if E_NOTICE or E_STRICT is more appropriate. if its not possible then I what flippin' universe have I been coding in for the past 2 years??? the only thing making it 'not possible' is self-imposed purism. As you can see I changed my opinion as to abstract. But as to non-public and static members - you're asking for the engine to simply ignore modifiers you explicitly give and that make no sense. Programming languages don't work that way. -- mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Upgrade notes for 5.1
I think all of us who were upset making the transition to 4.4.0 would greatly appreciate if (in the future) there will not only be short there's a new release notices, but if these notices would directly point to a list like this one. E. g. MySQL does a pretty good job with their upgrade notes, so you know before the upgrade what problems to expect; they also explicitly list all the incompatible changes (and there are quite some with MySQL5). Maybe for some folks on this list the changes are well-known or obvious and compiling a list like this one seems to be unnecessary. But most of the sysops and developers out there don't have the time to keep up with all the changes and don't like the fear of shooting themselves in the foot with every new update/-grade/release. And they are especially afraid after what happened with 4.4.0, so this is a good step to reestablish some trust. Put simply, this is the professionalism expected in business/enterprise environments :). Matthias -Ursprüngliche Nachricht- Von: Steph Fox [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 15. November 2005 17:18 An: internals Betreff: [PHP-DEV] Upgrade notes for 5.1 Hi all, I've already canvassed Ilia and Stas - can anyone else think of anything I've missed/mis-explained here? Thanks guys/guyess, - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Re: results of the PHP6 wishlists
You mean something like SRM: http://www.vl-srm.net/ Though a bit more finished :-) Derick is probably too busy to finish SRM all alone, and my C skills are way too bad to help him :) So this gets off-topic here, but what about writing something like SRM in PHP itself to avoid the need of porting the part written in C :)? I asked Derick about this at the PHP Conference and IIRC, he said that Hive from the Zend Coding Contest tried to do so? The server itself would run using php-cli and listen on a socket. Let alone performance and multithreading/-processing (PCNTL?), one could try to do the RPC/RMI part by having proxy objects that perform (un)marshaling. The overload language features could be used to make these proxies feel like the remote ones. Passing objects to/from the server could work by (un)serializing the objects, though the current implementation lacks support for re-establishing object identity (hint, hint ;). Volunteers :)? Matthias -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Expose php: on or off
my suggestion would be, to simply shorten the string that gets exposed to php - and not show any version numbers (or maybe leave it to the user, say 0 for no exposure, 1 for only php and 2 for php with version number. At least it would be interesting to know about the spread of PHP(3?)/4/5... So maybe one solution would be to strip the minor numbers? Matthias -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Questions about static and serialization
Hi internals, I was experimenting with different approaches of maintaining state and serializing objects in PHP5. The problem is handling static class members and static variables inside methods. First, I noted that static variables inside methods are shared between instances. C++ seems to handle it the same way, but admittedly, I was a little bit surprised: Such variables are available as local variables in methods that are called using an instance, i. e. non-statically, whereas static class variables can only be accessed using a static reference to a class (self::, parent:: or Classname::). However, this explains why static variables inside functions do not show up when serializing object instances: Because the static variable is - just like a static class variable - not part of the object, but belongs to the class. So - has anybody ever considered serializing static variables as well? Obviously they have to be treated separately at a per-class level; let alone static variables in functions outside classes ;). Would it be possible to write a session serialize handler that somehow includes such static elements? I presume it should be possible to somewhere find the static elements. (Strictly spoken, an object instance's state expresses itself in non-static members of the instance, so the above static variables in functions stuff makes sense the way it is - if I want to maintain per-instance state, I shouldn't be using local static variables, but plain object members for that. However, when working with the Singleton pattern, you don't come around using static at some level...) Best regards, Matthias -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] Questions about static and serialization
Von: Wez Furlong [mailto:[EMAIL PROTECTED] As you mentioned, static properties and statically scoped variables don't belong to an object instance, so it doesn't make sense to serialize them. Ok, but on the other hand they are just variables - so the question was if there is any (possibly userland) way to capture them in the line with normal session handling, by using (un)serialize or whatever. As to persisting and restoring structures like the singleton pattern, I just noticed that the builtin serialization/persistence mechanisms don't care about object identity at all... :( Best regards, Matthias -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] return /* by reference */ new Foo() in PHP4
I agree that allowing = new and disallowing return new by reference is inconsistent. I'm so stubborn with this one because there might be good reasons if you're the mechanic lying under the car fixing the engine, but it does not make any sense if you just want to drive the car :) But PHP4 is stable tree. We don't like different versions with different behavior. I don't get that point :( If you make changes like the one from 4.3.12 to 4.4.0, why don't take back the notice with 4.4.1 if it makes no sense? Why's that different behavior? The point is that since 4.4.0 the return new triggers a notice although there's admittedly no good reason why it should do so. Conceptually/semantically, it does not make any sense, the required workaround is absurd, and, as I stated in my initial post, under some conditions (implementation details of the constructor) the notice does not even occur. I was just curious if there is any chance that this bug is corrected in 4.4.1 :-). In PHP5 = new is deprecated, so I don't see any reason to introduce return new by ref in PHP5. I was only talking about PHP4, because that is where people are struggling right now. I don't see where assigning by reference from new would make any sense at all with PHP5, apart from BC reasons. Of course, assigning new Objects() to parameters passed in by reference would make sense ;), but that is another story. Matthias -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] return /* by reference */ new Foo() in PHP4
So, in case of return new, wouldn't it make sense to remove the warning as the code is 'legal'? And please, don't start a new it's just a friendly notice flame war. It's just a notice, tune your error_reporting level accordingly. Sorry, but that is just a stupid killer argument. I thought I had written something like please, don't start a new *it's just a friendly notice* flame war. May I conclude that what you really want to say is: Yes, return /*byref*/ new Foo() _is_ bad code _unless_ inside Foo's constructor, $this is passed around and somebody somewhere stores yet another reference to it. Accept that you wrote broken code: return new Foo() is wrong, it needs to be return $tmp = new Foo(). Shaking his head, Matthias -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
AW: [PHP-DEV] return /* by reference */ new Foo() in PHP4
The return new... is just a subset of the problem, but not
the only one that is in wide use. For example, this is very common:
function getstuff($in)
{
if ($in=='ok')
return new MyObject();
else
return false; // this is the common line
}
The false obviously is not a variable that can be reference
and it's even not an object, the _technically_ more correct
answer would be return null;. But both ways of doing it are
are not the new ... problem AND throw a notice AND PHP
should be able to silently know what to do. Boxing is an
approach that covers all of the similar problems and I think
it could easily be realizedsince I suppose PHP is already
doing something similar to fix the memory leak problems.
Of course you're right. Seems my view was a little biased from looking
at my code only ;). The return new issue has the interesting side
effect that notices disappear depending on the constructor's
implementation details.
Many people will agree that your above code should work - when seen from
the conceptual point of view. It's a nasty side effect that because of
the way the PHP4 internals worked, you *had* to use the reference here.
Note that the following is yet another way of stating the same:
function getstuff($in) {
return ($in == 'ok' ? new MyObject() : null);
}
The problem is that even if internally temp assignments are used to make
it still work, how to separate the cases where notices are appropriate
(bad code) from those where they are not (because everything was
legal)?
[Weak point - others will throw in that it has never been legal but
only worked :)]
I don't understand the only on PHP4: Why should PHP4 be
more advanced than PHP5 regarding this issue? And more
important: Why should the two versions differ in behaviour in
such a basic point?
With PHP5 object handles, passing around references is really rare. If
you ported your code to make use of the new PHP5 features, you probably
won't see the whole reference passing-related problems at all (at least
not in places where you're only doing correct OO stuff).
Your example with PHP5:
#!/usr/bin/php5
?php
class Factory {
function build($what) {
if ($what == 'a')
return new Foo();
else
return null;
}
}
class Foo {
}
var_dump($x = Factory::build('a'));
var_dump($y = Factory::build('b'));
?
gives:
object(Foo)#1 (0) {
}
NULL
Just as one would expect.
Matthias
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] return /* by reference */ new Foo() in PHP4
Hi all,
first of all I do not want to set off yet another discussion about the
changes 4.4 brought. I do understand why the changes were necessary, and
in most of the cases, I would even endorse that pieces of code that
trigger the new only variable... waring are bad code.
Anyways, to me it seems that there are two very common patterns in OOP
code that have problems with the new behaviours. The first one is
returning-by-reference a reference obtained from another function. This
was bug #33558 and has been fixed in 4.4.1RC1.
The other one is as to return new ..., which is quite common (think of
factory methods!). Just as $x = new Foo() needs to assign by ref to
make sure $x and $this (inside the constructor) point to the very same
instance, something like
function createInstance() {
return new Foo();
}
$x = createInstance();
has to be done exectly like this with PHP4. Yes, I *do* understand that
it is evaluated as an expression and thus generates a warning.
The point is that this requires really unlogic and silly workarounds
like 'return $tmp = new Foo()'. That forces people to touch stable
codebases; I find it comprehensible that they feel this is like passing
the engine internal problems to the php coders.
Even more disturbing, this does *not* generate a notice if inside Foo's
constructor, $this is assigned by reference to something else. Say, in
Foo's constructor, you have something like
$someObservableObj-registerObserver($this), where registerObserver (of
course) takes a reference and adds the observer to an array or something
like that. Thus, it depends on implementation internals of Foo's
constructor if return new - an implementation detail of a the factory!
- produces the notice.
The bug describing this is #33679, marked as bogus with no further
explanation.
So, in case of return new, wouldn't it make sense to remove the
warning as the code is 'legal'? And please, don't start a new it's just
a friendly notice flame war.
Best regards,
Matthias
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
