New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CPAN Pull Request Challenge 2015 #9

Closed
wants to merge 5 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@fluca1978

fluca1978 commented Dec 17, 2015

These are a few little changes to the module in order to better check arguments during object creation and to handle in a better way the code reference for the worker_id method. A few other cosmetic commits are within the pull request.

fluca1978 added some commits Dec 17, 2015

Placed braces around the use of Module::Install within the Makefile.PL,
in order to avoid the problem reported as:
Bareword "use_test_base" not allowed while "strict subs" in use at
Makefile.PL line 16

This is a workaround as specified in
https://rt.cpan.org/Public/Bug/Display.html?id=76240
Improved the test against the base_dir parameter: the directory must not
exist as a regular file or something that is not a directory (e.g., a FIFO).
The worker_id parameter was not handled correctly: it was always using
the $$ return value.
If a user specifies a worker_id parameter as as sub ref such ref is
stored and used to get the id. A new simple test has been created.
Documentaion has been updated.
@kazuho

This comment has been minimized.

Show comment
Hide comment
@kazuho

kazuho Dec 17, 2015

Owner

Thank you for the PR.

Owner

kazuho commented Dec 17, 2015

Thank you for the PR.

@fluca1978

This comment has been minimized.

Show comment
Hide comment
@fluca1978

fluca1978 Dec 17, 2015

I mainly see two problemtic commits here:

  • 09d62a2 while it is true that base_dir could be a link, it surely cannot be a file or a socket and therefore the user should get a chance to find out why the base_dir cannot be handled. Should we add a more strict test towards dir/links only?
  • 6d0cf56 while working_id was working right (I did not reported it as a bug), it is not checked to be a subroutine, and that could cause a runtime error. My idea was to prevent this in the very beginning.

What do you think?

fluca1978 commented Dec 17, 2015

I mainly see two problemtic commits here:

  • 09d62a2 while it is true that base_dir could be a link, it surely cannot be a file or a socket and therefore the user should get a chance to find out why the base_dir cannot be handled. Should we add a more strict test towards dir/links only?
  • 6d0cf56 while working_id was working right (I did not reported it as a bug), it is not checked to be a subroutine, and that could cause a runtime error. My idea was to prevent this in the very beginning.

What do you think?

@kazuho

This comment has been minimized.

Show comment
Hide comment
@kazuho

kazuho Dec 18, 2015

Owner

We definitely not want to change the behavior.

Therefore, the only chance of getting such assertions merged is when we come up with a nifty way of making such assertions without changing the behavior.

Regarding 09d62a2 I am not sure -s and -d are sufficient checks. And such checks have false positives (e.g. when a directory that is not writable by the program is specified).

Regarding 6d0cf56, not all callable objects are guaranteed to return ref($obj) eq 'CODE', and therefore I am backwards against doing such checks.

Generally speaking, I am not sure if it is worth trying to make such assertions considering the fact that Perl is a duck-typing proglang.

Owner

kazuho commented Dec 18, 2015

We definitely not want to change the behavior.

Therefore, the only chance of getting such assertions merged is when we come up with a nifty way of making such assertions without changing the behavior.

Regarding 09d62a2 I am not sure -s and -d are sufficient checks. And such checks have false positives (e.g. when a directory that is not writable by the program is specified).

Regarding 6d0cf56, not all callable objects are guaranteed to return ref($obj) eq 'CODE', and therefore I am backwards against doing such checks.

Generally speaking, I am not sure if it is worth trying to make such assertions considering the fact that Perl is a duck-typing proglang.

@miyagawa

This comment has been minimized.

Show comment
Hide comment
@miyagawa

miyagawa Dec 18, 2015

that could cause a runtime error. My idea was to prevent this in the very beginning.

An error is actually a better message to the user, than silently ignoring and changing to the implicit default behavior.

miyagawa commented Dec 18, 2015

that could cause a runtime error. My idea was to prevent this in the very beginning.

An error is actually a better message to the user, than silently ignoring and changing to the implicit default behavior.

@miyagawa

This comment has been minimized.

Show comment
Hide comment
@miyagawa

miyagawa Dec 18, 2015

ff8267e doesn't sound right to me. bareword use_test_base is fine as long as you have a right Test::Base related files in bundled inc.

miyagawa commented Dec 18, 2015

ff8267e doesn't sound right to me. bareword use_test_base is fine as long as you have a right Test::Base related files in bundled inc.

@miyagawa

This comment has been minimized.

Show comment
Hide comment
@miyagawa

miyagawa Dec 18, 2015

Actually, a better fix is to remove line 16-17 in Makefile.PL altogether since Test::Base isn't used at all! @fluca1978 try that patch as a separate PR and i'm sure it will be merged :)

miyagawa commented Dec 18, 2015

Actually, a better fix is to remove line 16-17 in Makefile.PL altogether since Test::Base isn't used at all! @fluca1978 try that patch as a separate PR and i'm sure it will be merged :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment