If you can't read, here's again: "It was originally only enabled for debug
builds and should always still be, I've no idea why Marcus made it enabled
always in the first place."
That should answer all your questions. And no, it's still not doing anything
similar like ini_get_all().
Now, be a nice boy and revert and study the code more before you commit anything
else.
For the rest of you peeps: You should actually start reviewing the patches and
not just say "it's ok, commit" in IRC..
--Jani
Hannes Magnusson kirjoitti:
On Mon, Apr 14, 2008 at 7:43 PM, Jani Taskinen <[EMAIL PROTECTED]> wrote:
Hannes Magnusson kirjoitti:
On Mon, Apr 14, 2008 at 5:40 PM, Jani Taskinen <[EMAIL PROTECTED]>
wrote:
Eh..do you really understand the code correctly..? ini_get_all() is very
much different what config_dump_hash() was/is.
Uhh.. I don't see the difference. And there are no tests to compare it
against.
I already asked on internals@ and after no reply I tracked down helly
on IRC and he was fine with merging them.
This function was originally just meant for debugging the config hash.
And hint for the difference is: registered vs. anything (that was
freebie..)
Rule 1: Learn how to use CVS before you commit (hint: cvs annotate
filename.ext)
Rule 2: Once you learned how to use CVS and figured out who to ask: ASK.
Rule 3: Ask the right people before committing.
Rule 4: IRC != internals@ (I haven't seen ANY question about this on
internals!)
Now be good boy and revert the crap, that function is VERY useful for
debugging how the php.ini stuff works (or not) and should be there. It was
originally only enabled for debug builds and should always still be, I've no
idea why Marcus made it enabled always in the first place..
Rule#1: Test the stuff you write, not only in your mind, with .phpt too
Rule#2: Make sure there are not more than 3 functions doing almost the
exact same thing.
Rule#3: Subscribe to internals@ and participate in the discussion of your work
Rule#4: Add comments about any hidden meanings behind the function
Rule#5: Add a frckin [DOC] note to the commit explaining how the stuff
works so it can be documented
Rule#6: If you write a function just to so it can be used when
debugging another internal feature add it in #ifdef FEATURE_DEBUG or
whatever so other people don't come after you and wonder wtf you were
thinking
Rule#7: If a documentor asks for clarifications on internals@ then help him
Rule#8: Do not reclassify bug-reports as documentation problem without
further information
If you don't tell anyone about what you are doing you cannot expect
anyone else to know what your intentions are. If the function should
be documented, removed, changed, only in debug mode, only there or
only here. Marcus apparently thought you made a booboo and renamed it
and enabled it in normal builds, and I seeing absolutely no point in
yet another ini-get function combined it with another function
seemingly serving the same purpose, in slightly different format...
I did ask on internals@ if we really did need yet-another-ini-get
function and since noone replied I followed your basic principle:
Commit and let the trolls flame.
-Hannes
(learned from the best! ;))
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
