On Thu, 3 Jul 2008, Pierre Joye wrote:
On Thu, Jul 3, 2008 at 4:23 PM, Derick Rethans [EMAIL PROTECTED] wrote:
On Thu, 3 Jul 2008, Pierre-Alain Joye wrote:
pajoyeThu Jul 3 13:50:15 2008 UTC
Modified files: (Branch: PHP_5_3)
/php-src/ext/mcrypt
Hi Travis,
Am Donnerstag, den 03.07.2008, 16:31 -0500 schrieb Travis Swicegood:
* Completely bike shedding, but does Recursive need its own level?
RecursiveArray reads better than having Array at two different levels
to me.
Alright, I will change that.
* Again, bike shedding, but I like
Can anybody review my patches? I need to commit the patches and want
to work on 5.3 and 6.0.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Sorry for delay. Here is the revised patches.
I marged pg_lo_import_with_oid() into pg_lo_import().
--
Tatsuo Ishii
SRA OSS, Inc. Japan
On 17.04.2008 18:50,
On Thu, 3 Jul 2008, Lars Strojny wrote:
RFC: http://wiki.php.net/rfc/namespaces-for-internal-classes
I'd say this is a BIG no-no. PHP owns the top-level namespace. Why make
things harder? And on top of that, you're suggesting just to break code
for no good reason in Backwards compatibility
Hi Derick,
Am Freitag, den 04.07.2008, 10:14 +0200 schrieb Derick Rethans:
I'd say this is a BIG no-no. PHP owns the top-level namespace. Why
make things harder? And on top of that, you're suggesting just to
break code for no good reason in Backwards compatibility and other
constraints.
Hi Derick,
On Fri, Jul 4, 2008 at 9:47 AM, Derick Rethans [EMAIL PROTECTED] wrote:
I see no reason to revert this commit now, why do you want me to
revert it except for making my work harder?
Never mind, I did it myself. Don't commit to ext/mcrypt.
It is not acceptable to have one person
On Fri, Jul 4, 2008 at 11:53 AM, Lars Strojny [EMAIL PROTECTED] wrote:
Am Donnerstag, den 03.07.2008, 16:31 -0500 schrieb Travis Swicegood:
* Completely bike shedding, but does Recursive need its own level?
RecursiveArray reads better than having Array at two different levels
to me.
Pierre,
I committed - several months ago - a generic 'probe' function that worked
perfectly for any binary.
Will you PLEASE openly discuss any changes to the core build system before
committing them in future?
Thanks,
- Steph
- Original Message -
From: Pierre-Alain Joye [EMAIL
On Fri, Jul 4, 2008 at 10:44 AM, Steph Fox [EMAIL PROTECTED] wrote:
Pierre,
I committed - several months ago - a generic 'probe' function that worked
perfectly for any binary.
Which branch did you use? The changes were only about syncing HEAD and 5.3.
--
Pierre
http://blog.thepimp.net |
I committed - several months ago - a generic 'probe' function that worked
perfectly for any binary.
Which branch did you use? The changes were only about syncing HEAD and
5.3.
5.3. I have a bunch of stuff here for merging to HEAD. Which I now have to
go through (again).
- Steph
--
On Fri, 2008-07-04 at 10:28 +0200, Lars Strojny wrote:
Hi Derick,
Am Freitag, den 04.07.2008, 10:14 +0200 schrieb Derick Rethans:
I'd say this is a BIG no-no. PHP owns the top-level namespace. Why
make things harder? And on top of that, you're suggesting just to
break code for no good
Hi,
On Thu, 2008-07-03 at 22:30 +0400, Dmitry Stogov wrote:
I don't see big problems with closures. The patch is simple and
stable.
It's main part isolated in zend_closures.c and it doesn't affect other
parts of engine.
Changes too the languages always introduce some side effects and
Hi Johannes,
Am Freitag, den 04.07.2008, 11:15 +0200 schrieb Johannes Schlüter:
[...]
That's not entirely true, there are minor BC breaks: Let's say Bar is an
alias for Foo::Bar. now to $r = new ReflectionClass('Bar'); echo
$r-getName(); and you'll get 'Foo::Bar' as that's the name in the CE,
On Fri, Jul 4, 2008 at 11:15 AM, Steph Fox [EMAIL PROTECTED] wrote:
I committed - several months ago - a generic 'probe' function that worked
perfectly for any binary.
Which branch did you use? The changes were only about syncing HEAD and
5.3.
5.3. I have a bunch of stuff here for merging
Hi Johannes,
Am Freitag, den 04.07.2008, 11:18 +0200 schrieb Johannes Schlüter:
Now such a check isn't possible, all reflection information on the
callback I can get is that it is an object of type Closure having a
method __invoke() with zero required parameters. There's no further
There is not much left. That's what my last commits did. The only
difference I can catch are about rd instead of rmdir and the
zend-multibyte configure option. The ICU macros will be backported as
soon as intl made its way to php-src.
OK, but the *reason* I made a generic function was to
Hello
I'm using vc 2008. i want to import the PHP core project into VC 2008.
who can help me ?
_
Invite your mail contacts to join your friends list with Windows Live Spaces.
It's easy!
On Fri, Jul 4, 2008 at 11:35 AM, Steph Fox [EMAIL PROTECTED] wrote:
There is not much left. That's what my last commits did. The only
difference I can catch are about rd instead of rmdir and the
zend-multibyte configure option. The ICU macros will be backported as
soon as intl made its way to
hi,
On Fri, Jul 4, 2008 at 11:37 AM, Ismaeel Abu Amsha [EMAIL PROTECTED] wrote:
Hello
I'm using vc 2008. i want to import the PHP core project into VC 2008.
who can help me ?
You can't import the src in Visual C, but you can compile PHP using
(any) VC. Take a look here:
On Fri, 2008-07-04 at 11:31 +0200, Lars Strojny wrote:
Hi Johannes,
Am Freitag, den 04.07.2008, 11:18 +0200 schrieb Johannes Schlüter:
Now such a check isn't possible, all reflection information on the
callback I can get is that it is an object of type Closure having a
method __invoke()
Hi,
On Fri, 2008-07-04 at 11:26 +0200, Lars Strojny wrote:
Am Freitag, den 04.07.2008, 11:15 +0200 schrieb Johannes Schlüter:
[...]
That's not entirely true, there are minor BC breaks: Let's say Bar is an
alias for Foo::Bar. now to $r = new ReflectionClass('Bar'); echo
$r-getName(); and
Hi Johannes,
Am Freitag, den 04.07.2008, 13:56 +0200 schrieb Johannes Schlüter:
[...]
Depends ;-)
Main point: There's no such thing as no BC break. So we have to decide
whether that BC break (hoping it's the only one) is less a problem than
having an inconsistent naming scheme. (... wait -
Hi,
a big -1 from me on the namings
I really see no point in having:
use Spl::Exception;
throw new Logic;
It makes the code hard to understand with no reason.
IMO a single SPL namespace is enough, and it solves the naming
problems we have with SPL.
Regards
On Fri, Jul 4, 2008 at 2:31 PM,
Hi Etienne,
Am Freitag, den 04.07.2008, 14:50 +0200 schrieb Etienne Kneuss:
[...]
a big -1 from me on the namings
I really see no point in having:
use Spl::Exception;
throw new Logic;
use Spl::Exception::Logic as LogicException;
throw new LogicException();
Besides that, what we should
Hi,
but there is already a structure in the namings of classes, and it's
already documented:
Iterators and Exceptions are however simply postfixed with
Iterator and Exception. Examples:
IMO this rule should still be valid in namespaces so I'd group
iterators along with what they iterates on,
Hi all,
Recently on the Dutch PHP convention I talked with Stefan Priebsch about
a new feature that I think would be a great addition to PHP. There are a
lot of array functions like count($array) and array_push($array,
$value). This has worked well for the past decade or so. However I would
On Thu, Jul 03, 2008 at 10:30:43PM +0400, Dmitry Stogov wrote:
I don't see big problems with closures. The patch is simple and stable.
While you're probably right, it seems there is still lots of discussion
about how closures should work. It seems better to get this right in a
later version
On Friday 04 July 2008 7:31:44 am Lars Strojny wrote:
Hi Johannes,
Alright, that's what my RFC was aiming for. Maybe from the wrong
direction. I wanted to do it exemplary for SPL and go on further for all
the other extensions we bundle in core. Namespacing everything is the
only way to
28 matches
Mail list logo
