Providing libraries for developers.

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Providing libraries for developers.

Post by kaisellgren »

I have come to a point in my project where I have lots of libraries that other developers can use to create plugins easily. These libraries are only loaded when they are needed (with __autoload).

An example library:

Code: Select all

class string
 {
  public static function str_replace_count(...) {...}
 }
Now it's easy for a plugin developer to use my libraries, he could just do:

Code: Select all

string::str_replace_count('search','replace',$subject,$count);
The libraries are easy to use and greatly improve the development time. Also, when I take the move in the future and support only PHP 5.3/6, then I can easily move into using namespaces ;)

Code: Select all

namespace string;
function str_replace_count(...) {...}
 
Also I'm using exceptions in these library functions like:

Code: Select all

if (!is_integer($count))
 throw new exception('You must pass an integer you dummy');
Not exactly what I do, but you got the point. :)

I'm just wondering am I doing something "wrong"?

Let's say that you pass a string into a built-in PHP function that takes only integers, it will inform you what you did wrong so shouldn't I do that too in my functions? And when something else goes wrong like fopen within the function then return false and log the error (and display it if the DEBUG mode for the script is enabled - in development stage).

Am I being utterly inane or does this make sense to you?

When I code in C# I use exceptions to exit from fatal problems and that makes me think if my approach here is rational.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Providing libraries for developers.

Post by alex.barylski »

I wouldn't say your doing anything "wrong" everything you have shown/displayed and asked will be subjective. Some personal opinions I will offer:

1. If your already using a namespace string:: there is no need to prefix functions with 'str'. DRY for me applies at all levels of development, even trivial interfaces.

2. Personally I dislike the idea of throwing an exception at every corner. I'd rather trigger an error (for consistency with other PHP functions/libraries)

3. I wouldn't include logging directly in your library, I'd let the client developer decide what and when and where to log by letting them override the error handler functions in PHP itself. Exceptions are a little better in this regard because you can initialize the object with all sorts of context specific information, where as trigger error I think your limited to

Code: Select all

trigger_error ( string $error_msg [, int $error_type ] )
4. I wouldn't test 'type' it's counter-intuitive in a language that is based on the reverse. If anything just cast a variable to an integer, string, etc.

Cheers,
Alex
User avatar
Chewbacca
Forum Newbie
Posts: 5
Joined: Fri Jan 23, 2009 1:57 pm

Re: Providing libraries for developers.

Post by Chewbacca »

Hi kaisellgren,

I think that exceptions are appropriate for handling recoverable errors that occur in an application. While I agree with Alex that you shouldn't always test the type of a variable in a dynamically typed language such as PHP, if passing a string to a method that requires an integer could potentially have dire consequences, then you should certainly throw an exception and allow the developer to recover from the error by catching the exception.
These libraries are only loaded when they are needed (with __autoload).
I recommend you make the switch to spl_autoload_register(): http://us3.php.net/manual/en/function.s ... gister.php. You can only set one __autoload() function per application, but you can register multiple spl_autoload functions at a time.

I also recommend that if you are going to throw exceptions in your library, try to throw the most appropriate exception. You can find a list of SPL exceptions at http://us3.php.net/manual/en/spl.exceptions.php

In this particular case, I'd recommend an InvalidArgumentException (http://us3.php.net/manual/en/class.inva ... eption.php). Remember, you can always extend the default PHP exception class if needed. See http://us3.php.net/manual/en/class.exception.php

If you feel that you need to log these types of errors, I would recommend implementing a subject-observer pattern into your library that will allow your end-users to specify the implementation of logging at runtime. Allow your end-users to attach a logging observer to your framework that listens for errors. You could once more benefit from SPL by using their interfaces for SplObserver and SplSubject: http://www.php.net/~helly/php/ext/spl/i ... erver.html, http://www.php.net/~helly/php/ext/spl/i ... bject.html

-Chewbacca
User avatar
kaisellgren
DevNet Resident
Posts: 1675
Joined: Sat Jan 07, 2006 5:52 am
Location: Lahti, Finland.

Re: Providing libraries for developers.

Post by kaisellgren »

Chewbacca wrote:I recommend you make the switch to spl_autoload_register(): http://us3.php.net/manual/en/function.s ... gister.php. You can only set one __autoload() function per application, but you can register multiple spl_autoload functions at a time.

I also recommend that if you are going to throw exceptions in your library, try to throw the most appropriate exception. You can find a list of SPL exceptions at http://us3.php.net/manual/en/spl.exceptions.php

In this particular case, I'd recommend an InvalidArgumentException (http://us3.php.net/manual/en/class.inva ... eption.php). Remember, you can always extend the default PHP exception class if needed. See http://us3.php.net/manual/en/class.exception.php

If you feel that you need to log these types of errors, I would recommend implementing a subject-observer pattern into your library that will allow your end-users to specify the implementation of logging at runtime. Allow your end-users to attach a logging observer to your framework that listens for errors. You could once more benefit from SPL by using their interfaces for SplObserver and SplSubject: http://www.php.net/~helly/php/ext/spl/i ... erver.html, http://www.php.net/~helly/php/ext/spl/i ... bject.html

-Chewbacca
I am actually already using the spl_autoload_register() and I am also extending the Exception class. I do not need logging features though.

Thanks for the answer.
Post Reply