Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:24326
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <00fe01c6a4c7$909ad070$0201a8c0@pc1>
To: <internals@lists.php.net>, "Marcus Boerger" <helly@php.net>
References: <009a01c69848$06f22e80$0201a8c0@pc1> <009f01c69cf9$6b493f30$0201a8c0@pc1> <1772356126.20060701125346@marcus-boerger.de> <008701c6a014$ec07ebd0$0201a8c0@pc1> <56141794.20060706101753@marcus-boerger.de>
Date: Tue, 11 Jul 2006 03:54:05 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH] array_fill: Allow an array to specify keys
From: php_lists@realplain.com ("Matt W")

Hi Marcus,

I'm replying again for clarification about the patch.  When you first
replied and said it looked OK, you mentioned "once we agree to this," which
I assumed meant it could be used/committed.  I saw array.c hasn't been
changed in CVS (though I don't know when that would happen anyway), so I was
kinda wondering, that's all. :-)

Then about the tests, I still didn't know whether you'd tell me to make a
tests file *after* committing the patch or if you need it *first*.  Sorry.
:-/

If you (meaning anyone who'd apply the patch) are just waiting for tests,
please let me know, and I'll create tests for all array_fill() functionality
(old and new) right away!

BTW, since sending the patches, I realized that my code will allow an empty
"keys" array.  I'm thinking there should be a warning for that to make it
consistent with the old behavior of not returning an empty array.  Should I
change that and RE-send patches...?


Thank you,
Matt


----- Original Message ----- 
From: "Marcus Boerger"


> Hello Matt,
>
>   in general we only require head first and once that is in we discuss
> merging the stuff to older versons (in this case 5.2). Tests have not
> always been required but it has shown that we introduce to many changes
> this way. So we more and more develop with tests. Especially when there
> is a change in an untested area it is very good to test against old
> documented behavior first and then see what changes with the patch.
> For the tests themselves we not test for every error situation but we
> test for a lot.
>
> best regards
> marcus