adding sheets to an existing book seems a fairly good idea. I fully support the idea.
On the OO interface, why not, but let's say that I a bit skeptical: I have the feeling that there are too many modules out there (in the CPAN, that is) that use an OO interface which just tends to give them a more difficult syntax (especially for beginners) and to make them more difficult to use, without any obvious benefit. We don't need to fall into the trap of Java and other languages which force you to superimpose an OO approach for things which could be made far simpler with a procedural or functional orientation. Please do not misunderstand me: I am not against OO programming, I am against it when it makes things more complicated than they need to be. But that's only my two cents of personal taste.
Concerning the idea of merging, copying, moving or deleting rows, columns or blocks, I have the feeling that it is something that you want to do using a spreadsheet interactively, but that is more difficult to figure out use cases where this could really be useful in a program, it seems that most of these operations, when needed, can be done easily with simple loops. So, again, why not, but do you really want to make your API much more complicated for something that is probably not very much needed in real situations.
Or perhaps it could go into a sub-module for people wanting to use that type of functionality, but without cluttering the current interface with bells and whistles that most people are not going to use.
Sorry if I may sound not very enthusiastic, but I tend to balk at using modules whose documentation requires many thousands of lines. In short, IMHO, keep it simple. Or put it in a sub-module.
In reply to Re: Spreadsheet::Read - Changes and quest for feedback
by Laurent_R
in thread Spreadsheet::Read - Changes and quest for feedback
by Tux
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |