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

Hi George ext/imagick would be certainly a very good extension for implementing nice and clean OO support. And I would certainly assist in that (as one of the domxml maintainers, I know much more about the zend engine now then back then :) ), but I'm not able to do it by myself (timewise). I don't know, what michael is thinking about going OO, as he wrote almost all of the new stuff. (BTW available at http://magick.communityconnect.com/ until he gets CVS pear access) chregu On Tue, 2002-11-26 at 17:00, George Schlossnagle wrote: > 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 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >> > >> > >> > > -- christian stocker | bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECB