Hi Yasuo,
On Jul 4, 2013 5:54 AM, "Yasuo Ohgaki" wrote:
>
> Hi Anthony,
>
> 2013/7/3 Anthony Ferrara
>
> > 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 i
Hi Anthony,
2013/7/3 Anthony Ferrara
> 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 lef
> 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 Cal
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
On Wed, Jul 3, 2013 at 11:10 PM, Sanford Whiteman
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 'sequentialBefo
> 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 'sequentialBef
On Wed, Jul 3, 2013 at 10:01 PM, Chris London 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
> Forea
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
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 c
> 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 ev
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
> 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
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 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.
Wh
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 exe
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 introdu
2013/7/3 Remi Collet :
> -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_dr
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 t
On Jul 3, 2013 4:12 PM, "Anthony Ferrara" 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
-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
> 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
Le 04/06/2013 05:02, Stanley Sufficool a écrit :
> Commit:5a04ab9a54f529f4197bed6f17599604266cdb35
> Author:Stanley Sufficool Mon, 3 Jun 2013
> 20:02:08 -0700
> Parents: 7360f0f1e6c4b49e89bd3c2cf1f524e9cf7f9dcc
> Branches: PHP-5.4
>
> Link:
> http://git.php.net/?p=php-s
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? ;-)
>
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 Bergmann
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 time
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_i
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 class
27 matches
Mail list logo
