Re: [RFC_v3] Handling Backwards Compatibility in PEAR [hopefully the final draft]

Zitat von Tobias Schlitt <tobias@schlitt.info>: > > API: "Application Program Interface" is the connection between a > > package and the programs that use it. This includes class and method > > names, parameters that are passed to methods, and constant names, or > > any other publicly accessible area of a program. Elements explicitly > > marked as private data/methods are excluded from this definition. > > I think there should be some extension to changes of parameters on > functions > and methods. IMHO it should be allowed to add more parameters to a > function/method without doing the needed steps of BC change under those > conditions: > > 1) The parameter added has to have a default value (optional parameter). > 2) This default value has to match the functionality the package had > before > adding the new parameter. > > What do you all think about that? Agreed, though I think this case is covered by this sentence: " This obviously means that new functionality may be added as long as it doesn’t interfere with existing functionality." Jan. -- http://www.horde.org - The Horde Project http://www.ammma.de - discover your knowledge http://www.tip4all.de - Deine private Tippgemeinschaft