> > Because of the experimental status, I don't think phpdev should worry
too
> > much about the
> > incompatibility, it's the user's own reponsibility to use an
experimental
> > module.
>
> Taking a look at the changes to the sockets extension, some break things
> on a Linux system, some don't work at all,
If I understand you well (I'm not sure I do), you say that the new extension
doesn't work properly on linux? Of course, that needs to be fixed...
but the new API seems fine by me.
> a side note even with
> experimental extensions, you still need to be concerned with backwards
> compatibility, under your logic i could remove the Sablotron extension
> in favor of the XSLT extension, since Sablotron is marked experimental?
No, I was a bit un-nuancated (I hope you understand that dutch-ism...).
You're right, above that, the fact it is experimental wasn't stated in
the documentation. Though IMO in experimental does mean that the
API might change. Of course, try to keep the old scripts working, but
if a choice has to made between either a consequent API and 100%BC
and an inconsequent API with 95% BC... I think the consequent API
is preferred. Otherwise you'll sit for ages with a strange API.
Summary:: Change the API when the module is still in experimental status,
rather than never change it and sit with a bad API for long time.
But this discussion is not relevant here, because it's possible to
both change API and keep old scripts working. (see below)
> I wouldn't remove the EXPERIMENTAL status.
k
Jani wrote:
> What new functionality? Why the hell should the API change?
> Only the function names should have been changed, not break
> the whole extension!
I am in favor of the change to follow the convention of returning
FALSE on error. It can be combined with the function-renaming:
let the old function names behave - for now - as before, but
let the new ones behave the new way. I.e.: do NOT let the
new names be aliases for the old ones. This way you
won't break current scripts, while the new API is still compliant
to the current PHP-conventions.
Greetz,
Jeroen
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
