Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Re: [RFC] Module code and POD for CPAN

by Arunbear (Prior)
on Apr 14, 2021 at 11:43 UTC ( #11131266=note: print w/replies, xml ) Need Help??


in reply to [RFC] Module code and POD for CPAN

I agree with hippo's suggestion that 'Checkout' should be part of the name. Also
  1. Your class is doing checkout handling and trolley handling (Single responsibility pattern / Cohesion). Consider having a separate Trolley object for trolley handling.
  2. The pattern of iterating over the trolley and doing something to just one item suggests the trolley ought to be a hash (keyed by the product ID). You can add extra keys to aid with sorting if you need that.
  3. Consider using Moo or something similar to make the OOP more ergonomic.
  4. Exceptions are usually preferable to silent returns because they are harder to ignore (see Try::Tiny).
  5. 'unless' is tricky for many people (it doesn't scale up, can lead to double negatives etc).
  6. 'and' and '&&' are not the same thing (the former is for combining statements)

Replies are listed 'Best First'.
Re^2: [RFC] Module code and POD for CPAN
by hippo (Bishop) on Apr 14, 2021 at 12:43 UTC

    I'm about to disagree to a greater or lesser extent with a lot of your points here. Most of them are (I hope you will agree) subjective so please treat these responses as just my own opinions.

    1. In general, separation of concerns is good and I am a firm proponent of the Unix Philosophy. However, since a trolley without a facility to check out is pretty useless and a checkout without a trolley equally so I humbly suggest that this is at least not as big a deal for this module as it might be elsewhere and may not even be desirable here at all. Bod should indeed consider it, as you have said.
    2. I agree here, unless the items in the array can be referenced by their index but that sounds like even more work in this instance.
    3. Considering alternatives like Moo is a worthwhile exercise but also remember that TANSTAAFL.
    4. Again, TANSTAAFL. Lots of devs swear by exceptions. Other devs swear at exceptions. I'm fairly ambivalent on them. To use them well you need structure and that means a framework and that means more dependencies. Just be aware of the costs of using them or not.
    5. This is the one I really disagree with. No doubt some people find unless tricky. Pick any feature of the language and some people will find it tricky. But does a module author care what others find tricky? Postfix deref drives me nuts but that doesn't mean that module authors should stop using it. Further, I actively like unless because it means that horrible things like if (!$foo || !$bar || !$baz) { ... } become unless ($foo && $bar && $baz) { ... } which is (subjectivity klaxon) much clearer to read and in intent. The only reason it doesn't fully scale is that there is no elsunless to correspond to elsif which is an oversight in the Perl language and not an inherent flaw with unless itself. Bod should feel entirely free to use unless throughout his code in the same manner that you should feel entirely free to eschew it in yours.
    6. I completely agree (phew :-)

    I am neither intending nor expecting to change any of your opinions by posting this but am trying to provide an opposite view so that Bod and others are aware of the contrary viewpoints.


    🦛

Re^2: [RFC] Module code and POD for CPAN
by Bod (Deacon) on Apr 14, 2021 at 12:38 UTC

    Thanks - quick reply to explain two three points. I'll look at the rest in more detail a little later

    1. Your class is doing checkout handling and trolley handling (Single responsibility pattern / Cohesion). Consider having a separate Trolley object for trolley handling.

    I did think of this. However, the Trolley only exists as a repository of the 'stuff' that is needed by the Stripe checkout. It isn't (intended to be) useful by itself.

    3. Consider using Moo or something similar to make the OOP more ergonomic.

    I expect much of the use of this module to be for small businesses using shared hosting. For this reason, I want to keep the dependencies as only core modules.

    4. Exceptions are usually preferable to silent returns because they are harder to ignore (see Try::Tiny)

    As above, Try::Tiny isn't core. Also, having $stripe->success is consistent with the Javascript methods provided by Stripe in stripe.js

    I'm not suggesting I made the optimal choices for these, just explaining why I chose to do things the way I did.

      Class::Tiny is similar in purpose to Moo, and like Try::Tiny it has no non-core dependencies, which means installing those (on shared hosting) is no more difficult than installing this particular project.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11131266]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (1)
As of 2021-10-16 02:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My first memorable Perl project was:







    Results (69 votes). Check out past polls.

    Notices?