Re: [PHP-DEV] cleaning up the functions - any volunteers?
Hi, While we nearing the release of 5.3 (hopefully?), there are many functions in the PHP code which still use old parameter parsing API (zend_get_parameters_ex) instead of the new one (zend_parse_parameters). I started taking care of ext/sybase_ct. - Timm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] LSB forward_static_call()
Etienne Kneuss schreef:
Hello,
On Mon, Jun 23, 2008 at 12:44 AM, Jochem Maas <[EMAIL PROTECTED]> wrote:
Etienne Kneuss schreef:
Hello,
On Sat, Jun 21, 2008 at 2:51 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
Hi!
So, I really would like to revert that foward_static_call stuff and
implement the parent:: patch instead, while it's still possible.
thoughts?
Didn't we discuss that already? Adding magic to parent:: is not a good
idea, it's very basic language construct and should work simple.
yes!
LSB is
an advanced feature, which probably would be used deep inside library
guts
and thus can use more elaborate syntax.
like static::foo() or if you're really feeling brave fix 'self' so that
it does LSB like it 'should' have done from the start.
changing self:: is not an option as it would break BC.
and the same is not true of parent::? besides which I doubt any same code
would actually break if the semantics of self:: changed, much less than
if parent:: changed at any rate.
It seems natural to think of LSB as a language feature, and so it
doesn't feel right to have it partly implemented as a keyword, and
then fix the problematic part as function.
We already see how call_user_func is painful to use (i.e. with methods
that use references), that same burden will be put on
forward_static_call.
and ironically call_user_func*() is quite often used in hacks that work
round the lack of LSB. forward_static_call() would relegate LSB to a second
rate feature, whilst 'comparable' languages treat it as a core OO feature.
I know that other languages are not the measure of things, but in the case
of
LSB I believe it should be a first class feature of an OO language.
On top of that, by making parent:: forward called class name, you remove
the possibility of doing non-forwarding call to the parent class.
Why would that be no longer possible ? If you want to make a
non-forwarding call to the parent class, you can use
TheParentClassName::foo();.
I certainly don't expect 'parent' to end up making a call to a method
defined in a sub-class.
Also don't we use 'parent' for much the same reason we use '__construct' ?
i.e. so we don't need to know which class is actually the parent defining
the requested method.
rewriting parent::meth() into parentClassName::meth() is like rewriting
class Foo {function __construct() {}} into class Foo {function Foo() {}}
no?
not really, for now, parent is simply an alias of the parent class.
but certainly not an alias for any child class.
please reconsider a either a new explicit keyword (e.g. 'static') or even
making 'self' LSB. I doubt much code would be affected if the semantics of
'self' changed.
another possibility is the keyword 'child', fits in nicely with 'parent'
and 'self' and describes nicely where in the class hierarchy a search
for the method/property will begin.
static::foo() is already implemented in HEAD and 5_3, it references
the class found with runtime information.
child is not a good keyword as LSB may not be to the direct child, it
can go through multiple childs in the inheritance branch, or it can
also reference the current class if no fallbacks occurred.
I understand that, the same is true for self:: and parent:: in that they
go though multiple ancestors (starting at the current class for self::) in
the anscetral inheritance branch, so I find the argument against 'child' weak,
but at the same time not important. I can live with anyname one cares to give
it.
Is this whole discussion pointless? given that you say 'static' has already been
implemented ... doesn't that negate the requirement for forward_static_call()
and
also the need to repurpose parent::?
As for it being slow - how slow it is? Does it really so slow that it
makes real-life application that otherwise would be fast to be slow? Or
it's just "couple more CPU cycles" slow? I suspect the latter - and thus
I don't think speed optimizations belong there.
It's about 85% slower than a direct call. Sure it's not that slow when
measuring absolutely, but we're talking about a feature that will be
typically used in frameworks and libraries, so the amount of calls may
be quite big.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 6 Bug Summary Report
PHP 6 Bug Database summary - http://bugs.php.net/ Num Status Summary (64 total -- which includes 26 feature requests) ===[*General Issues]== 26771 Suspended register_tick_funtions crash under threaded webservers ===[*Regular Expressions]= 44923 Open ereg works differently in PHP 6.0 unicode.semantics=on ===[*Unicode Issues]== 44868 Open Replaces UTF-8 symbol with incorrect symbol ===[Apache2 related]== 44083 Open virtual() not outputting results if zlib ouptut compression is on ===[Arrays related]=== 35277 Suspended incorrect recursion detection 41758 Assigned SORT_LOCALE_STRING broken for sort() in PHP6 43109 Open array_intersect() emits unexpected no of notices when 2d array is passed as arg ===[Class/Object related]= 41461 Assigned E_STRICT notice when overriding methods not defined by an Interface in hierarchy 44043 Open Enforcing a method without specifying the arguments ===[Compile Failure]== 42606 Open unicode/constants.c relies on ICU draft api 44502 Suspended Compiling ok with MySQL 5.0 45246 Open make error after ./configure --with-mysql ===[Filesystem function related]== 27792 Assigned Functions fail on large files (filesize,is_file,is_dir) 42110 Open fgetcsv doesn't handle ""\n correctly in multiline csv record 44034 Open FILE_IGNORE_NEW_LINES in FILE does not work as expected when lines end in \r\n ===[GD related]=== 34670 Assigned imageTTFText for Indian scripts (Devanagari) 34992 Assigned imageconvolution does not respect alpha ===[I18N and L10N related] 42471 Open locale_set_default returns true on invalid locales ===[MySQL related] 44076 Open mysql_result returns nothing with blob ===[ODBC related]= 39756 Assigned Crashes in fetching resultsets with LONG ASCII columns from MaxDB ===[OpenSSL related]== 25614 Suspended openssl_pkey_get_public() fails when given a private key ===[Other web server]= 26495 Suspended Using WebSite Pro 2.5 with ISAPI, cookies are not working ===[PDO related]== 35368 Suspended PDO query does not work properly with serialize 39171 Assigned pdo_mysql configure script sets empty default socket 42079 Open pdo_mysql always links to 3.x libraries (== PDO* in HEAD is out-dated) ===[Performance problem]== 42528 Open Out of "char"(8-bit) range value doesn't roll back, with uni-code ON. ===[Program Execution] 39992 Open proc_terminate() leaves children of child running 43784 Assigned escapeshellarg removes % from given string ===[Reproducible crash]=== 45107 Open setting ext_dir to "./" (and other ini settings) causes apache crash ===[Scripting Engine problem]= 33487 Assigned Memory allocated for objects created in object methods is not released 42194 Open $argc/$argv[] won't work when .php extension is assigned to php.exe ===[Session related]== 44860 Open session_encode fails for php_binary serialiser ===[Strings related]== 44075 Verified strtok misbehaving ===[Unicode Engine related]=== 45248 Open Shfift_JIS encoded characters in PHP script cause an error. ===[Unknown/Other Function]=== 45087 Open Illegal or truncated character in input ===[XML related]== 45022 Open Can't get php6 snap to ./configure on mac, fails at libxml2 ===[XSLT related]= 38218 Assigned php:functionString tries to access objects with their names in lowercase ===[Zlib Related]= 30153 Suspended FATAL erealloc() error when using gzinflate() Assigned bugs and feature requests (reminders sent): andrei 41758: SORT_LOCALE_STRING bro
Re: [PHP-DEV] OpenSSL and Phar
Hi Pierre, --with-openssl is used by ext/openssl and will continue to be used like it is now (I'm thinking of adding --with-openssl-dir for consistency but that's all). This has absolutely no bearing on my question. Perhaps I expressed myself badly. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: OpenSSL and Phar
Hi, Greg, OK, you've missed my point too, so let's start over from scratch. Please read carefully. I am working under Windows, a little-known operating system which as yet has no way of offering openssl support in ext/phar. My task is to make that work. If I set it up in the usual way, this configuration works as expected: --enable-phar --with-openssl It works by defining PHAR_HAVE_OPENSSL, which switches everything on. That triggers a dependency on the openssl libraries, but it's hidden because the openssl extension shares that dependency. If PHAR_HAVE_OPENSSL is not defined, phar relies on openssl extension calls. (I haven't yet investigated what happens to those when the user has no ext/openssl support at all.) Using something like PHAR_HAVE_OPENSSL_EXT to define that relationship can't work because there is no correlation between shared extensions that might be loaded by users and the original configure line for a given PHP build. We can only know whether or not the openssl extension was _built_ at the same time as phar. These configurations can only work if we give phar an **explicit** dependency on the openssl libs: --enable-phar=shared --with-openssl --enable-phar --with-openssl=shared --enable-phar=shared --with-openssl=shared The question is whether that dependency should be triggered by an explicit configuration option, instead of implicitly by the coincidence of having --with-openssl in the configure line. I personally feel that we should, and suggest we use --enable-phar-ssl[=shared] for this. Thanks, - Steph - Original Message - From: <[EMAIL PROTECTED]> To: "Steph Fox" <[EMAIL PROTECTED]>; "Marcus Boerger" <[EMAIL PROTECTED]> Cc: "internals" Sent: Sunday, June 22, 2008 9:50 PM Subject: Re: OpenSSL and Phar Hi, Steph, look more closely, the libraries are only used if openssl is built statically. Otherwise, phar directly calls openssl_verify or openssl_sign. Greg -Original Message- From: "Steph Fox" <[EMAIL PROTECTED]> Subj: OpenSSL and Phar Date: Sun Jun 22, 2008 4:32 pm Size: 701 bytes To: "Greg Beaver" <[EMAIL PROTECTED]>,"Marcus Boerger" <[EMAIL PROTECTED]> cc: "internals" Hi Greg, all, It seems we don't use the openssl extension API at all in ext/phar, just the actual OpenSSL headers and libs. That means Phar with OpenSSL support can be both built and run without ext/openssl being built at all, but requires third-party libs (under Windows at least - ssleay32.dll and libeay32.dll) in the same way that ext/openssl does. I'm wondering if we shouldn't have a separate configuration option for this - something like --enable-phar-ssl - rather than testing for --with-openssl in the config line. The chief advantage of this approach is that it doesn't matter whether phar-ssl is built as shared or not, since the dependency is outside PHP. Thoughts? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OpenSSL and Phar
Hi Martin, Would --with-openssl imply --enable-phar-ssl then? Sounds like a good idea to me. It certainly could... but what about distro builds? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OpenSSL and Phar
Hi Pierre, OK, I got back to the rest of your email now (caffeine always helps, eh). I'm not sure it makes sense to have the ssl optional features enabled but not ext/openssl. Or to say it better, I don't see the gain. What is the gain besides being able to say: "heh you can use the ssl features without having ext/openssl but you need the libs anyway"? You're missing that Windows users don't tend to roll their own PHP. They tend to pick and choose their extensions. At present, if someone were to load php_openssl.dll from PECL alongside built-in Phar in 5.3 they'd probably wonder why it wasn't working as advertised. If the dependency were made explicit in Phar, the only thing ext/openssl would be needed for is explicit openssl calls - which is far easier to understand. FWIW, I think having Phar built-in is actually a disadvantage when it comes to this kind of thing. ext/openssl isn't enabled by default and is only available as shared to the vast majority of Windows users. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OpenSSL and Phar
On Mon, Jun 23, 2008 at 1:28 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
> You're missing that Windows users don't tend to roll their own PHP. They
> tend to pick and choose their extensions.
I still miss your point here, I was only talking about bins releases
for windows.
> At present, if someone were to load php_openssl.dll from PECL
>From PECL? it is in our releases and will remain in our releases,
just like all extensions.
> alongside
> built-in Phar in 5.3 they'd probably wonder why it wasn't working as
> advertised. If the dependency were made explicit in Phar, the only thing
> ext/openssl would be needed for is explicit openssl calls - which is far
> easier to understand.
--enable-phar-ssl and do (not tested but it gives the idea):
if (PHP_PHAR_SSL == "yes") {
ADD_EXTENSION_DEP("phar", "openssl", true);
} else {
if (PHP_PHAR_SSL != "no") { // be sure to do not enable it when
--disable-phar-ssl is used
ADD_EXTENSION_DEP("phar", "openssl", true);
}
}
> FWIW, I think having Phar built-in is actually a disadvantage when it comes
> to this kind of thing. ext/openssl isn't enabled by default and is only
> available as shared to the vast majority of Windows users.
it is enabled by default and it is built shared as almost all
extensions. The rest is a matter of documenting it, like almost all
extensions, "please enable phar and openssl (if available) in your
php.ini".
Cheers,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] LSB forward_static_call()
On Mon, Jun 23, 2008 at 2:16 AM, Jochem Maas <[EMAIL PROTECTED]> wrote: > and the same is not true of parent::? besides which I doubt any same code > would actually break if the semantics of self:: changed, much less than > if parent:: changed at any rate. > The behavior of the parent:: as it relates to "existing" code is not changing. The only change of behavior is as it relates to the usage of static:: when parent:: is called on a method. That is why making this decision is now. Once 5.3 is released the behavior of parent:: will be locked in much the same way self:: was in 5.0 > > Is this whole discussion pointless? given that you say 'static' has already > been > implemented ... doesn't that negate the requirement for > forward_static_call() and > also the need to repurpose parent::? > static:: has been implemented for quite some time and the reason why forward_static_call was created and the reason why we want to change parent:: have been discussed at some length on this list. I'm mildly suprised you haven't seen it. Try reading: http://www.digitalsandwich.com/archives/65-Late-static-bindingsorta.htmlIt gives a pretty good description of what I disagreed with in the current patch. Then http://www.ds-o.com/archives/68-Late-Static-Binding-Changes-to-parent.htmlintroduces three patches to potentially resolve my issues. The three patches are really standalone (save a mistake I made when creating the forwarding patch that caused me to include forward_static_call()). forward_static_call patch has been implemented already. While this addresses my concerns I think it does so in a far less than optimal way. The first patch is what Etienne is talking about implementing which I am totally in favor for. The second patch is really is the same as the first, it just introduces a new keyword (which I do not think is needed.)
Re: [PHP-DEV] [RFC] Starting 5.3
Lukas Kahwe Smith wrote: if nobody with C hacking skills is feeling sufficient pain over this, the assumption is that the pool of users is too small or the pain is too small. Hi, sorry for such late reply, but I just joined this group. I'm very interested in Firebird's future in PHP and I have C skills. However, to answer your assumption: the pain is too small. We have a working 'interbase' extenstion that does all the job, and does it well. I see that it might get moved to PECL or it might not, however, it is going to be working for a long time. Current PHP+Firebird users just don't feel that they need PDO. It could be used for new application development, but you'll hardly find a novice PHP user that is also willing to start hacking into PHP source code in parallel. Existing users are simply happy with pure ibase_ functions and ADOdb. Now, I don't know about that 'lot of shiny new software' being written on PDO, and don't really see that Firebird users will care much. Most of that software is meant to run for ISPs, hosting, etc. services and Firebird is still not on par with MySQL in that (web hosting) environment. I use Firebird for everything, except dynamic online websites where MySQL is simply the best choice. I hope that PDO stuff is not meant to completely replace mysql_, ibase_, etc. kind of functions in some distant future. -- Milan Babuskov http://www.flamerobin.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On 23.06.2008, at 14:54, Milan Babuskov wrote: Lukas Kahwe Smith wrote: if nobody with C hacking skills is feeling sufficient pain over this, the assumption is that the pool of users is too small or the pain is too small. sorry for such late reply, but I just joined this group. I'm very interested in Firebird's future in PHP and I have C skills. However, to answer your assumption: the pain is too small. We have a working 'interbase' extenstion that does all the job, and does it well. I see that it might get moved to PECL or it might not, however, it is going to be working for a long time. Current PHP +Firebird users just don't feel that they need PDO. It could be used for new application development, but you'll hardly find a novice PHP user that is also willing to start hacking into PHP source code in parallel. Existing users are simply happy with pure ibase_ functions and ADOdb. Now, I don't know about that 'lot of shiny new software' being written on PDO, and don't really see that Firebird users will care much. Most of that software is meant to run for ISPs, hosting, etc. services and Firebird is still not on par with MySQL in that (web hosting) environment. I use Firebird for everything, except dynamic online websites where MySQL is simply the best choice. Its not only shiny software, its pretty much all of the standard libs people are developing. So even if you use PHP+Firebird for other stuff you will probably be unhappy that you cannot really use any of the database enabled libs in ezc and ZF. The same will probably be true for PEAR2 etc. I hope that PDO stuff is not meant to completely replace mysql_, ibase_, etc. kind of functions in some distant future. It does not seem like its going to happen in the immediate future (aka PHP 6.0) unless we will that we have nobody to contact in case of bugs and more importantly that ensures that we are aware of security issues. So for now it would be sufficient someone steps up and takes over the maintainer role for the ibase extension. This would entail doing the standard maintenance stuff like updating to the new parameter parsing API. It would also entail proactively addressing security issues. Obviously for PHP 6.0 we do need someone to update things for full unicode support eventually as well. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On Mon, Jun 23, 2008 at 2:54 PM, Milan Babuskov <[EMAIL PROTECTED]> wrote: > Lukas Kahwe Smith wrote: >> >> if nobody with C hacking skills is feeling sufficient pain over this, the >> assumption is that the pool of users is too small or the pain is too small. > > Hi, > > sorry for such late reply, but I just joined this group. I'm very interested > in Firebird's future in PHP and I have C skills. However, to answer your > assumption: the pain is too small. How should we understand that? Too small to actually take care of it? With the risk to repeat myself, the goal is to have a long term working extension with maintainer(s). An extension without maintainers, especially DB related extensions (or service specific extension) will slowly die within a couple of years if nothing is done. Let forget PDO for now, that's not the point (even if a working firebird support for PDO would rock). Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OpenSSL and Phar
Hey Pierre,
--enable-phar-ssl and do (not tested but it gives the idea):
if (PHP_PHAR_SSL == "yes") {
ADD_EXTENSION_DEP("phar", "openssl", true);
} else {
Erm... no, you've definitely missed the point. ADD_EXTENSION_DEP() only
works in one of the four possible scenarios, and that one is when both phar
and openssl are built as static. It will break the build for all other
combinations.
There are two ways to get phar to build alongside openssl in the other three
scenarios: You can add an explicit dependency on the underlying OpenSSL
libs, or you can ignore the relationship completely. If you do the former,
the related functionality in phar does not actually require ext/openssl to
be loaded. If you do the latter, it does.
FWIW, I think having Phar built-in is actually a disadvantage when it
comes
to this kind of thing. ext/openssl isn't enabled by default and is only
available as shared to the vast majority of Windows users.
it is enabled by default
'enabled by default' usually implies 'built-in'.
and it is built shared as almost all
extensions. The rest is a matter of documenting it, like almost all
extensions, "please enable phar and openssl (if available) in your
php.ini".
We can sign and verify OpenSSL signatures without ext/openssl if we have the
library dependency. In other words, this (with the module checks in util.c
commented out) works fine:
$p = new Phar('sigtest.phar');
$p['a.txt'] = 'whatever';
$pkey = file_get_contents(dirname(__FILE__) . '/files/private.pem');
$p->setSignatureAlgorithm(Phar::OPENSSL, $pkey);
var_dump($p->getSignature());
output:
array(2) {
["hash"]=>
string(256)
"A408120F3D5EAD7FAFB891FD6D3DB8A35A68741A550009F685517BA05086C35919730B81DAC06408082E0363F7DC25B7F51AFA9D3B598ECBE42D961296A201EE4ECD343BB707CD3C7F8E788C812477343644516591470F885A712326058B8A46DA769DADA8CDBC30C4DF47DD0A13C0A9AEF9FE4E62300EBD79C53215B415999E"
["hash_type"]=>
string(7) "OpenSSL"
}
and so does this:
$p = new Phar(dirname(__FILE__) . '/files/openssl.phar');
$sig = $p->getSignature();
var_dump($sig);
output:
array(2) {
["hash"]=>
string(256)
"1614A127C7DEB5405D175FFB2D20031E5E78A1FB993D8A854862940F28D0BB3207E1722F424DC731131BFC082D4B8A2F7B053E1B4405400F4D6D6AA0BBF2E45B3028CC6C01C9C361DC1A4B65D3932B075CB33948AF0B147076EBA3B13010B27DC64D7DAD340B2E399CA7848BB59434C1BC55B5B062F134A6943202F8FF63BD7B"
["hash_type"]=>
string(7) "OpenSSL"
}
Currently my config.w32 for PECL looks like this:
ARG_ENABLE("phar", "enable phar support", "no");
ARG_ENABLE("phar-ssl", "enable phar with OpenSSL support", "no");
if (PHP_PHAR_SSL != "no") {
PHP_PHAR = PHP_PHAR_SSL;
PHP_PHAR_SHARED = PHP_PHAR_SSL_SHARED;
}
if (PHP_PHAR != "no") {
EXTENSION("phar", "dirstream.c func_interceptors.c phar.c phar_object.c
phar_path_check.c stream.c tar.c util.c zip.c");
if (PHP_PHAR_SHARED) {
ADD_FLAG("CFLAGS_PHAR", "/D COMPILE_DL_PHAR ");
}
if (PHP_PHAR_SSL != "no" || PHP_OPENSSL != "no") {
ADD_FLAG("LIBS_PHAR", "libeay32.lib ssleay32.lib");
AC_DEFINE('PHAR_HAVE_OPENSSL', 1);
}
ADD_EXTENSION_DEP('phar', 'spl', true);
}
The config.w32 for core needs more thought because phar is enabled
statically by default there. It might be that Greg's is the only solution in
that set-up (i.e. phar only has internal openssl support if ext/openssl is
also statically linked, and the only way to get openssl support in phar
otherwise is to load php_openssl.dll.)
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OpenSSL and Phar
Hi, On Mon, Jun 23, 2008 at 4:38 PM, Steph Fox <[EMAIL PROTECTED]> wrote: > We can sign and verify OpenSSL signatures without ext/openssl if we have the > library dependency. In other words, this (with the module checks in util.c > commented out) works fine: I finally took a look at why phar is not built shared as all other extension. It seems to force it only to be able to be run with no dep but still uses them if they are lately added (given that phar is now built statically, that makes little sense). But in fact, it does have deps against ext/zlib, ext/bz2 and now ext/openssl. You may want to use the library directly but as it will be easy and problemless for bz2 and zlib, it is going to be a pain for openssl. My main question now is why don't you actually reflect the (optional) dependencies? bz2 and zlib compression available will not be available if bz2 or zlib is not present, same for openssl. As testing has_xxx at runtime looks shiny and powerful, I don't think it is worth the pain. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Pierre Joye wrote: if nobody with C hacking skills is feeling sufficient pain over this, the assumption is that the pool of users is too small or the pain is too small. sorry for such late reply, but I just joined this group. I'm very interested in Firebird's future in PHP and I have C skills. However, to answer your assumption: the pain is too small. How should we understand that? Too small to actually take care of it? Perhaps I didn't quote enough of Lukas' posting. I was addressing PDO support for Firebird. If would be great pain not to have php_interbase, and if nobody is out there willing to do it, I'd like to step up. What are the requirements for someone to become an extension maintainer? With the risk to repeat myself, the goal is to have a long term working extension with maintainer(s). An extension without maintainers, especially DB related extensions (or service specific extension) will slowly die within a couple of years if nothing is done. Let forget PDO for now, that's not the point (even if a working firebird support for PDO would rock). Ok. What do I need to become a maintainer of php_interbase? I got C/C++ skills and an very familiar with Firebird (I'm part of the team that makes FlameRobin, which is an open source cross-platform C++ admin. tool for Firebird). I have access to Linux and Windows XP. Although I prefer Linux for development, I could compile something with MSVC Express Edition if/when it's really needed. Now, when we're at it, my experience with MSVC and Windows command line tools is almost none. I tried to build PHP 5.3 with it, but the guide on PHP website has some errors (some stuff just isn't where it says it is, and it seems some steps are skipped. Also, the 'configure' script used for MSVC fails to detect that those things are missing). Where should I report such problems? (Is this list appropriate for such questions)? Thanks, -- Milan Babuskov http://www.flamerobin.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OpenSSL and Phar
Pierre, I finally took a look at why phar is not built shared as all other extension. It seems to force it only to be able to be run with no dep but still uses them if they are lately added (given that phar is now built statically, that makes little sense). But in fact, it does have deps against ext/zlib, ext/bz2 and now ext/openssl. It has *optional* dependencies on all three, yes. Not hard dependencies. Phar works fine without them, it's just you can't have bz2 compression without bz2 etc. You may want to use the library directly but as it will be easy and problemless for bz2 and zlib, it is going to be a pain for openssl. Ah, now you understand the problem. The thing is that direct use equates to "phar needs libeay32.dll". (Not the other one in my shared-build tests, not sure why.) Now, as you pointed out earlier, libeay32.dll is bundled with the Windows distro, so in itself that isn't a problem - people won't struggle to find it. But if phar's built-in, that gives PHP a hard third-party dependency by default, which is obviously not acceptable. The way Greg's written it allows for the openssl extension to be a soft dependency. If it's not loaded, you just miss that part of Phar's functionality, and if you want the functionality you need to load php_openssl.dll. However, if you happen to have built openssl statically into PHP, you might as well use the underlying library directly, and currently under Linux that's exactly what happens. That's fine, but it's also a little odd, since it means the only time you don't use ext/openssl is when it's there Now let's talk about use cases. The way OpenSSL is used in phar is very minor - just OpenSSL signature verification and creation from existing private keys. If you want to do any more than that you'd need to load php_openssl.dll anyway. But most people probably won't want to do any more than that. Also, if you want to run ext/openssl under Windows you need to set it up a working environment for it, and this isn't necessary if you just want to support OpenSSL signatures in ext/phar. So I think we need to offer the *option* of having a hard dependency on libeay32.dll, with the default being no dependency. In the config.w32 I posted earlier, the assumption is that anyone building --with-openssl won't find that hard dependency a problem, but I'm not sure this is a good idea, especially given that there's a perfectly good fallback solution. The other thing we could do of course is throw out all that pure library code and only offer OpenSSL signature support when ext/openssl is loaded. That has the benefit of clarity at least. My main question now is why don't you actually reflect the (optional) dependencies? bz2 and zlib compression available will not be available if bz2 or zlib is not present, same for openssl. What do you mean? In config.w32? No need. In phpinfo()? We already do, just haven't added the openssl part yet because the configuration's up in the air. As testing has_xxx at runtime looks shiny and powerful, I don't think it is worth the pain. Sorry, I failed to parse that sentence... :\ Cheers, - Steph Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] LSB forward_static_call()
Hi! It seems natural to think of LSB as a language feature, and so it doesn't feel right to have it partly implemented as a keyword, and then fix the problematic part as function. There's nothing wrong with functions - call_user_* are functions too, and func_get_args(), etc. We already see how call_user_func is painful to use (i.e. with methods that use references), that same burden will be put on forward_static_call. If we have problem with using call_user_* with references, that should be fixed (do we have description of what exactly is missing - like bug report or RFC or something?) But it won't be fixed by changing parent::, so how it's relevant here? Why would that be no longer possible ? If you want to make a non-forwarding call to the parent class, you can use TheParentClassName::foo();. Why having parent:: at all then? You could always use the class name, right? But for some reason we do have parent:: - and that reason is that using explicit class name is not a good style in this context, it both obscures the intent and makes unnecessary dependencies in the code. Now imagine on top of that we have name:: and parent:: work differently, so you don't have choice but using name:: for certain things. It's about 85% slower than a direct call. Sure it's not that slow when measuring absolutely, but we're talking about a feature that will be typically used in frameworks and libraries, so the amount of calls may be quite big. I do not think extra CPU instruction or two is really the factor here. We are talking about high-level language, not assembly language. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OpenSSL and Phar
On Mon, Jun 23, 2008 at 5:44 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
>> My main question now is why don't you actually reflect the (optional)
>> dependencies? bz2 and zlib compression available will not be available
>> if bz2 or zlib is not present, same for openssl.
>
> What do you mean? In config.w32? No need. In phpinfo()? We already do, just
> haven't added the openssl part yet because the configuration's up in the
> air.
Yes, in config.w32 and config.m4. Either using ADD_EXTENSION_DEP or
ADD_LIBS if you use the library directly. phar works smoothly without
them, fine, that makes them optional deps. But they are still
dependencies.
>> As testing has_xxx at runtime looks shiny and powerful, I don't think
>> it is worth the pain.
>
> Sorry, I failed to parse that sentence... :\
You know how a given feature is tested in phar?
PHAR_G(has_zlib) = zend_hash_exists(&module_registry, "zlib", sizeof("zlib"));
then:
if (!PHAR_G(has_zlib)) ...
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OpenSSL and Phar
if (!PHAR_G(has_zlib)) ... Pierre, you'd still need to test for them at runtime whether they were listed as a soft dependency or not! - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OpenSSL and Phar
On Mon, Jun 23, 2008 at 7:21 PM, Steph Fox <[EMAIL PROTECTED]> wrote: > >> if (!PHAR_G(has_zlib)) ... > > Pierre, you'd still need to test for them at runtime whether they were > listed as a soft dependency or not! No, not if they are not soft dependencies, this is what is done in 99% of the php exts (from an user pov, it will be the same yes). -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] LSB forward_static_call()
Hi!
why would anyone need that?
To use function that does use static without dependence on in which
context if was called (or, explaining it other way, when your chain of
inheritance serves multiple purposes):
class ActiveRecord {
static function getRow($condition) {
$table = new Table(get_called_class());
return $table->find($condition);
}
}
class Users extends ActiveRecord {
}
class DepartmentUsers extends Users {
static function find($user) {
if(self::user_in_department($user)) {
return parent::getRow("user=$user");
}
return false;
}
}
$user = DepartmentUsers::find("bob");
Now in this case if your way is implemented, ActiveRecord would try to
find table for DepartmentUsers, which probably does not exist. You would
have to name Users by name there to do what this code wants to do, which
leads us back to "why we have parent:: at all" argument.
"parent" is related to inheritance and it is logical, that it retains
call-chain.
It is "logical" if you look at it with the narrow point of view of what
you need for your particular application. However, there are other use
cases. Automatic forwarding may become very awkward if you have multiple
levels of inheritance not all of them used for the same thing.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
Hi! Now, when we're at it, my experience with MSVC and Windows command line tools is almost none. I tried to build PHP 5.3 with it, but the guide on PHP website has some errors (some stuff just isn't where it says it is, and it seems some steps are skipped. Also, the 'configure' script used for MSVC fails to detect that those things are missing). Where should I report such problems? (Is this list appropriate for such questions)? In general, building PHP on windows should be as easy as on Unix, not requiring any special knowledge of the tools, meaning: 1. Get environment with MSVC set up 2. Get external libraries (recommended to put them in same upper-level dir as php checkout) 3. Run buildconf 4. Run cscript configure.js --options 5. Run nmake 6. Enjoy your PHP build If something doesn't work along the way, most probably some library is missing or wrong version, etc. There's now dedicated windows list [EMAIL PROTECTED], which might be a better place for discussing it, but in any case description of the error message would help. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Starting 5.3
On Mon, Jun 23, 2008 at 5:36 PM, Milan Babuskov <[EMAIL PROTECTED]> wrote: > Pierre Joye wrote: if nobody with C hacking skills is feeling sufficient pain over this, the assumption is that the pool of users is too small or the pain is too small. >>> >>> sorry for such late reply, but I just joined this group. I'm very >>> interested >>> in Firebird's future in PHP and I have C skills. However, to answer your >>> assumption: the pain is too small. >> >> How should we understand that? Too small to actually take care of it? > > Perhaps I didn't quote enough of Lukas' posting. I was addressing PDO > support for Firebird. If would be great pain not to have php_interbase, and > if nobody is out there willing to do it, I'd like to step up. > > What are the requirements for someone to become an extension maintainer? > >> With the risk to repeat myself, the goal is to have a long term >> working extension with maintainer(s). An extension without >> maintainers, especially DB related extensions (or service specific >> extension) will slowly die within a couple of years if nothing is >> done. >> >> Let forget PDO for now, that's not the point (even if a working >> firebird support for PDO would rock). > > Ok. > > What do I need to become a maintainer of php_interbase? Motivation and a some free time (happiness too :) > Now, when we're at it, my experience with MSVC and Windows command line > tools is almost none. I tried to build PHP 5.3 with it, but the guide on PHP > website has some errors (some stuff just isn't where it says it is, and it > seems some steps are skipped. Also, the 'configure' script used for MSVC > fails to detect that those things are missing). Where should I report such > problems? (Is this list appropriate for such questions)? You don't have to be a windows pro as long as you can test it on windows. The main problem now is that we had no maintainer to take care of the bugs (there is bugs), to valid a release (sources or binary), etc. Are you (still) interested? :) -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP
Hi! Hmm, seems like a good idea. If nobody objects in the next few days, I'll rewrite my patch to use objects instead of resources. What class name do you suggest? While we are at it maybe even having special standard handler (__invoke?) that could be also used by objects created by reflection and maybe later of some other purposes. I.e. if we do $foo($bar, $baz) and $foo is an object and it defines __invoke, then we call it (in which case if $foo is Closure it does its thing) otherwise we get an error "object $foo is not callable". Of course, this goes also for is_callable, etc. What do you think? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] LSB forward_static_call()
Hello,
On Mon, Jun 23, 2008 at 6:57 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Hi!
>
>> It seems natural to think of LSB as a language feature, and so it
>> doesn't feel right to have it partly implemented as a keyword, and
>> then fix the problematic part as function.
>
> There's nothing wrong with functions - call_user_* are functions too, and
> func_get_args(), etc.
Sure, there are nothing wrong with functions, my point is that LSB is
implemented partly with a keyword and partly with a function. Which is
IMO a bad idea. Why use static:: in the first place ? We could have
used call_called_class_method("method"), oh right: it's ugly as hell.
>
>> We already see how call_user_func is painful to use (i.e. with methods
>> that use references), that same burden will be put on
>> forward_static_call.
>
> If we have problem with using call_user_* with references, that should be
> fixed (do we have description of what exactly is missing - like bug report
> or RFC or something?) But it won't be fixed by changing parent::, so how
> it's relevant here?
sure, the "fix" is
$args = array($byval, &$byref);
forward_static_call_array(array('parent', 'foo'), $args);
instead of:
parent::foo($byval, $byref);
I guess its quite obvious to see which way will be prefered.
>
>> Why would that be no longer possible ? If you want to make a
>> non-forwarding call to the parent class, you can use
>> TheParentClassName::foo();.
>
> Why having parent:: at all then? You could always use the class name, right?
> But for some reason we do have parent:: - and that reason is that using
> explicit class name is not a good style in this context, it both obscures
> the intent and makes unnecessary dependencies in the code. Now imagine on
> top of that we have name:: and parent:: work differently, so you don't have
> choice but using name:: for certain things.
yes parent:: is convenient, that's why it's there.
Here is the possible scenarios:
1) you don't use any LSB in your static method => you use parent::
without caring
2) you use LSB in the method of the parent class, and you need to
overwrite that static method, but still call it from the child method,
2.1) you use parent:: as usual
2.2) you need to lie to the parent class by telling that the method
was directly called.
Now, 2.1 seems to be oviously more frequent than 2.2. I can't even
think of a decent reason to need 2.2 (do you have any example of
"certain things" ?). Which means that when the difference between
parent:: and ParentClassName:: is relevant, parent:: will be used more
often.
Additionally, forward_static_call allows to do calls to unrelated
methods, (without passing the caller info) which increases the WTF
factor. parent::foo on the other hand is well defined.
>
>> It's about 85% slower than a direct call. Sure it's not that slow when
>> measuring absolutely, but we're talking about a feature that will be
>> typically used in frameworks and libraries, so the amount of calls may
>> be quite big.
>
> I do not think extra CPU instruction or two is really the factor here. We
> are talking about high-level language, not assembly language.
> --
> Stanislav Malyshev, Zend Software Architect
> [EMAIL PROTECTED] http://www.zend.com/
> (408)253-8829 MSN: [EMAIL PROTECTED]
>
>
--
Etienne Kneuss
http://www.colder.ch
Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] LSB forward_static_call()
Hi Stas, Am Montag, den 23.06.2008, 09:57 -0700 schrieb Stanislav Malyshev: [...] > Why having parent:: at all then? You could always use the class name, > right? But for some reason we do have parent:: - and that reason is > that using explicit class name is not a good style in this context, it > both obscures the intent and makes unnecessary dependencies in the > code. Now imagine on top of that we have name:: and parent:: work > differently, so you don't have choice but using name:: for certain > things. An wide-spreaded usage example for non-forwarding calls is? I would estimate, that in 70% percent, it doesn't matter, what kind of call strategy is choosen, 29% percent will be forwarding calls and only 1% are non-forwarding. cu, Lars signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] [PATCH] [RFC] Closures and lambda functions in PHP
Hi Stas, Am Montag, den 23.06.2008, 10:56 -0700 schrieb Stanislav Malyshev: > What do you think? I really love that idea. Real Functors¹ in PHP, great! 1) http://en.wikipedia.org/wiki/Function_object cu, Lars signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] OpenSSL and Phar
Steph Fox wrote: Hi Pierre, OK, I got back to the rest of your email now (caffeine always helps, eh). I'm not sure it makes sense to have the ssl optional features enabled but not ext/openssl. Or to say it better, I don't see the gain. What is the gain besides being able to say: "heh you can use the ssl features without having ext/openssl but you need the libs anyway"? You're missing that Windows users don't tend to roll their own PHP. They tend to pick and choose their extensions. At present, if someone were to load php_openssl.dll from PECL alongside built-in Phar in 5.3 they'd probably wonder why it wasn't working as advertised. If the dependency were made explicit in Phar, the only thing ext/openssl would be needed for is explicit openssl calls - which is far easier to understand. FWIW, I think having Phar built-in is actually a disadvantage when it comes to this kind of thing. ext/openssl isn't enabled by default and is only available as shared to the vast majority of Windows users. Hi, I must be going crazy. Is there an actual problem that needs solving? You're saying that a user who improperly installs php_openssl.dll (i.e. does not follow instructions and set up ssleay.dll and libeay.dll) should magically be able to use phar with openssl? Why? ext/phar uses openssl, and thus works in all of these situations: 1) ext/phar built statically and ext/openssl built statically (in this case, it uses openssl lib directly) 2) ext/phar built statically and ext/openssl built dynamically (in this case, it checks for openssl dynamically at runtime, and directly calls openssl_sign or openssl_verify) 3) ext/phar built dynamically and ext/openssl built dynamically (in this case, it checks for openssl dynamically at runtime, and directly calls openssl_sign or openssl_verify) 4) ext/phar built dynamically and ext/openssl built statically (in this case, it checks for openssl dynamically at runtime, and directly calls openssl_sign or openssl_verify) #1 is the fastest alternative, but the difference is insignificant for any application of significant size, as the extra code in #2, 3, and 4 is only called once. On windows, the user would have (by default) phar static and openssl dynamic. To enable openssl signing, you simply need to enable php_openssl.dll, which means setting up a few dlls as described on the installation page for openssl. Once done, phar then works great with openssl signatures. Where is the problem? Any user who has control over their windows build and wishes to compile in openssl statically for maximum performance may do so, but I would challenge any user trying to eke out such a small performance gain would be better served by using unix, where PHP is just plain faster no matter what. Pierre: the difference between phar and other extensions is that phar has the ability to handle all 4 of the above situations for bz2, zlib and openssl, whereas no other extensions possess this kind of true optional dependency handling. So, I fail to see how the use of runtime extension detection is anything other than a really great idea that solves the problem of optional dependency handling regardless of static/dynamic compilation. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OpenSSL and Phar
Pierre Joye wrote: As testing has_xxx at runtime looks shiny and powerful, I don't think it is worth the pain. What pain? Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] LSB forward_static_call()
On Monday 23 June 2008 3:21:54 pm Lars Strojny wrote: > Hi Stas, > > Am Montag, den 23.06.2008, 09:57 -0700 schrieb Stanislav Malyshev: > [...] > > > Why having parent:: at all then? You could always use the class name, > > right? But for some reason we do have parent:: - and that reason is > > that using explicit class name is not a good style in this context, it > > both obscures the intent and makes unnecessary dependencies in the > > code. Now imagine on top of that we have name:: and parent:: work > > differently, so you don't have choice but using name:: for certain > > things. > > An wide-spreaded usage example for non-forwarding calls is? I would > estimate, that in 70% percent, it doesn't matter, what kind of call > strategy is choosen, 29% percent will be forwarding calls and only 1% > are non-forwarding. > > cu, Lars I implemented a task-specific ORM last fall where the lack of late static binding really bit me, resulting in the need to duplicate code. I'll see about sending it to the list tomorrow from work as a practice example we can kick around. :-) (At least I think it's an LSB issue; if it isn't, I'm sure I'll get flamed for being off topic. ) -- Larry Garfield [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] LSB forward_static_call()
On 6/23/08, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Hi!
>
>
> > why would anyone need that?
> >
>
> To use function that does use static without dependence on in which context
> if was called (or, explaining it other way, when your chain of inheritance
> serves multiple purposes):
>
> class ActiveRecord {
> static function getRow($condition) {
> $table = new Table(get_called_class());
> return $table->find($condition);
> }
> }
>
> class Users extends ActiveRecord {
> }
>
> class DepartmentUsers extends Users {
> static function find($user) {
> if(self::user_in_department($user)) {
> return parent::getRow("user=$user");
> }
> return false;
> }
> }
>
> $user = DepartmentUsers::find("bob");
>
> Now in this case if your way is implemented, ActiveRecord would try to find
> table for DepartmentUsers, which probably does not exist. You would have to
> name Users by name there to do what this code wants to do, which leads us
> back to "why we have parent:: at all" argument.
in my ActiveRecord, table for DepartmentUsers would actually exist ;)
> > "parent" is related to inheritance and it is logical, that it retains
> > call-chain.
> >
>
> It is "logical" if you look at it with the narrow point of view of what you
> need for your particular application. However, there are other use cases.
> Automatic forwarding may become very awkward if you have multiple levels of
> inheritance not all of them used for the same thing.
I am just looking for consistency. I am expecting get_called_class()
to work as a static analog of get_class(this)
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
