[PHP-DEV] New feature: sequential constructors
Hello, all. On one or two occasions I've encountered a problem when designing a base class, where I wish to implement important set-up functionality in the constructor, but am limited in how to ensure that the base constructor functionality is unmolested whilst not restricting any inheriting classes in their use of a constructor, as would be the case when using the final keyword. I also don't feel 100% comfortable trusting the inheriting class to call the parent constructor. The idea I'm presenting for discussion here is to have some kind of (keyword-driven?) hierarchy for constructors, whereby it's possible to have for example sequential constructors, using syntax similar to: ... public sequential function __construct($ ... In this scenario, constructors defined as sequential are, as the name implies, called in sequence. If the introduction of a new keyword is problematic, perhaps this same behaviour could be enacted in cases where an inheriting class has a constructor and the base class' constructor is defined as final i.e. rather than causing an error, the final constructor is executed first, followed by any other constructors in the hierarchy. If this keyword is introduced, perhaps it this idea could also be expanded to allow for sequential methods in general, which would behave similarly - and may be a gateway to function overloading (or similar behaviour). I'm open to people pointing out design flaws/implementation difficulties with this; pull no punches. Thanks.
Re: [PHP-DEV] New feature: sequential constructors
For what it's worth, some time ago I prototyped something like that, without
modifying the language, in the form of a Universal class that you may
inherit from without defining __contruct/__destruct yourself.
See class definition below. In a using class (herarchy) define static methods
_pre_init, _post_init, _pre_exit and _post_exit. They will receive the
instance as their sole argument. __construct first calls _pre_init up the
inheritance chain, then _post_init on the way back down; likewise __destruct
calls _pre_exit and _post_exit
In the current form it is only moderately useful, because it doesn't support
constructor arguments. These throw up the question of how to pass them to the
sequential constructors, and what these would then usefully be able to do
with them...
best regards
Patrick
class Universal {
static private $_universal_pre_inits = [];
static private $_universal_post_inits = [];
static private $_universal_pre_exits = [];
static private $_universal_post_exits = [];
public function __construct() {
$class = get_class($this);
$initclass = $class.'°universal_init';
if (!class_exists($initclass, false))
Universal::_universal_inits_and_exits($class);
$initclass::_universal_init($this);
}
public function __destruct() {
$initclass = get_class($this).'°universal_init';
$initclass::_universal_exit($this);
}
final protected function _universal_inits_and_exits($class) {
$pre_inits = [];
$post_inits = [];
$pre_exits = [];
$post_exits = [];
$c = new ReflectionClass($class);
try {
$m = $c-getMethod('_pre_init');
if ($m-class == $class)
$pre_inits[] = [ $class, '_pre_init' ];
$m = $c-getMethod('_pre_exit');
if ($m-class == $class)
$pre_exits[] = [ $class, '_pre_exit' ];
} catch (Exception $e) {};
$parent = get_parent_class($class);
if ($parent $parent != 'Universal') {
if (!class_exists($parent.'°universal_init', false))
Universal::_universal_inits_and_exits($parent);
$pre_inits = array_merge($pre_inits, self::
$_universal_pre_inits[$parent]);
$pre_exits = array_merge($pre_exits, self::
$_universal_pre_exits[$parent]);
$post_inits = array_merge($post_inits, self::
$_universal_post_inits[$parent]);
$post_exits = array_merge($post_exits, self::
$_universal_post_exits[$parent]);
}
try {
$m = $c-getMethod('_post_init');
if ($m-class == $class)
$post_inits[] = [ $class, '_post_init' ];
$m = $c-getMethod('_post_exit');
if ($m-class == $class)
$post_exits[] = [ $class, '_post_exit' ];
} catch (Exception $e) {};
self::$_universal_pre_inits[$class] = $pre_inits;
self::$_universal_pre_exits[$class] = $pre_exits;
self::$_universal_post_inits[$class] = $post_inits;
self::$_universal_post_exits[$class] = $post_exits;
$code = class {$class}°universal_init extends {$class}{;
$code .= 'static protected function _universal_init($o){';
foreach (array_merge($pre_inits, $post_inits) as $init)
$code .= {$init[0]}::{$init[1]}(\$o);;
$code .= '} static protected function _universal_exit($o){';
foreach (array_merge($pre_exits, $post_exits) as $exit)
$code .= {$exit[0]}::{$exit[1]}(\$o);;
$code .= '}}';
eval($code);
}
}
On Wednesday 03 July 2013 13:45:57 Terence Copestake wrote:
Hello, all.
On one or two occasions I've encountered a problem when designing a base
class, where I wish to implement important set-up functionality in the
constructor, but am limited in how to ensure that the base constructor
functionality is unmolested whilst not restricting any inheriting classes
in their use of a constructor, as would be the case when using the final
keyword. I also don't feel 100% comfortable trusting the inheriting class
to call the parent constructor.
The idea I'm presenting for discussion here is to have some kind of
(keyword-driven?) hierarchy for constructors, whereby it's possible to have
for example sequential constructors, using syntax similar to:
... public sequential function __construct($ ...
In this scenario,
[PHP-DEV] String Size Refactor Progress
Hey all, So I've started the refactor to change the stored string size from int to size_t. I've got it compiling and the tests mostly passing (not all), when run with --disable-all and --disable-cgi. There are definitely still issues with the patch (there are some weird segfaults in certain times, which are caught by the tests), but it's progressing really nicely. Here's what I did: I created a new build option: --enable-zstrlen. This turns off the new match, and type-defs and defines everything back to how it was before. This is really useful for testing changes to ensure that they still work. Then, I defined a series of new types: #ifdef ZEND_USE_LEGACY_STRING_TYPES #define zend_str_size_int int #define zend_str_size_uint unsigned int #define zend_str_size_size_t size_t #define zend_str_size_long long typedef int zend_str_size; #else #define zend_str_size_int zend_str_size #define zend_str_size_uint zend_str_size #define zend_str_size_size_t zend_str_size #define zend_str_size_long zend_str_size typedef size_t zend_str_size; #endif Any API that accepted a string size parameter, I replace with one of the zend_str_size_* definitions. I chose to do this instead of just changing it directly to zend_str_size, as it should make extension developer's lives easier by supporting the intermediate types (with their own define lines for older versions of the API). These are intended to be removed after 1 or 2 releases, replacing everything with just zend_str_size. Due to a problem with zend_parse_parameters, I added two new identifiers: S and P. They act just like s and p, except that they return zend_str_size instead of int. When `--enable-zstrlen` is not enabled, I disable s and p, and changed ZPP to rase an E_ERROR on unknown parameter types. The E_ERROR change is not intended to go into production, but instead just makes life A LOT easier refactoring modules one at a time. Here's what's left to do: I've only really got the basic system working (for limited definitions of working). There's a ton of extensions that need migrating, and tons of parts of the core that i haven't fully migrated yet. I've migrated php_pcre.c over, but pcrelib still uses int for string sizes. This is going to be a much larger refactor, and I wanted to see people's thoughts prior to digging into it. Substr needs to be refactored to use size_t. Right now, I just raise an error if Z_STRSIZE INT_MAX (or an overflow would happen). I'd love to see that cleaned up more. My general process has been to enable an extension, fix the compile errors (typically due to removing Z_STRLEN*). Then run through the extension, searching for int and replacing where appropriate with zend_str_size (within a function) or zend_str_size_* in an API. Then run the tests for that extension, and fix the issues as they come up. Finally, recompile with -Werror and fix all of the warnings (yay!)... Lessons Learned So Far How this system is working today, I have no idea. There are SOOO many issues in string handling just due to types. I've seen int, unsigned int, size_t, long, unsigned long and others, silently cast back and forth (implicit casts too). Some really weird things going on... Here's the branch: https://github.com/ircmaxell/php-src/tree/string_size_refactor_take_2 And the diff: https://github.com/ircmaxell/php-src/compare/string_size_refactor_take_2 If you want to help out, please let me know and let's try to coordinate so we don't step on each other's toes... Thanks! Anthony
[PHP-DEV] Re: [PHP-CVS] com php-src: Add bison 2.6.4 to the list of supported versions: Zend/acinclude.m4
Am 03.07.2013 17:00, schrieb Johannes Schlüter: Additionally I got merge conflicts due to this while merging 5.4 into 5.5, please verify the result there. Don't trust me that I verified my changes before committing? ;-) PHP-5.5 already had the changes. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Add bison 2.6.4 to the list of supported versions: Zend/acinclude.m4
On Wed, 2013-07-03 at 17:12 +0200, Sebastian Bergmann wrote: Am 03.07.2013 17:00, schrieb Johannes Schlüter: Additionally I got merge conflicts due to this while merging 5.4 into 5.5, please verify the result there. Don't trust me that I verified my changes before committing? ;-) PHP-5.5 already had the changes. Still one has to merge the commit up to create a proper history - now I had a merge conflict while merging another change and had to figure out what the correct version of that file might be. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: Fix PDO_DBLIB bugs - FreeTDS dependency
Le 04/06/2013 05:02, Stanley Sufficool a écrit : Commit:5a04ab9a54f529f4197bed6f17599604266cdb35 Author:Stanley Sufficool ssuffic...@php.net Mon, 3 Jun 2013 20:02:08 -0700 Parents: 7360f0f1e6c4b49e89bd3c2cf1f524e9cf7f9dcc Branches: PHP-5.4 Link: http://git.php.net/?p=php-src.git;a=commitdiff;h=5a04ab9a54f529f4197bed6f17599604266cdb35 Log: Fix PDO_DBLIB bugs: #64338, #64808, #63638 Note: this change raises dependency on freetds 0.91 (don't build with previous and old 0.82) Probably not a big issue. Need to be known. Remi P.S sorry to have not detect this earlier (but I don't build RC for all possible targets...) /builddir/build/BUILD/php-5.4.17/ext/pdo_dblib/dblib_driver.c: In function 'dblib_handle_quoter': /builddir/build/BUILD/php-5.4.17/ext/pdo_dblib/dblib_driver.c:146: warning: unused variable 'H' /builddir/build/BUILD/php-5.4.17/ext/pdo_dblib/dblib_driver.c: In function 'pdo_dblib_transaction_cmd': /builddir/build/BUILD/php-5.4.17/ext/pdo_dblib/dblib_driver.c:175: warning: unused variable 'ret' /builddir/build/BUILD/php-5.4.17/ext/pdo_dblib/dblib_driver.c: In function 'pdo_dblib_handle_factory': /builddir/build/BUILD/php-5.4.17/ext/pdo_dblib/dblib_driver.c:277: error: 'DBVERSION_71' undeclared (first use in this function) /builddir/build/BUILD/php-5.4.17/ext/pdo_dblib/dblib_driver.c:277: error: (Each undeclared identifier is reported only once /builddir/build/BUILD/php-5.4.17/ext/pdo_dblib/dblib_driver.c:277: error: for each function it appears in.) /builddir/build/BUILD/php-5.4.17/ext/pdo_dblib/dblib_driver.c:278: error: 'DBVERSION_72' undeclared (first use in this function) /builddir/build/BUILD/php-5.4.17/ext/pdo_dblib/dblib_driver.c:365: warning: implicit declaration of function 'DBSETLDBNAME' /builddir/build/BUILD/php-5.4.17/ext/pdo_dblib/dblib_driver.c:269: warning: unused variable 'val' -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Fix PDO_DBLIB bugs - FreeTDS dependency
Remi P.S sorry to have not detect this earlier (but I don't build RC for all possible targets...) /builddir/build/BUILD/php-5.4.17/ext/pdo_dblib/dblib_driver.c: In I could set up an obs project for rhel, fedora and a service to build on each master commit etc... I just don't have enough insight to see what it means when it doesn't build ;) -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Fix PDO_DBLIB bugs - FreeTDS dependency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 03/07/2013 19:17, Ralf Lang a écrit : Remi P.S sorry to have not detect this earlier (but I don't build RC for all possible targets...) /builddir/build/BUILD/php-5.4.17/ext/pdo_dblib/dblib_driver.c: In I could set up an obs project for rhel, fedora and a service to build on each master commit etc... I just don't have enough insight to see what it means when it doesn't build ;) It's not a problem for Fedora, as all maintained version have freetds-0.91. It's not a problem for RHEL as php-mssql not provided (and EPEL also have freetds-0.91). Remi. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHUXlkACgkQYUppBSnxahhWuwCgkH+mFuqpzFnrm97IGLmzsKP2 R3sAoLTZFzUfpEYIHoCnh+MfSmSFBWuJ =iyUp -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] String Size Refactor Progress
On Jul 3, 2013 4:12 PM, Anthony Ferrara ircmax...@gmail.com wrote: If you want to help out, please let me know and let's try to coordinate so we don't step on each other's toes... I'm with you from August 1st, at the latest! Thanks! Anthony
Re: [PHP-DEV] I want to work against Bug 44522 - Upload limit 2G
On 28.06.2013 08:45, Ralf Lang wrote: On 27.06.2013 18:52, Christopher Jones wrote: On 06/27/2013 09:33 AM, Ralf Lang wrote: Anyway, I have built a version of the patch (using unsigned long instead of signed long as the original did) against old php 5.3.8 and currently a test is running with a 4.7 GiB DVD Image. If it works well, I will submit the patch and attach it to the bug record. Thank you for your response. To make it more reviewable, can you base the patch on the master branch (aka PHP 5.6)? If you're a github user, a PR would be great. Done that. https://github.com/php/php-src/pull/372 Did you review all the previous mail list discussion about the patch? IIRC there were a bunch of reasons it never got merged. I read the bug report discussion, stas' mails and what I found in the archives. I might have missed information though. Any additional action required from my side or is it just waiting for a review timeslot? -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Fix PDO_DBLIB bugs - FreeTDS dependency
2013/7/3 Remi Collet r...@fedoraproject.org: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 03/07/2013 19:17, Ralf Lang a écrit : Remi P.S sorry to have not detect this earlier (but I don't build RC for all possible targets...) /builddir/build/BUILD/php-5.4.17/ext/pdo_dblib/dblib_driver.c: In I could set up an obs project for rhel, fedora and a service to build on each master commit etc... I just don't have enough insight to see what it means when it doesn't build ;) It's not a problem for Fedora, as all maintained version have freetds-0.91. It's not a problem for RHEL as php-mssql not provided (and EPEL also have freetds-0.91). Remi. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHUXlkACgkQYUppBSnxahhWuwCgkH+mFuqpzFnrm97IGLmzsKP2 R3sAoLTZFzUfpEYIHoCnh+MfSmSFBWuJ =iyUp -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I've pushed a build fix. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New feature: sequential constructors
I suggest you read this recent thread for related commentary. http://www.serverphorums.com/read.php?7,71 In there, I refer to your proposal as Contractual Call Super and I find it an interesting concept that helps avoid the advisory call super antipattern. However -- If the introduction of a new keyword is problematic, perhaps this same behaviour could be enacted in cases where an inheriting class has a constructor and the base class' constructor is defined as final i.e. rather than causing an error, the final constructor is executed first, followed by any other constructors in the hierarchy. -- this is a horrible idea. `final` has distinct semantic meaning. It means cannot override. It doesn't mean overrideable, but we'll call any/all supers before/after we run yours. It's a BC break. Fuggedaboutit. The feature you want isn't in the language -- maybe it should be -- and you can't change the meaning of existing keywords. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New feature: sequential constructors
On 03.07.2013 20:05, Sanford Whiteman wrote: a new keyword is problematic, perhaps this same behaviour could be enacted in cases where an inheriting class has a constructor and the base class' constructor is defined as final i.e. rather than causing an error, the final constructor is executed first, followed by Most often if I need a super __construct(), I don't need it exactly before or exactly after the bottom constructor but at a specific point where I can setup super's input data and do stuff to its output. What is the typical use case for calling all supers (before or after the class' __construct itself) ? -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] String Size Refactor Progress
On 07/03/2013 07:12 AM, Anthony Ferrara wrote: Then, I defined a series of new types: #ifdef ZEND_USE_LEGACY_STRING_TYPES Due to a problem with zend_parse_parameters, I added two new identifiers: S and P. They act just like s and p, except that they return zend_str_size instead of int. When `--enable-zstrlen` is not enabled, I disable s and p, and changed ZPP to rase an E_ERROR on unknown parameter types. The E_ERROR change is not intended to go into production, but instead just makes life A LOT easier refactoring modules one at a time. Can you elaborate on the problem? Ideally the return type of s p would be toggled by ZEND_USE_LEGACY_STRING_TYPES. Chris -- christopher.jo...@oracle.com http://twitter.com/ghrd Free PHP Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] String Size Refactor Progress
Chris, When `--enable-zstrlen` is not enabled, I disable s and p, and changed ZPP to rase an E_ERROR on unknown parameter types. The E_ERROR change is not intended to go into production, but instead just makes life A LOT easier refactoring modules one at a time. Can you elaborate on the problem? Ideally the return type of s p would be toggled by ZEND_USE_LEGACY_STRING_TYPES The problem is that changing 's' from int to size_t can (and does) cause segfaults. We can have the discussion if 's' and 'p' should remain there (and if the compile time option should be there) at merge time, but for now the switch just makes life easier making the change. It wasn't designed for a long-term switch... Anthony
Re: [PHP-DEV] New feature: sequential constructors
Most often if I need a super __construct(), I don't need it exactly
before or exactly after the bottom constructor but at a specific point
where I can setup super's input data and do stuff to its output.
I've most often seen, or reluctantly implemented, the Call Super
antipattern by putting the call at the bottom of sub code.
It's true that it's an antipattern regardless of advisory placement.
But to me, somewhere-in-the-middle is even smellier than usual, since
in human hands that's got to be more prone to failure.
I think if Contractual Call Super were considered for the language it
should have before and after variants, not just after. There isn't a
practical way to declare at some point, is there, even if you wanted
it?
What is the typical use case for calling all supers (before or after the
class' __construct itself) ?
I can't think of a valid case in my memory for _all_ supers. Typically
you mean to call the immediate super _or_ the root super. Which is of
course the problem with the advisory form of this pattern, since
innocently inserting an intermediate class breaks your code.
If this feature were introduced, I see no reason for it to be allowed
to call more than one method for each occurrence of 'sequential'
keyword.
That is,
class A { sequentialBefore function __construct() {} }
class Asub extends A { function __construct() {} }
class Asubsub extends Asub { function __construct() {} }
would run A::__construct and then Asubsub::construct()
class A { sequentialBefore function __construct() {} }
class Asub extends A { sequentialBefore function __construct() {} }
class Asubsub extends Asub { function __construct() {} }
would run A::__construct, Asub::__construct, Asubsub::__construct
class A { sequentialBefore function __construct() {} }
class Asub extends A { sequentialAfter function __construct() {} }
class Asubsub extends Asub { function __construct() {} }
would run A::__construct, Asubsub::construct(), Asub::__construct
I'm not particularly cheering for this feature but enjoy thinking
about how it might work. If you see my notes on the previous thread
you can see I'm pretty adamant about Call Super being very bad
_unless_ it's baked into the language in an interesting way.
-- S.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New feature: sequential constructors
On 03.07.2013 20:48, Sanford Whiteman wrote:
Most often if I need a super __construct(), I don't need it exactly
before or exactly after the bottom constructor but at a specific point
where I can setup super's input data and do stuff to its output.
I've most often seen, or reluctantly implemented, the Call Super
antipattern by putting the call at the bottom of sub code.
It's true that it's an antipattern regardless of advisory placement.
But to me, somewhere-in-the-middle is even smellier than usual, since
in human hands that's got to be more prone to failure.
I think if Contractual Call Super were considered for the language it
should have before and after variants, not just after. There isn't a
practical way to declare at some point, is there, even if you wanted
it?
No, that's why I am asking. Why is it an anti-pattern to call a known
super constructor? Not knowing the implementation details, I still know
the documented api (which is all a class should ask for).
What is the typical use case for calling all supers (before or after the
class' __construct itself) ?
I can't think of a valid case in my memory for _all_ supers. Typically
you mean to call the immediate super _or_ the root super. Which is of
course the problem with the advisory form of this pattern, since
innocently inserting an intermediate class breaks your code.
This makes it more complicated. Do you mean next super or root super (or
root-1 as any class object is an object ?
I don't mean to disrupt any ideas. I just think how I would use or
expect to use the feature.
If this feature were introduced, I see no reason for it to be allowed
to call more than one method for each occurrence of 'sequential'
keyword.
That is,
class A { sequentialBefore function __construct() {} }
class Asub extends A { function __construct() {} }
class Asubsub extends Asub { function __construct() {} }
would run A::__construct and then Asubsub::construct()
class A { sequentialBefore function __construct() {} }
class Asub extends A { sequentialBefore function __construct() {} }
class Asubsub extends Asub { function __construct() {} }
would run A::__construct, Asub::__construct, Asubsub::__construct
class A { sequentialBefore function __construct() {} }
class Asub extends A { sequentialAfter function __construct() {} }
class Asubsub extends Asub { function __construct() {} }
would run A::__construct, Asubsub::construct(), Asub::__construct
I'm not particularly cheering for this feature but enjoy thinking
about how it might work. If you see my notes on the previous thread
you can see I'm pretty adamant about Call Super being very bad
_unless_ it's baked into the language in an interesting way.
Not that it would be an argument but just for understanding: Do you know
any scripting language which has this? This would help me seeing the
idea as I know some of them.
--
Ralf Lang
Linux Consultant / Developer
Mail: l...@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] New feature: sequential constructors
No, that's why I am asking. Why is it an anti-pattern to call a known super constructor? Guess I'd send you to my comments in the earlier thread as I think I exhausted my ability to dismantle (advisory a..k.a. pretty please) Call Super there. Or ?call super antipattern. Of course, most every antipattern began as a brand name for a common approach, then once it graduated to a non-judgmental recommendation the backlash began. The cynic in me knows that some patterns are declared anti- so they can make developers feel cool about their code even if it works no more efficiently, is no better documented, and is only negligibly more manageable than uncool stuff. Nevertheless I find the arguments against Call Super compelling even in a closed environment where you control your own API. YMMV... -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] New feature: additional syntax proposal for Foreach
Hello community,
This is my first post here. I hope to improve my participation in the
community and give back to the technology that has done so much for my
career. My first attempt is to propose an additional syntax for the
Foreach statement.
Background:
There are times in our code where we can leave things blank that we don't
need, such as:
for ( ; ; ) {
}
- and -
list( , $foo, $bar) = array('ignore', 'myFoo', 'myBar');
Proposal:
I have found over the years that there are times when I want to loop
through an associative array but I don't need the value. I would like to
allow the following syntax:
foreach ($array as $key = ) {
}
Please let me know your thoughts.
Thanks
Chris London
Re: [PHP-DEV] New feature: additional syntax proposal for Foreach
Welcome Chris,
As a `plain` user of PHP, i'd like to advocate not to allow anymore
aliasing of ways to do stuff...
Your example should just read foreach(array_keys($array) as $key) {} That's
the only way to convey the actual intent of working with keys and
explicitly leaving out the values ;)
But hey, just my 2c...
Met vriendelijke groet,
Robin Speekenbrink
Kingsquare BV
2013/7/3 Chris London m...@chrislondon.co
Hello community,
This is my first post here. I hope to improve my participation in the
community and give back to the technology that has done so much for my
career. My first attempt is to propose an additional syntax for the
Foreach statement.
Background:
There are times in our code where we can leave things blank that we don't
need, such as:
for ( ; ; ) {
}
- and -
list( , $foo, $bar) = array('ignore', 'myFoo', 'myBar');
Proposal:
I have found over the years that there are times when I want to loop
through an associative array but I don't need the value. I would like to
allow the following syntax:
foreach ($array as $key = ) {
}
Please let me know your thoughts.
Thanks
Chris London
Re: [PHP-DEV] New feature: additional syntax proposal for Foreach
On Wed, Jul 3, 2013 at 10:01 PM, Chris London m...@chrislondon.co wrote:
Hello community,
This is my first post here. I hope to improve my participation in the
community and give back to the technology that has done so much for my
career. My first attempt is to propose an additional syntax for the
Foreach statement.
Background:
There are times in our code where we can leave things blank that we don't
need, such as:
for ( ; ; ) {
}
- and -
list( , $foo, $bar) = array('ignore', 'myFoo', 'myBar');
Proposal:
I have found over the years that there are times when I want to loop
through an associative array but I don't need the value. I would like to
allow the following syntax:
foreach ($array as $key = ) {
}
Please let me know your thoughts.
Thanks
Chris London
While it does sometimes happen that you do not need the value, it's not
particularly common and as such I don't think it's necessary to add
additional syntax for this case. It's fairly straightforward to abstract
this behavior away into a separate function used as follows:
foreach (keys($iterable) as $key) { ... }
Where the keys function is defined as:
function keys($iterable) {
foreach ($iterable as $key = $_) {
yield $key;
}
}
This is something you write once (with the slightly ugly $key = $_), but
can then always use to have clear code :) Of course, as already said in the
other mail, for arrays the keys() function already exists as array_keys(),
so you don't even have to write anything yourself.
Nikita
Re: [PHP-DEV] New feature: sequential constructors
Not that it would be an argument but just for understanding: Do you know any scripting language which has this? Dropping the scripting part... IIRC, C++ calls ctors without arguments automatically like in my 'sequentialBefore' napkin sketch. C# has language-level support for 'sequentialBefore' type logic in its initialization list as well (which helps to smooth away the anti-ness by keeping it out of the ctor code). Also, here's a fascinatingly stupid bug-as-feature in AS3 (which I don't remember anything about, having used it basically procedurally along time ago) http://blogs.adobe.com/cantrell/archives/2008/09/be_careful_how.html. (Call Super hoisting out of conditionals? How could that have seemed like a good idea?) So there is precedent for Contractual Call Super. I don't think the above implementations are ideal, though, so if someone did go down this path I think it should be (a) not automatic but dependent on keyword(s); (b) flexible as far as executing before/after; (c) deeply-thought-through as far as its impact on class hierarchies that expand and contract over time. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New feature: sequential constructors
On Wed, Jul 3, 2013 at 11:10 PM, Sanford Whiteman swhitemanlistens-softw...@cypressintegrated.com wrote: Not that it would be an argument but just for understanding: Do you know any scripting language which has this? Dropping the scripting part... IIRC, C++ calls ctors without arguments automatically like in my 'sequentialBefore' napkin sketch. C# has language-level support for 'sequentialBefore' type logic in its initialization list as well (which helps to smooth away the anti-ness by keeping it out of the ctor code). Also, here's a fascinatingly stupid bug-as-feature in AS3 (which I don't remember anything about, having used it basically procedurally along time ago) http://blogs.adobe.com/cantrell/archives/2008/09/be_careful_how.html. (Call Super hoisting out of conditionals? How could that have seemed like a good idea?) So there is precedent for Contractual Call Super. I don't think the above implementations are ideal, though, so if someone did go down this path I think it should be (a) not automatic but dependent on keyword(s); (b) flexible as far as executing before/after; (c) deeply-thought-through as far as its impact on class hierarchies that expand and contract over time. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hello, I've been thinking about this for a bit and even if you are right about being nice to have a way to call a function always after constructor. It could happen. You could have a DB class and in constructor the user/pass/host/options and then a separate method for init(). But more often than not, I want to be able to dictate what the program is doing when I'm using libraries and so on that I'm extending, not the libraries do stuff on their own. In most of the cases, I know much better that the library author how I want to use the library for my use case. In your case, if you want to have a method always called then just document it properly. Except for cases when you don't have access to the source code, encrypted maybe?, I really don't see why just documenting this isn't enough. Think for a moment on the reverse of this: you have this nice feature in the language, but then the people start abusing it. Could you imagine yourself trying to use the latest XGreatLib v3.0 but you want to skip some constructor due the fact that you know better. What do you do then? And yeah, maybe the library authors are not that careless to use such an abusive functionality, but what if you have this in your code and you decide to remove the new keyword 'super' or whatever so that you can skip that constructor? Could it be that you just broke your whole app because of this? Please think of the downsides as well when thinking of new features like this, the implications for the whole eco-system could be huge for just wanting to skip some proper documentation. Cheers. Florin Patan https://github.com/dlsniper http://www.linkedin.com/in/florinpatan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] String Size Refactor Progress
Hi! The problem is that changing 's' from int to size_t can (and does) cause segfaults. But if we refactor string lengths to be size_t, we can not allow code that still relies on it being int, if sizeof(size_t) != sizeof(int). It would just produce wrong length. I'd actually prefer segfault there at least for testing phase because segfault is obvious while wrong length would be much harder to catch. We can have the discussion if 's' and 'p' should remain there (and if the compile time option should be there) at merge time, but for now the switch just makes life easier making the change. It wasn't designed for a long-term switch... OK, if it's a temp measure, that's fine, but if we're taking strings to use size_t, then in the final code it should use size_t in the API functions everywhere, otherwise there would be a lot of weird bugs. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New feature: sequential constructors
I've been thinking about this for a bit and even if you are right about being nice to have a way to call a function always after constructor. It could happen. You could have a DB class and in constructor the user/pass/host/options and then a separate method for init(). But that's not Call Super. Call Super specifically refers to always calling an overridden method of the same name (and usually same signature in languages supporting overloading) in a base class (usually the closest parent). Let's not mix up concepts: the relationship between methods of the same name in the a class hierarchy has specific semantic baggage, if not a single agreed-upon meaning, thus how some people say you should always be able to call super while others say you should never just assume you can call super *and* should never author an API that requires it and still others say you can't assume, but the requirement happens, and when it is required the language should be able to enforce the requirement. But more often than not, I want to be able to dictate what the program is doing when I'm using libraries and so on that I'm extending, not the libraries do stuff on their own. The question regarding Call Super isn't about libraries doing stuff on their own vs. stuff you dictate. It's about doing stuff on their own vs. dictating that you remember to do stuff for bug-free operation, being unable to do that stuff on their own. Languages that have Call Super as a flexible, baked-in language feature are able to contractually ensure Call Super _if a superclass author chooses to use the pattern_. Doesn't mean you have to use it, but it means you don't have to cross your fingers if you do use it. (In the case of C++, you're always using the pattern if you have a base ctor.) Languages that don't support Call Super still have to support code using the pattern in the real world, because not every user will use the alternative Template Method due to seeming complexity (even if TM is less prone to error). But those languages won't offer any way of catching omissions in a subclass. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] String Size Refactor Progress
Hi Anthony, 2013/7/3 Anthony Ferrara ircmax...@gmail.com I've migrated php_pcre.c over, but pcrelib still uses int for string sizes. This is going to be a much larger refactor, and I wanted to see people's thoughts prior to digging into it. For upgradability and compatibility, bundled pcrelib should be left as it is. Instead, checking possible over/under flow before passes string is better. Most pre-complied systems use system's preclib, I suppose. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] String Size Refactor Progress
Hi Yasuo, On Jul 4, 2013 5:54 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Anthony, 2013/7/3 Anthony Ferrara ircmax...@gmail.com I've migrated php_pcre.c over, but pcrelib still uses int for string sizes. This is going to be a much larger refactor, and I wanted to see people's thoughts prior to digging into it. For upgradability and compatibility, bundled pcrelib should be left as it is. Instead, checking possible over/under flow before passes string is better. Or ask pcre to use size_t as well for their next major version. Cheers, Pierre
