Re: [PEPr] Images::Imagick proposal, Naming Issues

> I am not sure 'Image_Imagick' is the better name, > 'Image_Magick' would be enough and better I think. > Pecl 'imagick' is an abbr for 'Image-Magick'. As this class will go in the > Image directory perhaps there is no need to add another redondant 'I' meaning > 'Image' twice? That's is right. I took it because it wraps the imagick-library. But I don't know if Image_Magick may confuse some users, since ImageMagick is the original name of the software this wrapper is based on. > Even if it is through pecl-imagick wraper, Image_Magick wraps to Image-Magick > at the final point. pecl->imagick is just a link in this chain (I'll come back > on this point below). Good point. But wouldn't the developers of ImageMagick be concerned about this - using the name for a PHP wrapper-class? > Even in the desing of your class, I think INHO that you should keep in mind > that your class should wrap to IM, and not to pecl-imagick. I am almost convinced ;) > Who this class is designed to? > > Only php users or also for every-day IM users, and users from the IM > community? > If this class is also intended to be used by IM users, it should respect the > IM standard names of the operations, a lot of actions have been hardly > customized with prefix and suffix, and even been renamed. > > The magick.pdf doc contains the doc for the 4 majors intefaces of IM: > - the command line > - the C api > - the C++ api > - the Perl api > (There are other apis like scheme, py, php, but all those are very alpha.) > There are small differences, but it is quite uniform and standard. > > Just consider respecting the standard IM command names like respecting Pear > coding standard! > > However to fit for users that are not IM users and that don't know IM, > names like 'doubleSizeImage' are indeed more understandable than 'magnify'. > > Renaming magnify to doubleSizeImage, and minify to halfSizeImage is perhaps > quite safe IMHO for the far more tricky names, though if you expect that IM > users will find the operations they are used to, perhaps aliases should be > made? > If you do not want to keep IM standard operations naming, and if you do not > want to provide alias for those, you should perhaps give correspondances in > the documentation for those users. > > A solution could be to use aliases, and the main function should be the > standard IM ones' named. > > (If this class would only have to fit to me as an every day IM and PHP user, > or if I would have wrote such this underlaying class for conjure, > I would just have kept all the standard IM names, since the advantage for this > would have been to let users have unified support from the IM community, > where on the IM mailing-list there are all kind of users, Perl, C, > php-imagick, etc.. and everybody can understand each other's tips through the > common IM language) > > In case the Pear community would make the choice to rename the IM language, > perhaps we should take 5 min to consider each renamed operation. > 'setContrast' as a loop around pecl::contrast could good for non-IM users. > Nevertheless adding the 'set' prefix or not should be considered seriously. > I like the C++ method-names. I will use these. Nevertheless, I will put alias-methods into the source (@see magnifiy) for the 08/15 Image_Magick-user ;) > Personnaly I would prefer no prefix, but if pear community choose to put one, > I would prefer only one unified prefix, for all the pear::IM functions, > rather than classified function prefix which will be very tricky to make the > decision for some functions that are not clearly definable and classificable. I will use C++-type Method-Names. I will use prefix/postfix where appropriate or needed, or where a method-name (magnify) doesn't exactly describes what the method does. Nevertheless I will keep the PEAR-Coding standards for the method-names, this will mean that I won't use underscores. I hope this is ok for the core-IM-user. See you in the next post ;) Regards Thorsten