[PHP-DEV] CVS Account Request: spriebsch
Working on phpruntests (refactored run-tests) with Zoe Slattery, and co-mentoring GSOC student Georg Gradwohl. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespaces and \t, \r, \n, \0 etc.
Hi Johannes, Johannes Schlüter schrieb: to me it does not seem to make sense to use tabs or linefeeds (or whatever other strange escaped characters) in namespace'd names. So I'd suggest generating a fatal error when somebody uses them. \n is no newline (yes \n is, \n not ...) - no need for such a strange limitation. My suggestion is to try to avoid people running into trouble with something like: namespace the\namespace\class; $classname = the\namespace\class; new $classname; I'd prefer the new statement to fail with an error like you can't have newlines in a classname instead of not finding $classname. Regards, Stefan -- e-novative - We make IT work for you. http://www.e-novative.de e-novative GmbH - Poignring 24 - 82515 Wolfratshausen - Germany tel/phone +49 (0)8171 267 087 0 - fax +49 (0)8171 267 087 5 Handelsregister/Trade Register: Amtsgericht München HRB 139407 Sitz/Registered Office: Wolfratshausen Geschäftsführer/Executive: Dipl. Inform. Stefan Priebsch GnuPG Key: 0x7DB67F7F -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Namespaces and \t, \r, \n, \0 etc.
Hi list, to me it does not seem to make sense to use tabs or linefeeds (or whatever other strange escaped characters) in namespace'd names. So I'd suggest generating a fatal error when somebody uses them. Regards, Stefan -- e-novative - We make IT work for you. http://www.e-novative.de e-novative GmbH - Poignring 24 - 82515 Wolfratshausen - Germany tel/phone +49 (0)8171 267 087 0 - fax +49 (0)8171 267 087 5 Handelsregister/Trade Register: Amtsgericht München HRB 139407 Sitz/Registered Office: Wolfratshausen Geschäftsführer/Executive: Dipl. Inform. Stefan Priebsch GnuPG Key: 0x7DB67F7F -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hannes Magnusson schrieb: I don't think anyone but him likes multiple namespaces per file. I do remember a PhD thesis sized mail from him explaining why multiple namespaces per file was needed though (can hardly believe anyone read the whole thing..). In some deployment processes, multiple PHP files are merged together into one file. Symfony, for example, does this, at least optionally. Regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de - GnuPG Key: 0x7DB67F7F -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace problem?
Hi Stas, Stanislav Malyshev schrieb: It may be true in some cases, but in general PHP allows to do tons of stuff that is not useful, or at least does not seem to be useful. But I don't think it's productive to spend time on disallowing such things - same time could be spent developing real features :) I think it may be more productive to disallow it now, instead of bogusifying bug reports and dealing with confused users later. My 2ct. Regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de - GnuPG Key: 0x7DB67F7F -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace problem?
Alexey Zakhlestin schrieb:
OK:
namespace foo;
{
}
Not OK:
{
use Foo:Bar as Something;
}
Then that is a showstopper that effectively does not allow to use braces
around a namespace, so I'd boldly suggest either fixing the curly braces
notation to allow use statements or disallow curly braces around
namespaces, because as it is, it doesn't really seem useful.
Regards,
Stefan
--
e-novative - We make IT work for you.
e-novative GmbH - HR: Amtsgericht München HRB 139407
Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch
http://www.e-novative.de - GnuPG Key: 0x7DB67F7F
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace problem?
Stanislav Malyshev schrieb: Hi! around a namespace, so I'd boldly suggest either fixing the curly braces notation to allow use statements or disallow curly braces around Use statements should be at the top, as the influence whole file scope. I know, but namespace must be the first statement in a script, so I can't put use _before_ the namespace. namespaces, because as it is, it doesn't really seem useful. What doesn't seem useful? What exactly you are trying to do? Trying to use curly braces around my namespace for readability. But I can't put a use statement _into_ these namespaces, neither can I put the use _before_ the namespace. That means: I cannot use namespaces with curly braces combined with a use statement. This makes the curly braces pretty pointless. Regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de - GnuPG Key: 0x7DB67F7F -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Namespace problem?
Hi list,
I was playing around with namespaces and stumbled across this:
#!/home/steve/php5.3-200807070430/sapi/cli/php
?php
namespace Foo;
use Foo::Bar as Something;
class Bar { }
?
works fine, whereas
#!/home/steve/php5.3-200807070430/sapi/cli/php
?php
namespace Foo;
{
use Foo::Bar as Something;
class Bar { }
}
?
yields: Parse error: syntax error, unexpected T_USE
in /home/steve/namespaces/code/with_braces.php on line 6
Regards,
Stefan
--
e-novative - We make IT work for you.
http://www.e-novative.de
e-novative GmbH - Poignring 24 - 82515 Wolfratshausen - Germany
tel/phone +49 (0)8171 267 087 0 - fax +49 (0)8171 267 087 5
Handelsregister/Trade Register: Amtsgericht München HRB 139407
Sitz/Registered Office: Wolfratshausen
Geschäftsführer/Executive: Dipl. Inform. Stefan Priebsch
GnuPG Key: 0x7DB67F7F
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How bad would it be to say/enforce that namespacing can only apply to classes and not normal functions?
Hey all, honestly, it is not my intention to raise a new flamewar, but aren't most of these ambiguity problems we talk about due to the fact that :: is used as the namespace separator? Regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de - GnuPG Key: 0x7DB67F7F -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting
Sam Barrow schrieb: If anyone has any objections to a scalar type hint please raise a valid point. Chris Stockton schrieb: This library would probably have ~300(String) + ~110(Int) ~40(Resource) ~30(Bool) ~10(Float) = 500 less function calls, and much cleaner code if there was type hinting. I may be short-sighted here, but does type adding hinting not just push the problem to the library user? In strictly typed languages the compiler enforces type consistency, in PHP any type inconsistency yields a runtime error, thus forcing the library user to explicitly type cast, wrap every library call into a try-catch statement or use a runtime error handler (which in turn can throw an exception, taking us back to try-catch)? From an overall perspective on the PHP code, I would rather have the type checks _once_ inside the functions/methods, instead of multiple times on every call. Regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de - GnuPG Key: 0x7DB67F7F -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] U
Richard Lynch schrieb: If a web service really doesn't care whether it is responding to GET or POST or even forged COOKIES to product its output, why would it not just use REQUEST? It's not as if it's any harder to forge GET vs. POST vs. COOKIE data, really. You can easily have sombeody inadvertedly send a malicious GET request just by embedding an image link into a page. Regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de - GnuPG Key: 0x7DB67F7F -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting
Sam Barrow schrieb:
Well these errors can be handled like any other, as long as they don't
issue a fatal.
That's exactly my point. You need to handle them. So in pidgin PHP that
could look something like
function foo(int $foo) {}
try
{
foo($bar);
}
catch (WhateverException $e)
{
since $bar cannot be converted to int, do_whatever
}
Is that really betten than writing
if (!is_int($bar)) do_whatever
foo($bar)
or
function foo($foo)
{
if (!is_int($foo)) do_whatever
}
My point is: aside from the academic purity of more strictness, what
is the real benefit in this scenario? Any defensive coder will always
write explicit type checks to prevent runtime errors.
Regards,
Stefan
--
e-novative - We make IT work for you.
e-novative GmbH - HR: Amtsgericht München HRB 139407
Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch
http://www.e-novative.de - GnuPG Key: 0x7DB67F7F
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting
Sam Barrow schrieb: Keep in mind that your do_whatever would actually be a trigger error with an error message including the name of the function and parameter number. I did not make the point of my code clear enough. do_whatever is not the code that triggers the error, but the code that handles the error. My point is that I think people will start checking parameters before they call a function to avoid a fatal error. This is more code and uglier, because you'll have to repeat it for every function call, instead of once in the function body. Even if they put an explicit typecast into a function call, like foo((int) $something) error handling code would have to be provided in case the cast was not possible. Regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de - GnuPG Key: 0x7DB67F7F -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting
Robert Cummings schrieb: The onus should be on consumers of my API to use it properly, not on me to jump through hoops to make sure they gave me the correct data at every step of the way. I stopped holding hands in grade 3 or so. Still you force any defensive coder to repeat explicit type checks and type casts all over whenever one of your API functions is called. Regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de - GnuPG Key: 0x7DB67F7F -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting
I'm a little afraid that introducing type hints will have us end up with
code like this (to stick with a previous example):
?php
function foo(int $a) {}
foo((int) '5');
?
So, just to make sure, add Java-ish typecasts everywhere. I'm not sure
if that solves the problem (error handling still required when the cast
is not possible), but maybe someone could comment on the performance
implications of adding explicit typecasts in every function call?
Regards,
Stefan
--
e-novative - We make IT work for you.
e-novative GmbH - HR: Amtsgericht München HRB 139407
Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch
http://www.e-novative.de - GnuPG Key: 0x7DB67F7F
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting
Pierre schrieb:
When a method or function uses the strict typing, it is on purpose. It
is documented (self documented and hopefully using normal docs). There
is no need of error handling, it is an usage error and should raise a
E_{whatever}, be happy, it will not be fatal as it is now in all these
OO strictness (with or without good reasons :).
Sorry, but I don't understand you. Why is there no need of error
handling? Clearly, it's a runtime error, which I either have to handle
or I have my program crash at some nonsense value. Wouldn't exactly
make me happy ;-)
Regards,
Stefan
--
e-novative - We make IT work for you.
e-novative GmbH - HR: Amtsgericht München HRB 139407
Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch
http://www.e-novative.de - GnuPG Key: 0x7DB67F7F
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting
Pierre schrieb: I don't see the point to make a application working when you pass to it the wrong data, it is a bad usage. That was the moto for the So how are you going to deal with the bad usage then? Isn't the problem that this bad usage is discovered at runtime, vs at compile time like in Java? If you don't deal with these errors, you effectively crash your application. Regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de - GnuPG Key: 0x7DB67F7F -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting
Pierre schrieb: That what happens now with the numerous fatal errors. That's not the case with an E_RECOVERABLE error. PHP has no compiler and all errors will be see at runtime, even fatals like missing classes, functions, methods, wrong interfaces or bad usages of set/getters. Sorry, not true. PHP does compile first and E_STRICT errors show up at compile time, which you can observe running a php -l lint check on a file E_STRICT errors and an appropriate error reporting level. But that's not really to the point, I know. Regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de - GnuPG Key: 0x7DB67F7F -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] spl_autoload vs __autoload
Andrew Mason schrieb: Hi guys, Can anyone shed some light on the advantages of the spl_autoload over the standard __autoload ? is there any ? You can only register one __autoload() function, whereas spl_autoload() allows for a hierarchy of handlers. This allows for libraries to register their own autoload handler, for example. Regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de - GnuPG Key: 0x7DB67F7F -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tainted Mode Decision
Hey David, David Zülke schrieb: bother us, at least they have been warned). But some implicit guessing magic that, once again, means people are gonna switch their brains off - please not. Frankly, I don't care about people that switch their brains off. If one doesn't care about security, or doesn't understand the related problems, they'll always be able to write crappy code, no matter what. I'd love to see a taint mode in PHP because it would help me make stuff I use and work on (at least) a little more secure - without a lot of effort. Regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de - GnuPG Key: 0x7DB67F7F -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about Namespace patch
Stanislav Malyshev schrieb: SELECT class FROM LibB WHERE class.name NOT LIKE 'Date%' AND class.version 3.14 OR class.approved='Manager' Maybe we should use PDO to support these? ;) For performance reasons, I would rather suggest using native database APIs instead of PDO. When do you think you can have the patch ready? ;-) Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Richard Lynch schrieb: And for those of us who never use autoload OR SPL, could you please not force SPL into core? From a regular PHP developer's perspective, SPL is part of the core (read: it is guaranteed that it is always there). The manual says so, and it has been said in most, if not all SPL-related presentations. So people have started using SPL, iterators, autoload, or the pre-defined exceptions. You might not use it personally, but I bet that sooner or later components and libraries you use will pick up on it, if they haven't already. AFAIK, PDO offers iterator-based access. Does PDO work without SPL? IMHO, you have to set a standard set of PHP features that everybody can rely on. By still allowing stuff to be disabled, you start adding more incertainty to the whole thing. If it can be disabled, somebody will disable it one day, get into trouble, file a bug report, and be told you need to always enable SPL. Isn't that a waste of time, energy and resources? Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: SPL as non-disablable extension (Was: Re: [PHP-DEV] Simple Namespace Proposal)
Derick Rethans schrieb: That's what we're doing... however, I don't mind the force SPL to be compiled into PHP bit. I think we should do that. Since the manual says This extension is available and compiled by default in PHP 5., so a lot of developers (me included) rely on SPL funtionality nowadays, so not compiling it into PHP in a certain installation is a recipe for diaster that should be avoided. Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Dmitry, Note that multiple files in namespace won't allow autoloading. Can you please explain why that is so? Now autoloading maps class name into file name, however if you have several classes in one file, only one of them may be autoloaded(). The same with namespaces. Did you confuse multiple files in namespace and multiple namespaces in a file in your original post? If yes, I'm with you, otherwise: Wasn't the original idea of your namespace implementation to simplify those long PEARified class names, kind of, by substituting a namespace for that name prefix? So I can write an autoloader that maps a namespace+class name to a file name. Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Stanislav Malyshev schrieb:
function super_common_function_every_namespace_in_my_project_uses(){
}
namespace A::B {
That's what I would like to avoid. Because if you need namespaces, then
you want to segment your naming space. If you in the same time pollute
the global space with non-namespaced function names, the whole namespace
business is kind of meaningless. Or you want your library not polluting
global space, or you don't.
Will there be an exception [as in: special case, not as in: new
Exception()] for an __autoload function?
Kind regards,
Stefan
--
e-novative - We make IT work for you.
e-novative GmbH - HR: Amtsgericht München HRB 139407
Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch
http://www.e-novative.de
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Stanislav Malyshev schrieb: Will there be an exception [as in: special case, not as in: new Exception()] for an __autoload function? __autoload is actually not that great an idea, as it appears now. spl_autoload_register works much better for complicated libraries. I know, and I use spl_autoload_register. But then I would blatantly suggest to remove __autoload() in PHP6 and force SPL to be compiled into PHP. Kind regards, Stefan Priebsch -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
Andrei Zmievski schrieb: As we see now, yes they will be in PHP 6. :-)) -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Rasmus Lerdorf schrieb: Stefan Priebsch wrote: Hi Rasmus, Or you may get it by conditionally including the file that defines it. Note that the opcodes are still cached, it just means that the executor has a bit more work to do on each request. Thanks for clarifying this. Has anybody actually created a benchmark that allows to compare conditional/unconditional include with and without opcode cache? I'm working on some PHP benchmarks like this, and would really appreciate any pointer to existing work in this area. Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Hi Dmitry,
I am merging together your various posts:
Note that multiple files in namespace won't allow autoloading.
Can you please explain why that is so?
function namespace_name($name) {
return __NAMESPACE__ . :: . $name;
}
Thanks for posting this - I am not sure wether this would do the trick
in my case, though, since would need to calculate a fully-qualified name
from *outside* the current namespace. BUT:
Putting multiple namespaces in one file is really unusual case.
It may be implemented, but I don't like to do it, because it may give
more mess then advantage.
Right. As I said before, I'd like to have this if it is not difficult to
do. Given the recent discussion with Rasmus about caching I think that y
original idea of glueing together files to improve performance will go
down the drain anyway. Bottom line: I'm with you.
Kind regards,
Stefan
--
e-novative - We make IT work for you.
e-novative GmbH - HR: Amtsgericht München HRB 139407
Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch
http://www.e-novative.de
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Stanislav Malyshev schrieb: Why wouldn't it play well with caching? My statement refered to a statment Rasmus had made somewhere else a while ago (conditional includes not playing well with caches) that got me confused. See Rasmus' clarifications in this thread. I don't think one binary approach makes sense for PHP. PHP application is usually composed of many files, some of them are library files not used at all, some are rarely used, etc. Also, this approach does not allow to change individual files without having all the system lose performance significantly. I wouldn't want to make it a new standard, but I'd say there could be a use for it. You could deploy a PHP application like a statically linked binary without external dependencies. That means, for example, no problems when wrong versions of external libraries are loaded because of an unexpected include path etc. Also, it is easier to ensure the application's integrity, because users cannot easily change or swap out a single file. I was asking myself wether loading one large file - possibly from a cache - might be a lot faster than loading n files. This of course depends on how expensive disk access is compared to how large your binary gets. That's why I was planning to benchmark it. Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Hi Dmitry, Allowing only one namespace per file is a clean concept which I like very much. I have a use case for putting multiple namespaces into one file, though. OOP-PHP applications are usually one class per file with conditional loading. This does not play well with caching. I am working on gluing together all files of a project into one large source file on deployment (a phing task will do this) so it can be opcode cached as one large application binary. I will then compare the performance of both apporaches, but I have a feeling that the single binary approach will be faster. As APC will be part of PHP6, I think this approach could improve general performance of PHP applications and easw deployment. Allowing only one namespace per file will obviously kill this approach. So if there is there a chance of allowing a namespace in braces, it would be great if you could make this possible. Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RIP PHP 4?
Vesselin Kenashkov schrieb: announcement for EOL on the php.net) the php4 users to upgrade directly to php6. This way the php6 adoption could be much faster than php5 one. So please give your opinions on this. I'd say this is not a good idea because PHP6 will/should/hopefully does introduce some backwards compatibility breaks (like removed php.ini options). So migrating from PHP4 to PHP5 first seems a better way to go, at least for troublesome code. Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Sebastian Bergmann schrieb: Why not expand namespaces during these step? The resulting file would then have either only one namespace or no namespace at all. A good idea, but (much) more work of course, since it requires parsing and rewriting every file. And I am not sure, if this really works out when it comes to dynamically creating class and function names. Is there a chance to add a PHP function that returns a fully qualified name for a given name (thus letting the engine do the expansion, which would ensure that correct rules are used)? Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Hi Ramus, Rasmus Lerdorf schrieb: Note that what you are saving by combining the files into one is just a single stat syscall per file. And that can be alleviated by setting apc.stat=0 in your config. That of course means you need to restart your server or flush your cache whenever you want to update the files. In apc.stat=0 mode you gain nothing by merging all the files. Hmmm, in earlier posts of yours (BTW, there was quite some confusion about those, I believe) you mentioned that/how cache-unfriendly conditional includes (i.e. autoload) were. Are we talking about new APC development here or did I misread your earlier comments on caching? Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
IMHO backporting a lot of features to PHP4 is a major reasons for the slow PHP5 adoption. Basically, it seems that everybody who is not using OOP feels that PHP4 is fine for them. I'd say committing to backporting stuff from PHP6 to PHP5 will yield a similar situation: very slow or no PHP6 adoption. BTW, can't the unicode switch be done at compile time? So one can compile PHP6 Unicode and PHP6 non-Unicode. Then if there is a clever way of running both engines in parallel, there should be no performance impact inside the non-unicode engine. Since there is both versions of the engine (that can maybe even selected by a certain statement in the main PHP file of the application), unicode and non-unicode users are happy. And there is only one version of PHP in the market, to conquer it all. There must be a reason to upgrade to a new PHP version (usually features, maybe performance increase etc.). But there also must be no reason not to upgrade. But you all know this, it has been said before. Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
Pierre schrieb: Namespace is one _very_ important reason. If we need a marketing I agree. But AFAIK namespaces were not supposed to be in PHP6, at least not in PHP 6.0. Is there an official position on wether namespaces will be in PHP 6.0? Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
Johannes Schlüter schrieb: http://www.php.net/~derick/meeting-notes.html#name-spaces repalce MArcus with Dmitry in the Conclusion and check the other thread. While we edit the document, can we also drop that *if* printed in italics? ;-) Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RIP PHP 4?
+1 -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Hi Dmitry, thanks for your clarifications. I like your concept very much, as a PHP user, however, I am a little concerned about some ambiguities your concept introduces. I feel this might be a source of error for many programmers, especially less experienced ones. In any case you won't use classes and namespaces with the same full names. IMHO this should be a fatal error, at least a warning (something like potential ambiguity between funtion foo() in namespace a and abstract method foo() in class a. Otherwise adding to an existing program could inadvertedly alter its behaviour. Right. You can have namespace UTF8 and function strlen() in it. This kind of overriding would make an interesting feature! However, if a programmer creates - by coincidence - a method with the name of an built-in PHP function, he alters the program's behaviour; from another point of view, this is something that should be forbidden, as I think it could be a source of hard-to-find errors. Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
David Coallier schrieb: I would probably be in favor of throwing a notice or a warning when someone modifies a built-in function (or even throw an exception) and that way as soon as you do such thing you would know right away that you modified something and you would know where the modification happened which would make things much easier for people developing and debugging applications. The problem is that this kind of overloading makes a nice feature as well. This is runied by throwing an exception, and cautious developers will at least get nervous when they see a notice. I could imagine that by adding something like overrides foo() or overloads foo() to a function/method declaration the developer could make clear that he willingly overrides a built-in function, and if this is missing, an exception is being thrown. This may be a little over the top, however. Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
Hi Dmitry, it would be great to have namespaces in PHP6, as these always longer-getting classnames are somewhat annoying. I don't want to start a discussion about the separator (I think there was one before), but: 6) Calls to qualified functions are resolved at run-time. Call to A::B::foo() first tries to call function foo() from namespace A::B, then it tries to find class A::B (__autoload() it if necessary) and call its static function foo() If I am not mislead this ambiguity is due to the fact that :: is the namespace separator? If, so I'd rather suggest changing the separator, because one could alter the program's behaviour by adding a function foo() to a namespace thus making PHP call this function instead of the method. Besides, a lot of less experiences programmers would not be sure when which function/method is actually called. All class and function names inside are automatically prefixed with namespace name. Inside namespace, local name always takes precedence over global name. It is possible to use the same namespace in several PHP files. The namespace declaration statement must be the very first statement in file. I take it that when I include or conditionally include, the included file has its own namespace, if one is declared in that file. What if I do not declare a namespace in an include file? Does this file inherit the current namespace or are the contents added to the global namespace? point of definition down to the end of file. It is recommended however to place imports at the beginning of the file. Import statements have effect only on file where they are written. Could this result in name conflicts when including files that have their own import statements? 4) calls to unqualified functions that are not defined in current namespace are resolved in run-time. The call to function foo() inside namespace (A::B) first tries to find and call function from current namespace A::B::foo() and if it doesn't exist PHP tries to call internal function foo(). Note that using foo() in namespace you can call only internal PHP functions, however using ::foo() you are able to call any function from global namespace. Does this mean that a programmer could override an internal PHP function, possibly accidentally? Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
Hi list, IMHO PHP6 might need more new features to attract developers to migrate their code / write new code for PHP6. Unicode support is great for those who need it, but is likely to cause work for those that just have to live with it. Nobody likes to so extra work, and it's hard to get managers to pay for refactoring and updating software without visible/measurable benefit. Especially if the new version it going to be slower, it's tough to push it through. Namespaces in PHP 6.0 might be a very interesting feature for many developers. Currently, it seems that unicode will be main thing, which might result in lots of developers not care about it and just wait for namespaces or another feature they need in 6.1 (or whenever). Regarding the BC break: maybe breaking BC can be cleverly used as a marketing statement. We have cleaned up PHP, to get rid of some sins of the past. If users do not upgrade because there is just one or two small issues that require them to put work in their existing code, then why keep BC? Those who are planning to upgrade to PHP6 will always have to put in some work into their code, or at least test it on PHP6. Those who stick with older versions do not really care wether the new version breaks BC just a little or really a lot - they are not going to touch their existing code anyway and stick with older PHP versions. Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feature(let) idea
Andi, Andi Gutmans schrieb: I got a feature idea from Apache. Apache will automatically translate mod_rewrite.so in LoadModule to mod_rewrite.dll on Windows. It'd be nice if we added the same to PHP so you wouldn't need to maintain two php.ini's between UNIX Windows machines. It's a pretty easy patch but I wanted to run it by people here before working on a patch. Andi I like this idea, but the directory layout is usually rather different between Windows and Unix, so there will probably still be differences in the php.ini regarding to include_path and extension_dir. Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feature(let) idea
Pierre, The idea is to use the same set of extension=foo directives for all platforms (nearly all). It is relatively obvious that extension_dir will differ. I like this idea and will ease our life, a litte :) I got that, and I like simplification. It would just not really make php.ini files portable between Windows and Unix. I could even think of some other feature(let)s that might help us move into that direction: - define a unified path separator for include_path (the system-dependend ones could still be accepted, thus keeping BC) - accept paths in php.ini with forward slashes on all systems (I think Apache also does -even requires- it that way) - for system-dependent settings like SMTP, have SMTP.Windows and SMTP.Unix settings that can override the general SMTP setting (this idea certainly needs some more thought) - also make zend_extension and zend_extension_ts guess wether dll or so is to be loaded Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP4] Logging native PHP function calls
Hi Markus, The thing is: I need to know specific information of the mysql operations: 1) host,user,pass of connects/pconnects (and which type of connect), count of connects this very request already had 2) sql statement on query, execution time, count of how many statements this very request already had You can configure xdebug to create a trace log showing the parameters passed to the called functions. This could be a basis for what you need. Additional to that I need information like: * server ip (multiple servers) * remote ip * http host (zillions of vhosts) * uri * user agent string A quick and maybe dirty idea that comes to my mind is to add a function call in your application that has these parameter (easy to gather from $_SERVER etc.) so they show up in the trace logs. Then it's a matter of processing a gazillion lines of trace log to get out the information you need, but at least it should be there. in the past, profiling things, but I don't see this possible in production environment running and getting out the the information I need. Trace logging in a production environment *absolutely* kills your performance, so if you have to dedicated test environment, hmmm. But would you actually create a patched PHP and deploy this in your production environment. Then I personally would rather opt for running an xdebug-based trace Sunday morning at 4 am. Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about bug #41262
Carsten Wiedmann schrieb:
So, why depends the return value in this one case on the local
filesystem and without any info in the documentation?
I always use something str_replace('\\', '/', $aFilename) before I work
with filenames, and normally have no cross-plattform issues with that. I
also do it after using realpath(), for example.
I know this is not really to the point, but it might just help you work
around the problem.
Kind regards
Stefan
--
e-novative - We make IT work for you.
e-novative GmbH - HR: Amtsgericht München HRB 139407
Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch
http://www.e-novative.de
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
phar is a good way of deploying PHP code, as PEAR proves. As a cautious developer however, I am reluctant to using optional features that might not be available on my client's installation. And for regular users of PHP-based software, installing a PECL extension is not an option. If I cannot be sure that phar works on my client's system, I cannot use it to deploy software. Uploading a phar file, then pointing your browser to it and running a PHP-based self-extracting installer similar to the Windows installers we know would make installing PHP software way more end-user-compatible. IMHO phar should be part of the PHP code, so that developers can rely on it as a means of PHP software deployment that certainly works on all systems, rather than another option. Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stanislav Malyshev schrieb: Unless your clients immediately upgrade to php 5.3 this is the case anyway for some time (probably measured in years). Sure. But since PHP4 support is discontinued by the end of this year, people will have to upgrade to 5.x (or 6) anyway. That would put phar support in the broad field maybe by mid-year 2008. for installer). However, running live app from inside phar is entirely different thing. I fully agree to that. I (currently) see phar as a means of deploying PHP code. But when people start running PHP apps from a phar, I am sure that soon some caching mechanism will appear that would just extract the files from the phar to the file system for quicker access - which again would make phar a great tool for deploying PHP code. And, if APC becomes more wide-spread in the future, I guess it does not really matter wether the code is read from filesystem of phar for the first time, since subsequently the pre-compiled code would be read from the cache anyway. Thus, I see no serious performance impact even if you run software from phar, at least when using a bytecode cache. That's exactly what I am saying - that in my opinion such format is not the best thing PHP software developers could (or should) rely on in many scenarios. Putting something in PHP source is a form of endorsement, and I think it should be carefully considered if it's ready for all scenarios before we do that. Then, for installation, what other format would you suggest? I think one advantage of phar is that it is backed by PEAR tools that one can expect every PHP developer to have on his system. It would be a good time now to provide some kind of de-facto-standard for deployment of PHP code, and phar is the best candidate I know for this. Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Lester Caine schrieb: And given the problem getting hosts to ADD PECL extensions, you expect that they will allow a third party application to install things on their locked down machines. I think the first problem is how does it integrate with hosting environments and will those hosts allow it to run? Hmmm ... isn't the essence of PHP webspace to be able to put PHP scripts/applications there to run them? phar could make the installation of PHP scripts and applications easier as compared to uploading an archive, unzipping it, possibly fixing access rights manually. Any yes, they will allow it to run because it's no different from allowing PHP scripts to run. As a matter of fact, .phar cannot do anything that .php cannot do, but it's just one file which makes it way easier to handler for end-users. Kind regards Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Stanislav Malyshev schrieb: All power to them, but why should they use phar as runtime format? Maybe we could agree on using phar as a means of deploying PHP code, as I pointed out earlier? Otherwise it seems, as Greg has pointed out, that PEAR as it is will become pretty useless with the release of PHP6. Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Gregory Beaver schrieb: Correction: the *installation* process for PEAR will have to be reverted to the way it worked in PHP 4. PEAR is unaffected by these changes. Which, from the end user's viewpoint, makes PEAR useless because they cannot install PEAR in the first place. That's what I meant. There are other changes that affect PEAR, which is why we are moving all packages to PHP 5+ currently. Could you please elaborate on that a little more? Kind regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
