Re^4: How can I call a class method of the object's parent class?

Thank you for the detailed instructions. I have thought about that a lot.

Most of the bugs are of very trivial nature. For example, if an object offers the possibility to set colors, and in the according function you see that instead of the variable a constant is being set, then it's quite obvious. Making a test stub for every one of those trivial cases seems excessive to me. I have not the time for that.

The background of the whole thing is that I needed an user interface for easy interactive configuration of a side project, which I need for my main project. And I was naive and didn't look at the maintenance status of Curses::UI before I decided to use it. So I was locked in, sort of, when I noticed more and more bugs after I built the applications' UI dialogs and started to test the application. Thus the fixing of Curses::UI is a side project of a side project into which I cannot afford to invest much time.

To keep my release schedule, I decided to just shove the Curses::UI modules that I use together to a big pile and include that in my script. It's ugly, but nobody will care.

Probably the best thing I can afford to do is to put those modules onto Github. Who likes to, can test them using my open source project. As I had to add several get/set property functions/methods that are common in GUIs, in particular to modify existing objects after creation, it's no pure bugfix anyway.

Nevertheless, I'll contact the author. If he thinks the fixes are good, he can grant me co-maintainership to put them in himself. Otherwise I will just make an bug report hinting interested users to my github package, as I for time reasons cannot meet the requirement of writing 50 stubs with POD documentation.

Anyway, I learnt one important thing from that. Next time I choose a cpan package, I will carefully examine its quality before I take it into consideration. For example, I lost quite a lot of time trying to use the CGI packages, only to find out they are inefficient and technologically outdated. But nonetheless so many people use it anyway. People who ask for better alternatives are being told: use package CGI, basta! So I had to write my own CGI routines to get good response times, be able to support secure cookies, etc, etc, etc

Comment on Re^4: How can I call a class method of the object's parent class?

Replies are listed 'Best First'.
Re^5: How can I call a class method of the object's parent class? by haukex (Archbishop) on Jan 05, 2018 at 10:55 UTC
Thus the fixing of Curses::UI is a side project of a side project into which I cannot afford to invest much time. I can completely understand that, and I certainly wouldn't want to "scare you away" by telling you how much test code I've had to write compared to application code for some commercial software ;-) And I also understand that if a fix is trivial, you don't necessarily want to write a full test case for that - but I guess you'll still want to briefly check that your fix worked? I'm just suggesting that it's better if it's possible to do so with code that is part of the Curses::UI package, even if it's just the `examples/demo-widgets` script. And sorry if I made it sound like POD documentation is necessary for every bugfix, what I was describing was more of a best practice - for trivial fixes a short commit message (referencing the RT bug if applicable) can certainly be enough. This is open source, if you want to fork Curses::UI you are free to do so and make contributions however you like - there are just some "best practices" (often subjective) that can improve cooperation. You could for example make a fork on GitHub of the latest Curses::UI release, something anyone could pull patches from if they want. Perhaps that could be a compromise between limited time and your willingness to contribute to an open source project :-)	[reply] [d/l]

Replies are listed 'Best First'.

Re^5: How can I call a class method of the object's parent class?
by haukex (Archbishop) on Jan 05, 2018 at 10:55 UTC

Thus the fixing of Curses::UI is a side project of a side project into which I cannot afford to invest much time.

I can completely understand that, and I certainly wouldn't want to "scare you away" by telling you how much test code I've had to write compared to application code for some commercial software ;-) And I also understand that if a fix is trivial, you don't necessarily want to write a full test case for that - but I guess you'll still want to briefly check that your fix worked? I'm just suggesting that it's better if it's possible to do so with code that is part of the Curses::UI package, even if it's just the examples/demo-widgets script. And sorry if I made it sound like POD documentation is necessary for every bugfix, what I was describing was more of a best practice - for trivial fixes a short commit message (referencing the RT bug if applicable) can certainly be enough. This is open source, if you want to fork Curses::UI you are free to do so and make contributions however you like - there are just some "best practices" (often subjective) that can improve cooperation. You could for example make a fork on GitHub of the latest Curses::UI release, something anyone could pull patches from if they want. Perhaps that could be a compromise between limited time and your willingness to contribute to an open source project :-)

[reply]
[d/l]