Re: Re: ext/imagick BC break (was: Re: [PEAR-DEV] PHP Magick version 0.5a Released!)

This wasn't anything particular about your extension, btw. I was talking with Thies in Vegas last week about his ideas for a new, more robust oci extension and one of the things we talked about was OO'ifying it. The _really_ nice thing about making them all method calls is that you don't have to do all this name munging. so you can do $handle = new imagick; $handle->readimage( "./image.jpg" ); $new_handle = $handle->clonehandle( ) ; Whereas there is probably not a huge amount of potential symbol conflict for the imagick extension, for db extensions it's just awful. Everyone has to define mydatabasename_execute, where otherwise they could just all be a method named execute. Sorry to make you the first victim of my new crusade.... :) George Michael Montero wrote:

Quite frankly, no haven't considered it. On Tue, 26 Nov 2002, George Schlossnagle wrote:

Since you're breaking BC, have you considered making the new imagick interface OO? There is enormous bloat in the php global function table, keepinf all your method names in a private namespace would be nice. George Michael Montero wrote:

Quick review, I will work on the doc. and forward around. Will shoot for today (althought most of the doc. is already below). These functions are supported: PHP_FUNCTION(imagick_border); PHP_FUNCTION(imagick_frame); PHP_FUNCTION(imagick_resize); PHP_FUNCTION(imagick_sample); PHP_FUNCTION(imagick_crop); PHP_FUNCTION(imagick_rotate); PHP_FUNCTION(imagick_shear); PHP_FUNCTION(imagick_oilpaint); PHP_FUNCTION(imagick_annotate); PHP_FUNCTION(imagick_convert); I haven't looked at each specifically but there is a chance the parameter order changed. UNLESS (and I believe Christian and I followed this standard) the handle is the first parameter and the subsequent parameters match the order in which they are passed to the ImageMagick functions. I looked at imagick_resize (old one) and the new one and they are dead on. These functions have been made backward compatible:

      PHP_FUNCTION( imagick_read ) ;     /* => imagick_readimage() */
      PHP_FUNCTION( imagick_write ) ;    /* => imagick_writeimage() */
      PHP_FUNCTION( imagick_free ) ;     /* => imagick_destroyhandle() */

These have been deprecated:

      PHP_FUNCTION( imagick_add_resource ) ;
      PHP_FUNCTION( imagick_list_magickinfo ) ;
      PHP_FUNCTION( imagick_new ) ;
      PHP_FUNCTION( imagick_init ) ;
      PHP_FUNCTION( imagick_copy_sample ) ;
      PHP_FUNCTION( imagick_copy_resize ) ;
      PHP_FUNCTION( imagick_copy_crop ) ;
      PHP_FUNCTION( imagick_copy_shear ) ;
      PHP_FUNCTION( imagick_copy_rotate ) ;
      PHP_FUNCTION( imagick_copy_morph ) ;
      PHP_FUNCTION( imagick_dump ) ;

A few explanations: imagick_add_resource() and imagick_list_magickinfo() aren't entirely necessary anymore. The phpinfo() will list everything that imagick_list_magickinfo() would dump to a file. If anyone disagrees, I can implement the function but I'd rather the data in phpinfo() then requesting PHP to dump a file. imagick_add_resource() will be supported in SOME fashion with regard to image lists. I believe this will use the ImageMagick push functions and should appear perhaps today. If I CAN make this function backwards compatible I will. imagick_new() has no meaning...to create a new handle you either have to create a canvas or read an image. Currently you can read an image from a file and by the time we're done from a blob of data as well. You can create a canvas of a specified size and color. Coming soon will be creating a canvas with a tiled background created from a custom image. imagick_init() isn't necessary anymore. ImageMagick needs to be initialized but I have removed the need for the user to remember doing this. The module will initialize itself and clean up after itself. imagick_copy* functions are too ambitious. The ImageMagick library is enormous and writing a corresponding copy function for every operation, in my opinion, is a wasted efforted (again, based solely on the number of functions available in ImageMagick). Instead, I support this: <? $existing_handle = imagick_readimage( "./image.jpg" ) ;

	$new_handle      = imagick_clonehandle( $existing_handle ) ;

// now execute a function on the cloned handled ?> In other words, instead of the function creating a new handle and returning it to you, you'd create a new handle and operate on it. imagick_dump(): I thought about this a lot. This essentially writes the image file out, then reads it and writes it to the browser. This seems like a lot of effort if all the user wants to do is work on an image and then just display it. You can achieve this with the new API by doing: <? $handle = imagick_readimage( "./image.jpg" ) ; header( "Content-type: " . imagick_getmimetype( $handle ) ) ; print $image_data = imagick_image2blob( $handle ) ; ?> If you want to write the file you can do so at another point or not do it at all. If anyone disagrees with this assessment let me know. I can put some work into some of it. However, I'm pretty opposed to the copy functions. There would need to be something like 20 or 30 (perhaps more) in addition to the same functions that operate on image itself without copying it. This seems like far too much to support. It makes more sense to me to let the user clone the handle when that's what they want and start operating on a different image entirely. Let me know what you think. On Tue, 26 Nov 2002, Alan Knowles wrote:

Michael Montero wrote:

I will clearly document how to go from the BC version to the new one.

can you give a 2-3 line overview of the differences: functions have different arguments/order? missing functions? (lots of new ones I presume :) ... phpmole uses it to do resize/rotate etc. Regards Alan

On Mon, 25 Nov 2002, Christian Stocker wrote:

Hi As mentioned in the mail by Michael, we will replace pecl/imagick with his version, as I think, he has much more to offer than my code (and much more time to support it right at the moment :) ). I will still support the extension and hopefully contribute to it. Therefore here comes the big WARNING: The commits (and finally releases) in the next few days will break BC of pecl/imagick! Therefore, if anyone is using this extension and really really needs BC should stand up now and maybe we will have a look what we can do :) But since it's clearly stated as alpha and experimental, noone should be surprised by that Anyway, have a nice evening and check out Michael's work. christian On Mon, 25 Nov 2002, Michael Montero wrote:

Just released some more functionality. The major push right now is join my efforts with those of Christian Stocker to get one single module into PEAR. Christian and I have been working that. Please see the latest changes below...they are significant.

     - functions added:
             imagick_getcanvas()
             imagick_blur()
             imagick_despeckle()
             imagick_edge()
             imagick_emboss()
             imagick_enhance()
             imagick_gaussianblur()
             imagick_medianfilter()
             imagick_motionblur()
     - one major change - renamed everything to imagick*; I've joined

my efforts with Christian Stocker who had a previously written

       but smaller extension
     - magick_getcanvas() allows you to create a blank image to draw on
     - changed comment header in imagick.h to match the one in
       imagick.c
     - added Christian Stocker to credits
     - moved over to Christian Stocker's config.m4, removed the need
       for gen_configm4
     - rewrote INSTALL to reflect new config.m4
     - slight modifications to config.m4 to get it to work properly
     - added package.xml
     - removed ChangeLog, everything is now in package.xml
     - removed imagick_free_reason() and imagick_free_description()
       since they are no longer necessary
     - preceded all internal functions with _php_
     - created imagick_read() for backward compatibility with old
       extension
     - created imagick_write() for backward compatibility with old
       extension