Re: Policy for procedural style in new additions
Am 03.06.2021 um 22:47 schrieb Kamil Tekiela <tekiela246@gmail.com>:I love this idea. We
should definitely make it official that procedural
> style API is unfavourable and should not be added to new classes.
> On top of that, I would be in favor of deprecating all existing procedural
> APIs.
> - It's making it more difficult to maintain code in two variants
> - It's making it difficult to maintain documentation
> - It's confusing for users
> - Procedural API is usually much more verbose than OO style
> - The return values often do not match
While I understand your points and especially see the benefit for maintainers, I'm not a fan of
make-everything-OO-with-exceptions.
This leads to more exceptions creeping into otherwise exception-free code. I assume that some people
don't see a problem with that but it can end up using exceptions for flow control which is
frowned upon even by some exception enthusiasts.
As soon as you start mixing ifs and exceptions it tends to get messy because you might even end up
converting ifs to exceptions like
try {
$date = new DateTime($datestring);
if ($limit > $maxlimit)
throw new Exception(...);
...
} catch (Exception $e) {}
as opposed to
if ($date = date_create($datestring) and $limit <= $maxlimit)
...
I'm fine with new OO style APIs not providing a procedural equivalent but I'm wary about
deprecating/removing existing ones.
Final remark: I think neither procedural nor OO style is the right choice for everything. I believe
it should be decided individually.
- Chris
Thread (7 messages)