Re: [PHP-DEV] Proposal to unbundle imap/pspell/oci8 extensions for PHP 8.4
On 15.09.23 17:54, BohwaZ wrote: I'm not against the removal, but having to rely on user-space libraries probably means we'll lose some performance over using the C library. to quote from the message that started this thread: "Please remember, that unbundling extensions does not mean that they disappear. They will be moved to PECL with a release made." I have fond memories of ext/imap back in the days (it basically was one of the key reasons for me getting involved with PHP in the first place back then), but even without the upstream lack of maintenance situation it should probably have long moved to PECL already ... -- hartmut -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Forum software
On 09/11/2013 04:46 PM, John Betley wrote: I'm in full support of this idea. In order to have more meaningful and on topic discussions, we have to provide ourselves with the means and tools to do so. I think having a forum would be excellent. my personal experience with "we have both a forum and a mailing list" setups was the opposite unfortunately ... this may have been due to lack of moderation, but the main point IMHO was that having both quickly leads to separation (by preferred workflow etc.) without any actual improvement on either side ... But then again this is anecdotal, not empiric ... My greatest concern personally would be the lack of an offline option. Not that I do matter in current affairs anymore at all, but back in the days a lot of the work I've done on PHP code, documentation and mailing lists and newsgroups (yes, we had working UseNet groups at some point) has happened offline while i was sitting on long distant trains. Especially catching up with email is something that works very well while not being distracted by "being online" So anything that doesn't support offline interaction would be a big show stopper for me if I were still active here ... PS: A forum that also supports NNTP might be a solution to the "offline" problem. A quick search shows that this has at least been discussed in the context of discourse.org ... from just looking over the result pages it doesn't look as if it has actually materialized though? -- hartmut -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wake up
On 09/11/2013 02:46 PM, Johannes Schlüter wrote: So, I think, it's time to move to a forum. I hope this is a joke. so do I ... -- hartmut -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moving PHP documentation to Git repository
On 06/25/2013 11:10 AM, Johannes Schlüter wrote: That aside: resources is also the issue with the online editor. We have too few people working on docs, so in the end it doesn't make much difference if they don't have time to review edit.php.net or github. (while reviewing on edit.php.net has the benefit that it can directly validate the docbook, github can't) i have to confess that i've only shown the documentation very minimal love in recent years (damn, YEARS! ... when i first started, or better was forced, to use and fix PHP this was supposed to be a 6 month job only ...) In the situations where i'd actually might have time and leisure to do so the web editor fails me though: * on the train or when otherwise mostly offline it doesn't work for obvious reasons * in front of the TV or when being stuck in hotel rooms the lack of screen real estate makes edit.php a not tooo plearurable experience it is usable on small screens somehow, but for a good experience you should have a large primary screen to run it on and a secondary for looking things up (dictionary/translator, source code, ...) (and yes, my multitasking capabilities are far from perfect, but they are for sure good enough for doing translations and watching TV at the same time for most of todays TV content) Doing things "the old way" on the other hand is severely blocked by me not wanting to touch SVN in any way anymore unless i'm payed for it (i'd even prefer doing CVS again instead of "too-little-too-late" SVN, but that's a different story ...) johannes (who is one of the bad people not really actively helping with docs) Is there an official community for that which i could join? ;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
On 11/12/2012 02:20 PM, Antony Dovgal wrote: > While I fully understand the reasons behind this, I still believe this > kind of thing should be done using the documentation only. following that argument we can deprecate E_DEPRECATED altogether, can't we? -1 -- hartmut -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] common issue with version_compare()
On 07/20/2012 11:07 PM, Stas Malyshev wrote: > 1.0.0 and 1.0 are different things. If you want to make a comparison > that takes into account only two components, you can just cut them both > to two components, then compare. it is hart to imagine a 1.0 followed by 1.0.0 in real world, but the only reason for something like this that i can come up with is that, for whatever reason, a project wants to change from two component version numbers to three component ones right after having done a 1.0. And in that case a 1.0.0 following the 1.0 would be a new release, even if it only differs by the extra .0 And so 1.0 < 1.0.0 would be perfectly correct. -- hartmut -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug 54547
Too late to raise this now anyway, but ... On 13.05.2012 04:39, Stas Malyshev wrote: > I know this was discussed a number of times here, but just to bring it > to a conclusion - I intend to apply patch in the bug report - which > removes conversion for strings that do not convert to integers - to 5.4. > If anybody sees anything that breaks because of this please tell. "12345678901234567890" == "12345678901234567890.0" used to be true, is now false ... i'd still say that's ok though as it is a case of "never compare floats for equality" here, now that the decimal clearly says that at least the right side is supposed to be float, not integer ... -- hartmut -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [off] PHP: a fractal of bad design
On 05/07/2012 05:32 AM, Tjerk Anne Meesters wrote: > Validated or not, why would type juggling even come into the picture > if both variables are of the same type? For the simple reason that web forms return all input as strings, even if the input is actually meant to be numeric Many PHP database backend functions also return all result fields as strings regardless of the actual result type, e.g. mysql_fetch_*(), mysqli_fetch_*() and pg_fetch_*() (although that's more debatable) So if both operands look numeric (even though they are actually of type string) type juggling kicks, and in your MD5 example it unfortunately kicks in with a conversion to float for both sides and you're running into the "never compare floats for equality" trap ... (which is being worked on for the string comparison case though, i just don't have the bug number at hand right now) -- hartmut -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [off] PHP: a fractal of bad design
On 05/07/2012 09:28 AM, Arvids Godjuks wrote: > Hello internals, > > I should voice my opinion that such things like comparing two strings > starting with numbers and that they resolve to actual integer/float for > comparation is bad, really bad. That just defies the logic and yealds > absolutly unexpected results. I pride myself that i know the juggling rules > well, but I'm shocked by this to say the least.. you have to see this in the "web context" where all input from a HTTP client arrives as strings without type information (and some database result data comes in as string data, too) In that context it perfectly makes sense that "1" == "1.0" returns true even if both operands are strings. "123ABF453..." == "123DFEABC..." is a different story though, and guess what? These are *not* considered equal, at least not by the 5.3.6 instance on the system i'm currently testing with: will print "no, you don't get in *that* easy!" just fine -- hartmut -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fixing bug #18556 (was: Complete case-sensitivity in PHP)
On 04/24/2012 01:06 AM, Galen Wright-Watson wrote:
> http://svn.php.net/viewvc?view=revision&revision=128060, same author) then
> changes zend_str_tolower to use tolower instead of its custom ASCII-based
> conversion. The commit message is: "make this faster and sexier". Within
> these revisions, zend_lookup_class is case sensitive. This change, in
> combination with 99001, mask the reason for the custom conversion.
Argh STERLING!!!111
ok, part of the story seems to be that i can't find the regression test
tests/lang/035.phpt that i mentioned in bug #18556 anywhere. In the 5.x
code base this is a test for some Expection related stuff, and in the
latest 4.x branch the highest test number in test/lang is 034.phpt
So it seems as if i somehow never really committed my test case and
so Sterling, not being aware of the "turkish" history, unfixed things
during micro optimization withozut anything in place to warn him about
the regression he introduced :(
(AFAIR it was me back then who first stumbled about "i"!=tolower("I")
in tr_TR after noticing that most of our "Image functions don't work
even though the gd extension is active" came from Turkey ...)
--
hartmut
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [off] PHP: a fractal of bad design
On 04/11/2012 05:19 PM, Luke Scott wrote: > The only thing that infuriates me is the ternary operator being left > associative. I want that fixed - screw bc on that one! I have been > programming for 10 years and that one still confuses me! Most people > just add parentheses to "fix" the problem. I wish someone would write > an RFC to change this to right associative like every other language! > *hint hint* i actually never noticed this until now as i keep it as a best practice to never nest ternaries anyway, in any language. To me it's at least as much a sign for a desseased mind as using multiple exclamation marks !!!11eleven ;) The problem i see though is that in code that really relies on this it may become a real nightmare to track down what goes wrong if evaluation order is changed if you're not aware of that change having happened. An E_DEPRECATED may help here, but will also produce a lot of false positives for those using parentheses? Or can we add enough parser magic to only throw warnings for the unsafe uses? ... -- hartmut -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [off] PHP: a fractal of bad design
On 04/10/2012 06:20 PM, Adir Kuhn wrote: > Hi folks, > > today I read this post, I think that some points are valid, follow the link > for > you guys as stuff like this comes up again and again (although not in as epic lenght as this one) i've been thinking whether it might make sense to have some "PHP Gotchas, how they came to be, and why we can't simply fix them" FAQ section in the manual or wiki? If nothing else it would at least help with dealing with this kind of rant (nothing new here, move along, your concerns were already covered in ### in great detail), but also might help that would indeed want to understand why some things are as they are. I'd rather proactively own this kind of discussions than just jump into them whenever they arise elsewhere ... -- hartmut -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_numeric_string an hexadecimal numbers ("123" == "0x7B")
On 04/17/2012 01:20 PM, Nikita Popov wrote: > I don't think this has much BC impact, so it should be possible to change it. Same here, i never even knew that this worked in a string context until recently. Autocast/comparison rules are already complicated enough as they are documented now, and i failed to find anything in the manual that would actually say that hex in a string context is support to work at all ... I can't really judge the BC implications though, so the best way would be to start throwing E_DEPRECATED warnings for now ... or maybe go the X11 way of "deliberately break obscure feature and see how many complaints we get" ;) -- hartmut -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Help w/ Parser
On 11/07/2011 10:12 AM, Keloran wrote: this looks cool if you get it to work +1 want have! :) -- hartmut -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Really random ?
Kenan Sulayman wrote: The rand(x) function alters the avg in 5M iterations really by just 0.1 ? Wow, that's creepy. Is there any way - to make it better ( or a bit as good as the m_twister is ? ) ? there's a reason why mt_rand() is referred to as "Generate a better random value" in the rand() documentation ;) And i can't resist to add http://web.archive.org/web/20011027002011/http://dilbert.com/comics/dilbert/archive/images/dilbert2001182781025.gif -- Hartmut Holzgraefe, MySQL Regional Support Manager, EMEA Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php7- dropping the $ from the variable name - rfc
marius popa wrote: >> 1. Break every single PHP script that is currently in existence. > maybe an legacy mode can be included in ini we want less of such legacy mode options, not more plus this would have to be configured per application and not just per server >> 2. Break syntax highlighting (and probably other tools/functions) for >> every IDE that is currently in existence. > this can be fixed by each ide , I talk about something like sure it can be fixed, but you missed the *every* part plus IDEs, editors, highlight tools etc. would have to support both old and new for quite a while >> I'm not sure that much more needs to be said. > I can give another practical example in wxjscript > from this javascript example that can be run on apache server you can see > that is simpler to read and to learn at least for an beginner > http://www.wxjavascript.net/mysql/index.html so instead of clearly marking variables with $ as such there they need to be declared with 'var' instead, and '->' is replaced by '.' ... ... i don't see much of a difference there from a learning point of view though > What i want to say is that php must go forward and yes you can > change/break things in the engine > like in the php 4 to php 5 migration or php5 to php6 sure we can break things if there is a compelling reason to do so, i'm just totally missing the compelling part here ... -- Hartmut Holzgraefe, MySQL Regional Support Manager EMEA Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How to enable debug for my extension?
Mangol Smith wrote: I'm trying to debug my extension.It says that PHP is built with debug flag, but my not my extenison. I used --enable-debug for PHP build. But, in the extension I wrote I can't find any configure option associated with debug in ./configure --help. I tried using the options --enable-debug and --with-debug options, but no result. PHP is giving a startup error while loading my extension. the information whether to build a debug extension or not is fetched from the PHP installation you're building against, specifically from the ZEND_DEBUG definition in $prefix/include/php/main/php_config.h Looks like you are compiling against a PHP installation that was compiled without debug enabled and then deploying on a system or installation that has debug features built in. If you have several PHP installation with different install prefixes installed on your system you need to specify which to use to build your extension against with ./configure --with-php-config=$PATH_TO/php-config You can check whether you have the right php-config by calling $PATH_TO/php-config --extension-dir This will give you $prefix/lib/php/extensions/no-debug-non-zts-20071006 fror a non-debug build and $prefix/lib/php/extensions/debug-non-zts-20071006 for a debug one. -- Hartmut Holzgraefe, MySQL Regional Support Manager EMEA Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_strtod.c]
Nuno Lopes wrote: I already expressed my opinion.. If you know what's the buggy gcc version, just fail at configure time if it's present. but with a test for the actual buggy behavior, not just the gcc version i'd assume? (thing "regression" ;) -- Hartmut Holzgraefe, MySQL Regional Support Manager EMEA Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new PostgreSQL API
Hartmut Holzgraefe wrote: I finished testing now, the new test case "27large_object_oid.phpt" tests for the new parameters. The test passes with PostgreSQL 8.4 but fails with older versions as i haven't found a good way to test for the new capabilities in the skip test. i'm now testing by pg_version results and have split the test in two files, one skipped if pg_version<8.3, the other if <8.4 I committed my changes to the 5.3 branch only for now as the tests for "oid passed as string" fail in HEAD, i will commit there too once i have that fixed ... unicode string handling added for HEAD and committed MFB there, too -- Hartmut Holzgraefe, MySQL Regional Support Manager EMEA Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new PostgreSQL API
Tatsuo Ishii wrote: I think it should return errors in the case. The intention for the PostgreSQL API is, avoiding automatic oid assigning by PostgreSQL. This is necessary for query based replication tools such as pgpool. Plus, if PostgreSQL fails to assign the specified oid, the transaction will be in abort state anyway. ok, returning errors it is ... I finished testing now, the new test case "27large_object_oid.phpt" tests for the new parameters. The test passes with PostgreSQL 8.4 but fails with older versions as i haven't found a good way to test for the new capabilities in the skip test. I committed my changes to the 5.3 branch only for now as the tests for "oid passed as string" fail in HEAD, i will commit there too once i have that fixed ... -- Hartmut Holzgraefe, MySQL Regional Support Manager EMEA Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new PostgreSQL API
Hartmut Holzgraefe wrote:
i've started looking into the patch yesterday, there are still some
small issues with it though ... i'll provide you with more detailed
comments later today or early tomorrow ...
open questions:
- should the functions return an error if using the specified oid
isn't possible or just throw a warning and return the oid that
was actually assigned and used by the server?
changes:
- there was a mismatch between autoconf macro names and what
was tested against in the source
- ZEND_ARG_INFO entries for the new parameter
- pg_lo_create()
- option parsing is more lightweight and only
one #ifdef is needed
- added a test case file
- updated documentation
- pg_lo_import()
- new parameter is now placed after file name, not before,
as we usually do with new parameters
- only one #ifdef block needed
- updated documentation
- still need to add a test case, function compiles but
i haven't tested it yet
- possible coding style issues, still breaking in a new
emacs installation ...
--
Hartmut Holzgraefe, MySQL Regional Support Manager EMEA
Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering
diff -rubBwNx CVS 5.3-clean/ext/pgsql/config.m4 5.3/ext/pgsql/config.m4
--- 5.3-clean/ext/pgsql/config.m4 2007-07-11 23:51:55.0 +0200
+++ 5.3/ext/pgsql/config.m4 2008-07-06 02:46:48.0 +0200
@@ -92,6 +92,8 @@
AC_CHECK_LIB(pq, PQescapeStringConn, AC_DEFINE(HAVE_PQESCAPE_CONN,1,[PostgreSQL 8.1.4 or later]))
AC_CHECK_LIB(pq, PQescapeByteaConn, AC_DEFINE(HAVE_PQESCAPE_BYTEA_CONN,1,[PostgreSQL 8.1.4 or later]))
AC_CHECK_LIB(pq, pg_encoding_to_char,AC_DEFINE(HAVE_PGSQL_WITH_MULTIBYTE_SUPPORT,1,[Whether libpq is compiled with --enable-multibyte]))
+ AC_CHECK_LIB(pq, lo_create, AC_DEFINE(HAVE_PG_LO_CREATE,1,[PostgreSQL 8.1 or later]))
+ AC_CHECK_LIB(pq, lo_import_with_oid, AC_DEFINE(HAVE_PG_LO_IMPORT_WITH_OID,1,[PostgreSQL 8.4 or later]))
LIBS=$old_LIBS
LDFLAGS=$old_LDFLAGS
diff -rubBwNx CVS 5.3-clean/ext/pgsql/pgsql.c 5.3/ext/pgsql/pgsql.c
--- 5.3-clean/ext/pgsql/pgsql.c 2008-07-02 02:10:54.0 +0200
+++ 5.3/ext/pgsql/pgsql.c 2008-07-07 16:23:40.0 +0200
@@ -350,6 +350,7 @@
static
ZEND_BEGIN_ARG_INFO_EX(arginfo_pg_lo_create, 0, 0, 0)
ZEND_ARG_INFO(0, connection)
+ ZEND_ARG_INFO(0, large_object_id)
ZEND_END_ARG_INFO()
static
@@ -392,6 +393,7 @@
ZEND_BEGIN_ARG_INFO_EX(arginfo_pg_lo_import, 0, 0, 0)
ZEND_ARG_INFO(0, connection)
ZEND_ARG_INFO(0, filename)
+ ZEND_ARG_INFO(0, large_object_oid)
ZEND_END_ARG_INFO()
static
@@ -2992,37 +2994,69 @@
}
/* }}} */
-/* {{{ proto int pg_lo_create([resource connection])
+/* {{{ proto mixed pg_lo_create([resource connection],[mixed large_object_oid])
Create a large object */
PHP_FUNCTION(pg_lo_create)
{
- zval *pgsql_link = NULL;
+ zval *pgsql_link = NULL, *oid = NULL;
PGconn *pgsql;
- Oid pgsql_oid;
+ Oid pgsql_oid, wanted_oid = InvalidOid;
int id = -1, argc = ZEND_NUM_ARGS();
- if (zend_parse_parameters(argc TSRMLS_CC, "|r", &pgsql_link) == FAILURE) {
+ if (zend_parse_parameters(argc TSRMLS_CC, "|zz", &pgsql_link, &oid) == FAILURE) {
return;
}
- if (argc == 0) {
- id = PGG(default_link);
- CHECK_DEFAULT_LINK(id);
+ if ((argc == 1) && (Z_TYPE_P(pgsql_link) != IS_RESOURCE)) {
+ oid = pgsql_link;
+ pgsql_link = NULL;
}
- if (pgsql_link == NULL && id == -1) {
+ if (pgsql_link == NULL) {
+ id = PGG(default_link);
+ CHECK_DEFAULT_LINK(id);
+ if (id == -1) {
RETURN_FALSE;
}
+ }
ZEND_FETCH_RESOURCE2(pgsql, PGconn *, &pgsql_link, id, "PostgreSQL link", le_link, le_plink);
- /* NOTE: Archive modes not supported until I get some more data. Don't think anybody's
- using it anyway. I believe it's also somehow related to the 'time travel' feature of
- PostgreSQL, that's on the list of features to be removed... Create modes not supported.
- What's the use of an object that can be only written to, but not read from, and vice
- versa? Beats me... And the access type (r/w) must be specified again when opening
- the object, probably (?) overrides this. (Jouni)
- */
+ if (oid) {
+#ifndef HAVE_PG_LO_CREATE
+ php_error_docref(NULL TSRMLS_CC, E_NOTICE, "OID value passing not supported");
+#else
+ switch (Z_TYPE_P(oid)) {
+ case IS_STRING:
+ {
+char *end_ptr;
+wanted_oid = (Oid)strtoul(Z_STRVAL_P(oid), &end_ptr, 10);
+if ((Z_STRVAL_P(oid)+Z_STRLEN_P(oid)) != end_ptr) {
+/* wrong integer format */
+php_error_docref(NULL TSRMLS_CC, E_NOTICE, "invalid OID value passed");
+RETURN_FALSE;
+}
+ }
+ break;
+ case IS_LONG:
+ if (Z_LVAL_P(oid) < (long)Invali
Re: [PHP-DEV] new PostgreSQL API
Hello Tatsuo-san Can anybody review my patches? I need to commit the patches and want to work on 5.3 and 6.0. i've started looking into the patch yesterday, there are still some small issues with it though ... i'll provide you with more detailed comments later today or early tomorrow ... -- Hartmut Holzgraefe, MySQL Regional Support Manager EMEA Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering -- 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?
Richard Quadling wrote: How bad would it be to say that namespacing can only apply to classes and not normal functions? i don't see namespacing as an OO only feature, IMHO it is a perfectly valid and useful thing for pure procedural code, too not having namespacing for procedural functions would leave the old ugly concept of bundling functions as static methods within dummy wrapper classes as only option for procedural name space emulation ... which AFAIR was one of the things we wanted to get rid of way back when the whole namespace idea first materialized? -- Hartmut Holzgraefe, MySQL Regional Support Manager EMEA Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] extensions status, to move to pecl or to drop
Pierre Joye wrote: Can be moved PECL - interbase - fpdf - fbsql - sybase and sybase_ct Please let me know if you can either help to maintain an extension or if you see any issue with one of these moves. i can help with fpdf if needed but it should go to PECL nonetheless ... -- Hartmut Holzgraefe, MySQL Regional Support Manager EMEA Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Pierre Joye wrote: Not sure if the rest affects codegen, do you check the version format itself or do you realy on the pear installer for this task? it is not checked yet, but it is an open TODO item anyway ... -- Hartmut Holzgraefe, Principal Support Engineer . Discover new MySQL Monitoring & Advisory features at: http://www.mysql.com/products/enterprise/whats_new.html Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München Geschäftsführer: Kaj Arnö - HRB München 162140 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PECL-DEV] About that PECL versioning thing
Steph Fox wrote: I discovered tonight that I have full PECL karma, so the secondary question is: does anyone have any objection to my making all (or most... I'd leave the package.xml ones for now) PECL modules fit this versioning model? i'm fine with it, and i already changed pecl-gen / CodeGen_PECL to create compliant code. I didn't roll a new release yet though waiting for the final outcome of this ... -- Hartmut Holzgraefe, Principal Support Engineer . Discover new MySQL Monitoring & Advisory features at: http://www.mysql.com/products/enterprise/whats_new.html Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München Geschäftsführer: Kaj Arnö - HRB München 162140 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Thoughts on Feature Request - Arithmetic
Antony Dovgal wrote: On 07.12.2007 18:05, Alexey Zakhlestin wrote: I doubt this is needed in core, but sounds "ok" for an extension. Yes, I'm sure a simple extension using re2c to parse the expressions would be gladly accepted into PECL. or something libeval based ... http://members.bellatlantic.net/~dutky/libeval.html i already started a pecl wrapper for that onece but somehow lost interest. Don't remember why, it was either license issues (it's LGPL now but might have been GPL back then) or build system issues on the library itself ... i'll give it another look tonight in parallel to the TV maybe ... -- Hartmut Holzgraefe, Principal Support Engineer . Discover new MySQL Monitoring & Advisory features at: http://www.mysql.com/products/enterprise/whats_new.html Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München Geschäftsführer: Kaj Arnö - HRB München 162140 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] using classes/objects in extensions
Andrew O. Shadoura wrote: Hello. Can anybody suggest me any docs/tutorials on writing php extensions using Zend API those can work with classes/objects, i.e. declare some classes, create instances of others etc. Thanks. ok, time again for the usual shameless plug: If you're not afraid of code generators doing part of the work you might try http://php-baustelle.de/CodeGen_PECL Its OO features are documented in http://php-baustelle.de/CodeGen_PECL/manual.html#AEN536 The current source for this package is available using svn checkout svn://php-baustelle.de/CodeGenerators/trunk/CodeGen_PECL in there you'll find a subdirectory CodeGen_PECL/docs/examples with lots of example files for OO features. Even if you don't want to use the generator yourself the code generated for these examples might prove useful. That aside "Extending and Embedding PHP" is probably a must have: http://www.informit.com/store/product.aspx?isbn=067232704X -- Hartmut Holzgraefe, Principal Support Engineer . Discover new MySQL Monitoring & Advisory features at: http://www.mysql.com/products/enterprise/whats_new.html Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München Geschäftsführer: Kaj Arnö - HRB München 162140 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: new feature -> with()
Sebastian wrote:
[...] what i'm suggesting is,
that in with(){} you are only allowed to use the methods and variables
defined in the object you are using with(). as in the sample, you are not
using any global functions or else.
this would render 'with' mostly useless as in most
real world situations where a 'with' block might
make sense it wouldn't be standalone but would
at least require some basic function calls to
be of use ...
so with this limitation in place i'd like to revert
my previous -0.9 to a strong -1
--
Hartmut Holzgraefe, Principal Support Engineer
.
Discover new MySQL Monitoring & Advisory features at:
http://www.mysql.com/products/enterprise/whats_new.html
Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München
Geschäftsführer: Kaj Arnö - HRB München 162140
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new feature -> with()
Richard Black wrote: [...] for me it doesn't add any value - only potential confusion. +0.9 it makes sense as a convenience tool if used correctly but can create a hell of a maintenance nightmare if not Almost as bad as GOTO maintenance wise but without the benefits in edge cases. When reading foreign C++ code a lot you learn to love the explicit nature of PHP naming scopes even though it is extra typing as it is clear at first sight whether you are looking at a variable, member variable, function, object method ... It is also clear that everything is from a local scope unless explicitly declared as global within that local scope ... Lets do not weaken this concept ... -- Hartmut Holzgraefe, Principal Support Engineer . Discover new MySQL Monitoring & Advisory features at: http://www.mysql.com/products/enterprise/whats_new.html Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München Geschäftsführer: Kaj Arnö - HRB München 162140 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: mark functions as const for possible optimizations
Nuno Lopes wrote:
My proposal is the following:
some functions when fed with constant arguments always return a constant
value, too. e.g.:
strlen('abcd') === 4.
wouldn't that be called "deterministic" and not "const"?
--
Hartmut Holzgraefe, Principal Support Engineer
.
Discover new MySQL Monitoring & Advisory features at:
http://www.mysql.com/products/enterprise/whats_new.html
Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München
Geschäftsführer: Kaj Arnö - HRB München 162140
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP_FALIAS()
BuildSmart wrote: Thanks for the response, OK I think I can manage that with ease, what I'm contemplating to do is create a mysql_alias extension that aliases the mysql extension functions to the mysqli equivalents uh PHP_FALIAS() would only work for functions having exactly the same parameter signature ... so it would only work with a very minor subset of the mysql/mysqli functions (if at all). For a lot of functions the signature changed so that the database handle is now the first parmeter instead of the last, and even for those that look similar you have to take into account that mysqli relies on objects (even for the procedural style functions) where ext/mysql is all about resources, not objects. There is also the concept of the default connection in ext/mysql that does not exist in ext/mysqli at all so that can't be emulated by just aliasing functions either ... While a ext/mysql -> ext/mysqli compatibility wrapper might make sense it is way more effort to create one, and if you really want to go that way i'd recommend that you do a proof-of-concept implementation using PHP code first before starting the effort to wrap it up in a C extension. That aside i don't think that it would make much sense to create such a wrapper, ext/mysql being deprecated says that we won't add any new features to it. There are no plans to remove it though and any serious security issues or possible incompatibilities with newer libmysqlclient versions will still be fixed. -- Hartmut Holzgraefe, Principal Support Engineer . Discover new MySQL Monitoring & Advisory features at: http://www.mysql.com/products/enterprise/whats_new.html Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München Geschäftsführer: Kaj Arnö - HRB München 162140 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] own php function
Marten Lehmann wrote: I would like to create an own php function which just prints a certain report as phpinfo() does. The function shall not be included into the general php code, I just want to patch my own installation. Where would be a good place for the function? I don't want to create an extention which would have to be included into the configure script, I guess thats too much work. The function shall be able to access the Host-header of the webserver. I'd also recommend that you wrap your function into an extension of its own, it is not as hard as it seems ... (warning, shameless plug to follow as usual) ... especially if you let pecl-gen take care of all the infrastructure work so that you can focus on the desired functionality. Assuming that your function does not take any parameter and does not return anything your pecl-gen input file would look like this: void myinfo(void) Once you've installed CodeGen_PECL from PEAR you can create a working extension from this using the following sequence of commands: pecl-gen myinfo.xml cd myinfo phpize configure make sudo make install After that you can load the extension in php.ini using extension=myinfo.so For more details on pecl-gen see: http://php-baustelle.de/CodeGen_PECL/manual.html -- Hartmut Holzgraefe, Principal Support Engineer . Discover new MySQL Monitoring & Advisory features at: http://www.mysql.com/products/enterprise/whats_new.html Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München Geschäftsführer: Kaj Arnö - HRB München 162140 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] proof of concept or undocumented?
BuildSmart wrote: my current test was to change it to use mysql_config to retrieve the library details which seemed to work. Does that work all the way back to MySQL 3.23.x? It is important that ext/mysql stays compatible with 3.23 and 4.0 as these client library versions are not supported by ext/mysqli ... If it's been EOL'd or NLS'd then working on it doesn't make for a sound decision and my time would be better spent learning how to replace mysql calls with mysqli calls if mysqli has been proven to work properly with mysql-ssl connections. if you stay with the procedural interface then it comes down to 'just' *always* putting in the database handle as first parameter instead of doing so optionally as last parameter only ... See also http://forge.mysql.com/wiki/Converting_to_MySQLi -- Hartmut Holzgraefe, Principal Support Engineer . Discover new MySQL Monitoring & Advisory features at: http://www.mysql.com/products/enterprise/whats_new.html Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München Geschäftsführer: Kaj Arnö - HRB München 162140 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] proof of concept or undocumented?
BuildSmart wrote: The only differences I could find was that openssl was enabled in the working builds but not enabled in the failing build. [...] I went a step further and manually added the ssl libraries (-lssl -lcrypto) to the Makefile (both as bundled and shared) and all worked well. This cannot be considered a bug (or maybe it is), perhaps an additional check could/should be performed to see if mysql is built with SSL support and if so check whether openssl is enabled and add the ssl libraries to the sapi build or to MYSQL_SHARED_LDADD if it's not or to auto-enable openssl? yes, ext/mysql is not too clever about this and simply relies on ext/openssl being enabled at the same time. Adding an extra test can't rely on mysql_config though as AFAIR it is not using mysql_config at all. If you want to check whether you'd need to add a compile/link test with a small example program that tries to e.g. use http://dev.mysql.com/doc/refman/4.1/en/mysql-ssl-set.html I'm not sure though whether this function is only available with ssl-enabled MySQL builds or whether it is always there and just returning error codes, i think it is the later so you'd have to create a functionality test, not just a simple "does it compile and link without errors" one. As this is not a change to the actual functionality of ext/mysql i think a working patch would be accepted even though the extension is deprecated by now. OTOH i don't really think it is worth the effort anymore though ... -- Hartmut Holzgraefe, Principal Support Engineer . Discover new MySQL Monitoring & Advisory features at: http://www.mysql.com/products/enterprise/whats_new.html Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München Geschäftsführer: Kaj Arnö - HRB München 162140 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] proof of concept or undocumented?
Rasmus Lerdorf wrote: It is documented at php.net/mysql in the section on connection constants: MYSQL_CLIENT_SSL Use SSL encryption. This flag is only available with version 4.x of the MySQL client library or newer. Version 3.23.x is bundled both with PHP 4 and Windows binaries of PHP 5. Hartmut Holzgraefe wrote: > ext/mysql development has been discontinued in favor of ext/mysqli, > one of the goals was to integrate support for exactly SSL and the > other new connection options like gzip compressed connections that > are available as of MySQL 4.1. Rasmus is right and Hartmut is wrong ... :( I'd still recommend not to bother with ext/mysql for SSL though as control over SSL options is indeed available in ext/mysqli only by mysqli_ssl_set() -- Hartmut Holzgraefe, Principal Support Engineer . Discover new MySQL Monitoring & Advisory features at: http://www.mysql.com/products/enterprise/whats_new.html Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München Geschäftsführer: Kaj Arnö - HRB München 162140 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] proof of concept or undocumented?
BuildSmart wrote: I see that the mysqli extension is essentially a wrapper and it obtains the required libraries from the mysql_config script so if mysql is built with ssl support the mysqli module will include this library and theoretically should work with ssl connections. My question though is related to the mysql module itself which doesn't have any ARGS for ssl support or a method to automatically retrieve dependant libraries and is more of a client When talking about "the mysql module" itself you're talking about ext/mysql, right? ext/mysql development has been discontinued in favor of ext/mysqli, one of the goals was to integrate support for exactly SSL and the other new connection options like gzip compressed connections that are available as of MySQL 4.1. See also http://php.net/mysql: Although this MySQL extension is compatible with MySQL 4.1.0 and greater, it doesn't support the extra functionality that these versions provide. For that, use the MySQLi extension. By that time the codebase of ext/mysql had become a bit of a mess. It was one of the first PHP extensions ever and there were a few design decisions made back then that made it almost impossible to add new features to the existing functions (e.g. the db handle being an optional parameter at the *end* of most functions argument list made it impractical to add any further parameters). The code was also full of conditional compile branches as it supported mysql client libraries back to at least MySQL 3.23. > so before submitting a > feature request , writing a proof of concept or working on code for a > capability that might already exists but is undocumented, I thought I'd > ask first. It doesn't really make sense to add a feature request for a deprecated extension. All further development effort will go into ext/mysqli only. I just checked the manual pages for ext/mysql and ext/mysqli and found that we're not really making this clear in the documentation, i'll bring this up with the ext/mysqli maintainers today and we'll have http://php.net/mysql be more explicit about this. -- Hartmut Holzgraefe, Principal Support Engineer . Discover new MySQL Monitoring & Advisory features at: http://www.mysql.com/products/enterprise/whats_new.html Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München Geschäftsführer: Kaj Arnö - HRB München 162140 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] buildconf and the generated configure script for PHP6 is faulty [the fix].
Hello Mr B*S* The complaints over the 4 or 5 I have mentioned on the list has borne the remarks that I swamp the list with the reports, how it would be if I dumped a couple hundred? if you dumped them on the list you would end up in everyones ignore list as *the list is not the right communication channel for that* If the bug system is not the right place to put things then nothing is. Is this really so hard to understand? To disregard the perception of the PHP software and it's developers is a stoic thought concept, since you have no issues accepting the concept that the majority of end users believe that the PHP software is a collection of cruft managed by a group of pompous programmers doesn't mean that the other developers share in this concept, image in a web-related world has value whether you give it any or not so airing everything isn't always the best policy. Talking about image, why are you trying *so* hard to ruin your own? Rather than contribute to any negative thoughts and impressions that would be attained by submitting countless bug reports How do bug reports contribute to a negative impression? There is no bug free software. And having the known bugs tracked in the open instead of somewhere under the hood is is actually building trust instead of demolishing it IMHO that would take months if not years to process Did you try? where does this estimate come from? I see a lot of claims in your postings but only very little fact it is built upon or most likely just be ignored, One of the things that influences whether a bug is ignored or taken serious is the attitude of the reporter, too. Things that do not help with that: - Insisting to push things to the wrong communication channels - revealing the actual fix you claim to have only several messages down the thread instead of right away - not providing version information up front ... yes, the autoconf version you were using was to be found in the post somewhere ... but you ignored a very simple and substantial rule that applies to all forms of one-to-many communication: "the burden shall be on the writer, not the readers" I believe it's best to refrain from such submission unless it's absolutely critical. well, if you think so ... > This is going absolutely nowhere, I'm dropping out of this discussion > to avoid retaliations due to bruised egos. Has there been a discussion? At least from your side it was mostly flaming IMHO. Anyway, i agree that this is not getting us anywhere. You've clearly shown that you want to have it your way and are not willing to adapt in any way ... -- Hartmut Holzgraefe, Principal Support Engineer . Discover new MySQL Monitoring & Advisory features at: http://www.mysql.com/products/enterprise/whats_new.html Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München Geschäftsführer: Kaj Arnö - HRB München 162140 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] buildconf and the generated configure script for PHP6 is faulty [the fix].
Dear Mr. BuildSmart I'm not interested in filing a minimum of 100 bug reports when you don't have the manpower to process them, I've resolved most of them already (at least the ones related to the php base) and any that I haven't I've noted as "Broken - DNU" so I don't pass anything unstable on to my clients. if you want your fixes applied you need to get them reviewed for now, and the proper workflow to get that done is to file bug reports with patches attached, not posting them in the mailing list (and especially not putting them in only rather late in a thread). Posting patches to the mailing list right away sort of works, too, but in the long run it produces *more* work for everyone, not less. You don't have to agree with this, but you have to accept the established workflow nonetheless ... or accept not being taken serious (which your insistence of not putting your real name into your "From:" field already substantially contributes to ...) -- Hartmut Holzgraefe, Principal Support Engineer . Discover new MySQL Monitoring & Advisory features at: http://www.mysql.com/products/enterprise/whats_new.html Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München Geschäftsführer: Kaj Arnö - HRB München 162140 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] buildconf and the generated configure script for PHP6 is faulty [the fix].
Dear Mr BuildSmart BuildSmart wrote: SInce I didn't consider it a bug but rather a minor error of importance, just out of curiosity: how do you define "bug" if not as "any error"? I thought it would best be handled by making the maintainers aware of the issue since the fix is relatively simple and provided to avoid the filing of bug reports which would have occurred. this is wrong in several ways: - your original posting did not include the actual fix but only what should change in the generated configure file the actual fix was only in your mail of 12:10 today. giving you the benefit of the doubt i'd assume for now that it was attached to the original message, too, but got stripped, this would not have happened with a bug report though - the bug database is not only a todo list, it is also a repository of bugs fixed in the past. e.g. have you noticed the duplicate detection when filing a bug? with a bug fixed out of band without involving the bugs db duplicate detection can't kick in on new bug reports - changelog entries usually refer to a bug number, having them point to a mail archive instead would be inconsistant and so bad - same for commit messages ... add to this that it is easy to refer to a bug number but way less so to refer to a distinct email So working around the bug system is not a shortcut, it actually generates *more* work in the long run. The bug system is there to be *used*, not to be circumvented. If you had submitted your finding as a bug report with proper how-to-reproduce instructions (which your original message did not have, what you wrote there was way to vague) and also with your patch to ext/standard/config.m4 things would probably been handled just fine already. Look what mess you caused instead ... :( -- Hartmut Holzgraefe, Principal Support Engineer . Discover new MySQL Monitoring & Advisory features at: http://www.mysql.com/products/enterprise/whats_new.html Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München Geschäftsführer: Kaj Arnö - HRB München 162140 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] buildconf and the generated configure script for PHP6 is faulty.
BuildSmart wrote: [... inappropriate language removed ...] Why would I want to downgrade, don't tell me it's because you claim all other versions are buggy, I find that hard to accept since the only problem I've ever experienced to date has been with PHP6 > and swapping two lines corrected this. Well, the fact that the lines ended up in the wrong place in the final configure file produced while the one created with 2.13 ... what is that if not a strong indication of an autoconf bug? buildconf just calls autoconf, so why do you think it is to blame for wrong autoconf output that only seems to happen with *some* versions of autoconf? -- Hartmut Holzgraefe, Principal Support Engineer . Discover new MySQL Monitoring & Advisory features at: http://www.mysql.com/products/enterprise/whats_new.html Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München Geschäftsführer: Kaj Arnö - HRB München 162140 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Syntactic improvement to array
Mathias Bank wrote: It don't think so: PHP is a good language, but writing code in PHP is sometimes awful. This could be improved by an alternative syntax. This could help new developers who are coming from another language. This could make coding funnier for some developers. Alternative syntax is what makes reading someone else's Perl code "funny" ... ;( > So: what's the matter? The idea of [] does not harm existent code. > Everyone who does not like this syntax can avoid it in his code. > But please don't tell others how they have to write their code! > Let them write! This violates a simple but important principle: The burden shall be on the writer, not the readers. As long as you write code all by yourself and never share it in any way your argument may hold true. The very second your code needs to be read or even maintained by others alternative syntax choices quickly become a nightmare. So you have to agree on one form or the other and add yet another item to your coding style rules list. So you even have to bother *more* about telling others (or yourself) how to write code than you had to with only one syntax alternative. As a matter of taste i do prefer the [] alternative over the current array()/list() approach. But we can't get rid of array() or list() any time soon, even if we would decide to deprecate them now in favor of []. So we're stuck with them and the nicer syntax does not justify the can of worms opened by introducing an alternative syntax for an already existing feature. So if we were designing PHP today i'd be all for [] and [] only, but as things are my vote is mostly against it even though i sort of like the syntax. So from my side a -0.8 -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Autoglobal CVs without silence -- Summary
Sara wrote: > I've produced a couple of major lightbulb moments in people with this explanation, but it all stems from introducing the concept of an object's handle rather than saying objects are reference by default. i usually got these "aha!" events when using inodes and hard links as metaphers ... -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is this what Stefan Esser was referring to ...?
Stefan Esser wrote: Hello Marcus, that's plain wrong what you wrote. First PHP license is OSI Approved and for that defintively does not violate any OSI recommendation. Besides that We will see how OSI explains how a discriminating license can be OSI approved. well, given that the Apache license has the very same restriction in it (there are minor wording differences and it obviously protects the term "Apache" instead of "PHP") and that the Apache license was among the first to become OSI approved the explanation should be clear: "discrimination" is defined as discrimination in the use of the code, not the name. So "you may not use this code for military purposes" or "this code may not be modified by left handed people" would be discriminating by the OSI definition while "you may not re-publish it using the same name" or "you may not re-publish it without copyright notices left intact" are not ... If we were talking about GPL compatibility or the FSFs definition of Free Software instead of OSIs definition of Open Source Software things might be a bit different, but we aren't ... So please stop making a fool of yourself, you're riding a dead horse here and no matter how hard you beat it, it won't go any faster (or go at all) ... -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is this what Stefan Esser was referring to ...?
Robert Cummings wrote: Sounds like PHP should have been trademarked [...] i don't know about the rest of the world, but here in .de you won't get a trademark on a 3 letter name anymore, and this has been so for quite a while, afaict since far before PHP came to light ... -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Build and gcov test of PHP_5_2 finished
Pierre wrote: Is it possible to have an access to the outputs of the failed tests? There is tests which fail on the gcov machine but work on every machine I use. one thing i notices is that the machine doesn't seem to have any locales installed which e.g. lead to ext/gettext tests and others being skipped ... -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
Richard Quadling wrote: >> On 02/08/06, Hartmut Holzgraefe <[EMAIL PROTECTED]> wrote: >> Is function overloading really "an OOP thing"? I think so, I've only ever used it within Delphi, so my POV may be skewed. proving by example? ;) To quote http://www.codeproject.com/soap/RefAndOL.asp "For a language to be said .NET complaint, it should be truly object oriented and therefore must support polymorphism. Method overloading is one of the pillars of polymorphism. Overloading means methods with the same name but different parameters. Just as we overload methods in regular applications, we can overload XML WebMethods also." I've always considered it to be the case. You are mixing concepts here. Yes, function overloading is crucial to polymorphism. And OO languages usually heavily rely on polymorphism. But does that make polymorphism an OO feature? Polymorphism does exist outside the OO world, e.g. in functional languages. Whether it is crucial for OO is a different question ... But even then we have different types of polymorphism to look at. What you are requesting is ad-hoc polymorphism, there are other classes of polymorphism though ... e.g. PHP userland functions without type hints are already polymorph in that they accept any number of arguments of any type. PHP will issue a warning if you call such a function with less parameters than specified in the functions parameter list, but you cann still call it nevertheless. This qualifies as a form of parametric polymorphism which is the other major kind of polymorphism besides ad-hoc polymorphism. PS: your quoting style sucks. please put your answers *below* the question -- Hartmut Holzgraefe, Senior Support Engineer. Hauptsitz: MySQL GmbH, Radlkoferstr. 2, D-81373 München Geschäftsführer: Hans von Bell, Kaj Arnö - HRB München 162140 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
Richard Quadling wrote: That was done before, so it could be done again. In principle, there is nothing wrong with refactoring or even rewriting, except time and effort. totally changing the underlying type concept in an incompatible way is not refactoring, and even as a rewrite i'm strongly in doubt whether the result deserves to go by the same name as the original We have OOP developers wanting OOP things that they've seen working fine in other languages and non-OOP'ers wondering why! Is function overloading really "an OOP thing"? As this is a discussion forum, all things SHOULD be considered! There is a difference between discussion and brainstorming ... -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
Richard Quadling wrote: This is where PHP's strengths can be seen as a weakness. If parameter overloading is wanted then it would be easier if PHP was not a loosely typed language. it wouldn't bee PHP then anymore, neither from the user experience nor from its internal implementation. This would require an almost 100% rewrite ... -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
Ron Korving wrote: So, my suggestion is this: why not support function overloading in PHP6, because in PHPs dynamicly typed world this would require runtime checks *on every single function call* as things can't be resolved at compile time? -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RfC: rethink OO inheritance strictness
Stefan Walk wrote: For the people who have said "I can not understand why this is a bad thing": http://en.wikipedia.org/wiki/Liskov_substitution_principle so it is a bad thing when aiming for substitutability, i lack to see an argument yet for substitutability being a must have in all situations (just as a normalized data model is not always the right choice in database design ... it's something to aim for but if it were enforced this would be BAD THING(tm)) -- Hartmut Holzgraefe, Senior Support Engineer. Hauptsitz: MySQL GmbH, Radlkoferstr. 2, D-81373 München Geschäftsführer: Hans von Bell, Kaj Arnö - HRB München 162140 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extensions building tutorial
Artzi, Yoav (Yoav) wrote: I am looking for a good place to learn about the following: 1. Writing a customized extension 2. Compiling PHP with customized extensions, including how can I set up a customized location their code and what I should add to the configure line and such Any good tutorials out there? and now for the usual shameless plug: CodeGen_PECL: Tool to generate PECL extensions from an XML description PEAR package: http://pear.php.net/package/CodeGen_PECL/ Documentation: http://php-baustelle.de/CodeGen_PECL/manual.html Examples: http://cvs.php.net/viewcvs.cgi/pear/CodeGen_PECL/docs/examples/ -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com Are you certified? http://www.mysql.com/training/certification -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] private, protected, readonly, public
Sebastian Bergmann wrote: Stefan Walk wrote: I'm against visible private variables. If they are visible, they are part of the interface of the class, which means changing the implementation means a BC break. This is a valid point against readonly, indeed. no, it is a valid point against implicit visibility, not against *declaring* a property as readonly -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com Are you certified? http://www.mysql.com/training/certification -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] private, protected, readonly, public
Hartmut Holzgraefe wrote: Zeev Suraski wrote: What does that give you that class constants don't? i on the other hand fail to see how it is related to class constants at all? hm ... this was not supposed to get out as i had seen your reply to yourself ... -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com Are you certified? http://www.mysql.com/training/certification -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] private, protected, readonly, public
Zeev Suraski wrote: What does that give you that class constants don't? i on the other hand fail to see how it is related to class constants at all? -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com Are you certified? http://www.mysql.com/training/certification -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: private, protected, readonly, public
Ron Korving wrote: In C++ you'd use private for this. All object members are readable, ... Could you elaborate on this? -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com Are you certified? http://www.mysql.com/training/certification -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: tests
Jeff Moore wrote: On May 13, 2006, at 10:08 AM, Marcus Boerger wrote: Therefor we need more tests. Hi, I just wanted to point out that http://www.w3.org/XML/Test/ has thousands of XML test cases in a well defined format (XML, of course). They might be good for testing the XML processing portions of PHP. While there are likely a bunch of obscure cases that PHP would not pass, this test suite might help detect changes in XML processing between versions of PHP. Isn't this a task for the libxml2 developers instead? PHP just relies on it in everything XML, it doesn't do any processing itself (or have i missed something lately?) -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com Are you certified? http://www.mysql.com/training/certification -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] private, protected, readonly, public
Bastian Grupe wrote:
Blame my recent use of Java here ;-)
Well, I think the whole point of ppp is to having to use setters and
getters consistently.
i'm going to blame your use of Java for this one, ppp is way older
than the setter/getter fashion and as far as i remember the main
reason to introduce the setter/getter pattern into java was to
have a standard way for Java IDEs to provide access to Java Bean
properties in property dialogs in their GUI design tools
I personally wouldn't like to be able to access some members which are
private, and not others. It just *feels* wrong.
Think of it as a more fine grained permission system, like unix
file attributes. Reading and writing a property value are two
different operations and it makes sense to distinguish access
rights not only by ownership but also by type of operation.
And I don't know whether or not less typing is really a good argument in
this situation (think unreadable code in shortcut-ish programming
languages).
Less typing is not an argument by itself, else we'd all do APL
But less typing is less error prone (and no, plese *don't* mention
auto-completion here ;), it can be less readable, too, and in this
special case it spreads information that should be in one place.
Maintainability can become an issue, too.
Take a look at typical PHP class implementations: they have
all properties on top followed by the member functions. So to find
out whether a private property is really provite or whether it has
a getter or even a setter, too, i would have to browse the full
class code.
class example {
private $foo;
private $bar;
[... more properties ...]
function __construct() {...}
function __destruct() {...}
function getFoo() {...}
[... more code ...]
}
So $foo is readonly here and $bar is really private. Or wait,
maybe we have just overlooked getBar()?
With
readonly $foo;
on the other hand you have all the information in one place.
If you want to go the getter/setter path all the way then we
wouldn't need all the ppp stuff anymore alltogether, we would
just make everything private and have the getter and setter
decide (using instanceof on $this etc.) the access rights.
--
Hartmut Holzgraefe, Senior Support Engineer.
MySQL AB, www.mysql.com
Are you certified? http://www.mysql.com/training/certification
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] private, protected, readonly, public
Bastian Grupe wrote:
Uhh... how about using private and only using a "regular"
getter (the Java-style) and no setter?
class xx
{
private $bar;
public getBar() { return $bar; }
}
i think you're missing the point, the idea is to *not*
have to write that extra getter line ... less typing
*and* less error prone ... and easier to read, too IMHO
You didn't want to return $bar in your example, you wanted
to return $this->bar so you already ran into one of the
issues here ;)
--
Hartmut Holzgraefe, Senior Support Engineer.
MySQL AB, www.mysql.com
Are you certified? http://www.mysql.com/training/certification
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] private, protected, readonly, public
Etienne Kneuss wrote: 2) It only requires a bit of discipline, not to edit the properties you want to be readonly. well, then we don't need private/protected/public at all, as it only requires a bit of discipline not to access the properties you want to be visible to the class or its children only? -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com Are you certified? http://www.mysql.com/training/certification -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: new function: php_get_tmpdir() - bug #35380
Pierre wrote: That would really nice to have it. Temp directory detection is a pain. added the function and documentation now, but i'm not sure about the name yet, php_get_tmpdir() seems to be the better choice to me but php_tmpdir() would be more in line with the ohter info functions with php_ prefix it seems? -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com Are you certified? http://www.mysql.com/training/certification -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] new function: php_get_tmpdir() - bug #35380
I have added a small function requested by bug #35380 that exposes the C API function php_get_temorary_directory() to userland as php_get_tmpdir(). The patch is available from the bug page http://bugs.php.net/bug.php?id=35380 I can't oversee whether this has any security implications although i can't think of any ... Anny comments before i proceed to commit? -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Developing PHP
Rasmus Lerdorf wrote:
Tim Van Wassenhove wrote:
I thought that {{{ and }}} were there because they are markers for vim
code folding.
Emacs too actually.
As far as i remember emacs folding mode supported these first
and vim only picked this up later
I am jetlagged (twice), was stranded in heathrow for 6 hours
due to my stupidity (which i'd like to see as a followup of
jetlags and as such as a temporary state only), have just
missed the last fast train connection home by ~5min and
will now not only have to wait for another hour but the train
will also take an hour longer than the regular ICE connection ...
i hope this explains things ... or maybe it explains why this
doesn't explain things at all ... whatever ...
--
Hartmut Holzgraefe, Senior Support Engineer.
MySQL AB, www.mysql.com
Are you certified? http://www.mysql.com/training/certification
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] more candidates for PECL
Wez Furlong wrote: It'd be good to have Hartmut's view on that, since he wrote both those systems. I suspect that Hartmut will want to keep at least one of them around in the core. *DISCLAIMER* I did *not* write ext_skel, i tried to maintain it for a short while but gave up on that pretty soon ... pecl-gen should be ext_skel compatible (i haven't checked this for quite a while though) i don't mind whether it stays or not, i haven't used it for years now whether pecl-gen is more maintainable is quite arguable thow ;) (although at least it does not depend on arcane tools like awk ...) -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com Are you certified? http://www.mysql.com/training/certification -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GOTO and/or BREAK LABEL
Steph Fox wrote: Still to vote: Derick, Marcus, George, Sascha, Hartmut, Chregu, Johannes, Sebastian, Stefan, apologies if I missed any names here. 1) -1 2) +1 3) +.5 4) -0 -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com Join me at MySQL's 2006 Users Conference, April 24-27! http://www.mysqluc.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GOTO and/or BREAK LABEL
Sascha Schumann wrote: 5) goto, fowarding-jumping only. which would more or less make it useless for state machine stuff, right? -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com Join me at MySQL's 2006 Users Conference, April 24-27! http://www.mysqluc.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Private data in C/C++ generated classes for Php - example?
Andrew Mather wrote: Further to my earlier mail, does anyone have/know of a working example that demonstrates private data held in C/C++ and encapsulated within a Php/Zend object for storage, exposing a Php class, per George Schlossnagle's recommendation/example? (warning: shameless plug ahead as usual) not per Georges example but CodeGen_PECL has support for this it is not docuemted yet but there is an example in its CVS repository that shows how to create a class with payload data which is also used as a testcase: http://cvs.php.net/viewcvs.cgi/pear/CodeGen_PECL/docs/examples/class_payload.xml?view=markup -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com Join me at MySQL's 2006 Users Conference, April 24-27! http://www.mysqluc.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP / C++ Interaction
Steph Fox wrote: Just search the archives, or the zend weeklies index page (http://www.zend.com/zend/week/) if you're short of time. I remember linking to someone's material regarding C++ extensions for PHP a few months back, and it'll be in the 'item descriptions' there. Yet another shameless plug: CodeGen_PECL (http://pear.php.net/package/CodeGen_PECL/) supports C++ extension writing just fine (including the needed config.m4 magic etc), see e.g.: http://cvs.php.net/viewcvs.cgi/pear/CodeGen_PECL/docs/examples/resource_cpp.xml?view=markup -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] True labelled breaks
Wez Furlong wrote: I think not many people use it because it's difficult to use. Having real labels might change that. Personally, I'd prefer real goto, as I've stated in the past. Just for the record again, I'm +1 for goto, and +0.5 for labelled breaks only if we've totally given up on goto. FULLACK -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] True labelled breaks
Derick Rethans wrote: I will use it. << that good enough? :) But seriously, I have quite a few cases where I would use it if it was available. same here ... i tried to avoid the current "break n;" where ever possible as it is easy to run into a maintainance nightmare with it (renumbering! this is so 80ies BASIC ...), so i tend to use flag variables instead in cases where i need to terminate several nested loops. labeled breaks are *so* much better/cleaner than both approaches above that i'd really love to have them ... IMHO "break n;" is even more evil than "goto label;", it is almost in the same league as "goto linenumber;" ... -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dead C Scrolls - Missing Code for Writing New Extensions without recompiling PHP
Andrew Mather wrote: i)a walkthrough of the exact steps + sample code to write an extension without requiring re-compilation of Php and without access to Php source code maybe its time for a shameless plug one more time: http://pear.php.net/package/CodeGen_PECL/docs this approach will shield you from autoconf/make details as much as possible, it will also generate windows VS 6.0 .dsp project files, too ii) as above but with access to Php source code its not mentioned in the above docs, but compiling the generated extension code staticly into PHP just requires these simple steps: - place the generated code directory into PHPs ext/ directory - run buildconf (in the top level src directory) - if you've already built php from this source tree before do config.nice ...any-options-specific-to-your-extension else extract the configure string for the current php installation from "php -i" output, re-use this configure line and add your extensions options to it - make - optional: make test - make install (may require sudo) iii) as above (either i or ii) but with instructions to allow the project to be initiated and compiled within the KDE development environment i don't know / use Kdevelop, but i'm pretty sure that it allows to integrate standard unix projects based on configure/make ... Resulting object (presumably .so) to be accessible in a distribution release of Apache/Php with only minor modification of a client's Apache/Php config settings. using CodeGen_PECL you'll get a full self contained extension project, including a package.xml file suitable for automatic installation using the pear installer -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 23 nothing is so as it seems, but why
Marco Kaiser wrote: Today during a session i had a strange "magic" feature found in php. there is a very simple rule that PHP inherited from C: never use pre- and postfix increment operators in the same expression as the results are undefined -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Naming Arguments
Andi Gutmans wrote: Not sure if there's a list. I think it's 90% or so not converted. Andrei, you can answer this one better than me. well, the only one i checked so far was my levenshtein() function, and seeing something as esoteric as this already being converted made me think most of the reast was, too -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Naming Arguments
Andi Gutmans wrote: Andrei is waiting for volunteers to upgrade internal functions to Unicode :) is there a todo list of functions converted, being worked on, pending? -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Naming Arguments
Jared Williams wrote: Perhaps some tool to generate boiler plate docbook from introspection > would be enough encouragement? we can already generate this from the proto comment lines or you could use PEAR::CodeGen_PECL which generates C code and DocBook at the same time ... -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] problem with zend_register_internal_class
Antony Dovgal wrote: You forgot to add TSRMLS_CC macro: zend_register_internal_class(&ce TSRMLS_CC); see also http://www.php.net/manual/en/zend-api.zend-register-internal-class.php -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Named arguments revisited
Jared White wrote: While ideally it'd be nice to have named parameters used in the core of PHP, I realize that's probably an impossible task at the moment. So I agree that the main goal is to allow users to define APIs in PHP using this feature. If that's all we had, it'd be good enough I think. (At least, it'd certainly serve my needs. :) ) So far there is no difference between a user level and an internal function from a callers point of view, adding such an asymmetry now really doesn't sound like the right thing to do ... -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Named arguments revisited
Brad Fisher wrote: Thus no need to rework internal parameter passing API at all. Perhaps I'm missing something? you missed that the parameter name information is just not available for internal functions, the api works by parameter positions only right now, so at some level you *have to* add this information for all the 4,000+ extension funcitons out there ... -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Named arguments revisited
Lukas Smith wrote: Its sole purpose is to deal with situations where you have a considerable number of parameters. well, i for one would love to write something like $pos = strpos(haystack=$str, needle="foobar"); instead of looking up parameter orders all the time :) -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Named arguments revisited
Lukas Smith wrote: - all internal and PECL functions need to be recoded as the API right now doesn't know any concept of parameter names at all I was thinking that this would a userland only feature. do we really want to add even more inconsistencies to the language? -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Named arguments revisited
Ron Korving wrote: Let me summarize it for you then. Advantages of named parameters over associative arrays: - cleaner syntax - support for type hints - difference between required and optional parameters - generating documentation (whether with something like phpDoc or an IDE) - ... Can anyone summarize the disadvantages now please? - all internal and PECL functions need to be recoded as the API right now doesn't know any concept of parameter names at all -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Named arguments revisited
Andrei Zmievski wrote: Hartmut, there are only 2 or 3 of those functions where the order differs. but it's the fact that it differs at all that counts ... -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Named arguments revisited
Frank M. Kromann wrote: And if you have many parameters to functions you still need to look at the definition (or documentation) to figure out what parameters the function takes. It's not a big problem to look at the order at the same time. lets face the opposite direction for a second: all those string functions with different order of haystack and needle named parameters could help to reduce the criticism we get for this poor choice of parameter order in the past ... -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Support for friend classes
Greg Beaver wrote: By definition, if you're accessing it from another class, then perhaps it isn't "private" at all. in C++ "friend" gives access to both "private" and "protected" ... This can be more easily and intuitively solved by using protected and CoderTest extends Coder, given that PHP doesn't have multiple inheritance this just doesn't work out all the time, so this would actually be an argument *for* "friend" in PHP or just making it public and documenting in the code where it should and should not be used. this argument can easily be extended to "don't use the PPP stuff at all" "friend" on the other hand is a mechanism to allow more fine grained access control "friend" extends PPP in a similar way as ACLs extend the unix file access control mechanisms "user/group/others" concept ... -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Labeled Break (nothing at all whatsoever to do with GOTO)
Stanislav Malyshev wrote: SG>>* Labeled breaks also apply to continue; For example: yes, I think it's a good way to do it. oh, totally forgot about that, another strong reason for having it in parallel to any GOTO solution we come up with -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Labeled Breaks (not the G-word)
Ron Korving wrote: Well that's because labeled breaks should (in "our" opinion) be implemented paralel to goto. It is simply not the same. Of course you could break out of loops with a goto statement, but I'd much prefer true labeled breaks, where the label is set for the loop-construct itself, not after the construct. So labeled breaks have only 1 use case: * escaping deeply nested loops or if statements 'goto' should solve the others. FULLACK, labled breaks are great if you really just want to get out of nested loops or if statements, just in combination with error handling the GOTO variant looks more readable in some cases -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV]
Mike Hall wrote: Just FYI, the lack of as far as i remember the only arguemnt against http://www.php.net/unsub.php
Re: [PHP-DEV] Labeled Break (nothing at all whatsoever to do with GOTO)
Ron Korving wrote:
I loved Joao Cruz Morais idea of using the 'as' keyword in this:
while (true) as outer_cycle {
$i = 0;
while (true)
if($i++ == 10) break outer_cycle;
}
might become a bit confusing with
foreach ($array as $val) as someloop {
but that aside i like the syntax :)
--
Hartmut Holzgraefe, Senior Support Engineer.
MySQL AB, www.mysql.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Labeled Break (nothing at all whatsoever to do with GOTO)
Ilia Alshanetsky wrote: I guess I fall into Group B, and I must say that I'd prefer either to see goto/jump like construct or nothing at all. Be it a crippled goto/jump or labeled breaks. So, my vote is a -1. think of not in the context of GOTO but as in 'break _number_;" finally done right' -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Labeled Breaks (not the G-word)
Joao Cruz Morais wrote:
I'm sorry if I'm saying something that was already proposed, but why
not use the Java approach to labeled breaks or something like this
(dumb) example:
while(true) as outer_cycle {
$i = 0;
while(true)
if($i++ == 10) break outer_cycle;
}
well, this is only handling one of the three GOTO use cases
that we seem to agree on as being 'ok'
* escaping deeply nested loops or if statements
this one it would handle, just as "break _number_;"
does right now, so it would be a viable option even
in parallel to GOTO or as a fallback position if we
can't reach agreement on GOTO at all
* jumping to a central error handling/cleanup point
this it can't handle unless you use it in combination
with an extra $error flag
while this is a viable approach i prefere
for (...) {
for (...) {
for (...) {
...
if (something_failed()) goto error_handling;
...
}
}
}
return true;
error_handling:
...
return false;
to
$error_flag = false;
for (...) as outer_loop {
for (...) {
for (...) {
...
if (something_failed()) {
$error_flag = true;
break outer_loop;
}
...
}
}
}
if ($error_flag) {
...
return false;
}
return true;
as now there are all those extra $error_flag lines
and to see where the error condition is actually processed
i first have to search up from the 'break' to the outer_loop
definition, then down to the closing { of that loops body
and than further on to the place where $error_flag is
actually checked (if at all)
with "goto error_handling;" on the other hand i just have
to search for "error_handling:" and i'm at the error handling
code in one step (and the compiler can even guarantee that
the error_handling: label exists whereas a flag might actually
end up being ignored and an exception might get all the way
up the call stack without being called)
* state machine implementations
states get labels, state transitions goto labels -> pretty clean
right now you have to implement stuff like this as switch()
statements with an extra state variable being managed
this has the advantage of being able to tell which state you are
currently in and to have state transition logging in front of
the switch, but i experience it as less readable and it doesn't
perform as well as a GOTO based solution would as GOTOs can be
resolved at compile time while switch requires run time comparisons
--
Hartmut Holzgraefe, Senior Support Engineer.
MySQL AB, www.mysql.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Labeled Breaks (not the G-word)
Stanislav Malyshev wrote: HH>>a small objection here: with a GOTO it is clear where execution continues, HH>>you can simply search for the label the GOTO is using. With exceptions on It is clear from technical point. It is not clear from structural view, since it can be any random place in code, not connected to the previos place in any logical way. throw...catch can be as illogically connected just as well -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespaces: Technical proposal
Oliver Grätz wrote: Nope. Parentheses are a totally different thing here. Adding mandatory whitespace means giving syntactic meaning to something that normally never should have it. Meaningful whitespace is really evil. On the other side parentheses are already there. They are an existing concept of scoping evaluation. The idea simply consists of not having namespaces inside the ternary: while i agree that the () approach is less bad than the whitespace one it is still "bad enough" from an language orthogonally point of view ... -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Labeled Breaks (not the G-word)
Stanislav Malyshev wrote: Precentage of code that lies between throw point and catch point has nothing to do with anything. The structure of the code - that you always know which block encloses the code with exception potential and which code would handle the exception if it arises - has everything to do with it. one of the things we agreed upon from the very start (if i remember correctly) was that we are *not* going to have 'calculated' GOTOs, just constants are allowed as argument to GOTO so that it is perfectly clear where it jumps to with exceptions OTOH you can do silly stuff like $execptionName = $someObj->getRandomExeceptionName(); throw new $exceptionName; now where will that one be caught? dirty code? indeed ... but then it is perfectly legel, so lets ban "calculated" exceptions, too, as they obviously provide the potential for unmaintanable spaghettyish code ;) -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Labeled Breaks (not the G-word)
Stanislav Malyshev wrote: Exceptions are structured way of handling code flow - you can not get to random points of code with exception, you can get either to enclosing catch or stop the program entirely. Unlike exceptions, goto allows to jump to a random point of code. a small objection here: with a GOTO it is clear where execution continues, you can simply search for the label the GOTO is using. With exceptions on the other hand it is way harder to find out where it is actually going to be handled: could be the next catch() or not, even one in a different function or method upstream on the call stack, or maybe it isn't even caught at all but producing a runtime exception error instead ... so using goto and lables can actually be *more* clean ... I don't know what do you mean by "limited" - I see that the consensus among the goto proponents is to not impose any limits on the place you could jump to - because, of course, once you strated to jump around you always can find a use for jumping to any place, if you are creative enough - and I do not doubt creativity of PHP people. i think we all agreed ons *some* limits on GOTO that nobody ever put in question: - can only jump out of a block, not into - can not jump out of a function body (unlike exceptions) jumping back and forth instead of just forward is needed for state machine implementations, the alternatives (abusing switch(), having a seperate function for each state which are called by name ...) are way less clean if we are retricting GOTO to just jump forward we might be better off with named loops and labeled breaks just as in java, there is not much extra use in being able to place the labels anywhere you want then ... -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespaces: Technical proposal
Oliver Grätz wrote: Here's the idea: When the tokenizer encounters the opening "?" of the ternary, it DEACTIVATES the namespace operator until the end of the ternary. This way, all old code will behave as before, nothing will be broken. Of course, this absolutely requires the use of parentheses if one absolutely needs to use namespaces inside the ternary. As such cases will be pretty rare, this is no big drawback. The good thing: no whitespace magic is needed! this adds almost the same WTF? factor as requring whitespace, and being a pretty rare case only adds to this ... (not to mention that maintaining a parser with special state rules like this becomes a WTF? PITA anyway ...) -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Labeled Breaks (not the G-word)
Ilia Alshanetsky wrote: If it comes down to count of +1/-1 about this feature, I am +1 for unrestricted forward/backward jumps and -1 for restricted version. same here -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: namespace separator ideas
Jasper Bryant-Greene wrote: +1 for <- here. It makes namespace hierarchies resemble diagrams of the same hierarchies (like inheritance in UML). It also visually makes sense, isn't hard to type, and doesn't look like a smiley (like :> etc). wouldn't that create an amiguity with T_LESS_THAN T_UNARY_MINUS like in if (SOME_CONSTANT<-SOME_OTHER_CONSTANT) so that we are back to the same problem we alread have with ':'? -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.1 (Or How to break tousands of apps out there)
Sebastian Kugler wrote: Forcing the use of brackets (instead of whitespaces) only for places where you want to use namespace constants in ternaries is also impossible? exactly -- Hartmut Holzgraefe, Senior Support Engineer. MySQL AB, www.mysql.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] dropping curly braces
Derick Rethans wrote:
Don't you think it's useful to allow a convention like {} for strings and []
for arrays, so you can be sure what $str{1} means without looking at any
context?
No.
Derick
ok, next stop: "Operator Overloading"? ;)
--
Hartmut Holzgraefe, Senior Support Engineer.
MySQL AB, www.mysql.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] wishlist item for 6.0.0
Petar Nedyalkov wrote: proper scopes for global, classes and functions. will allow for local variables for functions and classes without having to use $this->foo in classes and will allow for a more c/c++ like classes. I think this will pollute the namespace a lot and may lead to spaghetti code problems. When reading C++ code it's usually rather hard to determine whether a given variable is a member of the class, one of its parent classes, the local context or something global. So i'm all for keeping the $this-> prefix even though it adds some extra typing ... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
