Date: 10/20/00
- Next message: Andi Gutmans: "Re: [PHP-DEV] why the damn phpinfo() is so talkative? + answers"
- Previous message: adam <email protected>: "[PHP-DEV] PHP 4.0 Bug #7363: <email protected> supresses parse errors within included file"
- In reply to: Hartmut Holzgraefe: "[PHP-DEV] A proposal regarding function naming, aliases and such"
- Next in thread: Andi Gutmans: "Re: [PHP-DEV] A proposal regarding function naming, aliases and such"
- Reply: Andi Gutmans: "Re: [PHP-DEV] A proposal regarding function naming, aliases and such"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
This approach will only really work if people upgrade regularly. If
someone was to jump from 4.0.0 to 4.0.27 then all these nice steps in
between where functions took different states really won't make any
difference.
-Rasmus
On Fri, 20 Oct 2000, Hartmut Holzgraefe wrote:
>
> 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-77
>
> Besuchen 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>
>
>
-- 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: Andi Gutmans: "Re: [PHP-DEV] why the damn phpinfo() is so talkative? + answers"
- Previous message: adam <email protected>: "[PHP-DEV] PHP 4.0 Bug #7363: <email protected> supresses parse errors within included file"
- In reply to: Hartmut Holzgraefe: "[PHP-DEV] A proposal regarding function naming, aliases and such"
- Next in thread: Andi Gutmans: "Re: [PHP-DEV] A proposal regarding function naming, aliases and such"
- Reply: Andi Gutmans: "Re: [PHP-DEV] A proposal regarding function naming, aliases and such"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

