Date: 10/20/00
- Next message: adam <email protected>: "[PHP-DEV] PHP 4.0 Bug #7363: <email protected> supresses parse errors within included file"
- Previous message: herve.kabla <email protected>: "[PHP-DEV] PHP 4.0 Bug #7362: Crash when executing any mysql directive in php file"
- Next in thread: Rasmus Lerdorf: "Re: [PHP-DEV] A proposal regarding function naming, aliases and such"
- Reply: Rasmus Lerdorf: "Re: [PHP-DEV] A proposal regarding function naming, aliases and such"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I'd like to re-issue a suggestion i had already brought up
somewhere back this spring regarding function naming and backwards
compatibility:
- add some mechanism to mark functions (and alias names) as 'deprecate'
or 'experimental'
- add ini options that will generate warnings when using deprecate
or experimental functions (defaults to 'yes')
- finaly add a third state 'dead'
So whenever a new function is introduced it should be marked as
'experimental' first. Whoever uses theese will be warned that
they might change or even vanish in the future. Introducing the
new shared memory functions like this would have already saved us #
some discussion.
As a second step to get rid of annoying 'backwards compatibility'
aliases and even functions we don't want to support anymore we
mark them as 'deprecate' while leaving them in place. When we
decide to drop them lateron nobody can say that he hadn't been
warned (for people like me who do not really read the NEWS and
Changelog files).
As a final step we might consider to mark a function as 'dead' for
exactly one release step so that people who try a new release and
find their code not working anymore get at least a message like
'Error: the function foo() is no longer supported. It had already
been marked as 'deprecate' for some time now, so you
should have been warned!'
While a 'deprecate' function or alias might stay in that state
over more than one release i would suggest a policy to drop old
'dead' entries whenever a new minor release is born. If someone
skips releases from time to time: bad luck!
I have to dig out and reconsider the patches i tried out in spring,
i hope to be able to post my suggestions on monday
-- Hartmut Holzgraefe hartmut <email protected> http://www.six.de +49-711-99091-77Besuchen Sie uns auf der Buchmesse in Frankfurt, Halle 4.0, Stand D 1117 und auf der Systems in München , Halle C2, Stand 126
-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-dev-unsubscribe <email protected> For additional commands, e-mail: php-dev-help <email protected> To contact the list administrators, e-mail: php-list-admin <email protected>
- Next message: adam <email protected>: "[PHP-DEV] PHP 4.0 Bug #7363: <email protected> supresses parse errors within included file"
- Previous message: herve.kabla <email protected>: "[PHP-DEV] PHP 4.0 Bug #7362: Crash when executing any mysql directive in php file"
- Next in thread: Rasmus Lerdorf: "Re: [PHP-DEV] A proposal regarding function naming, aliases and such"
- Reply: Rasmus Lerdorf: "Re: [PHP-DEV] A proposal regarding function naming, aliases and such"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

