SQL::Abstract::More is a drop-in, completely compatible extension of SQL::Abstract that adds significant functionality. The main thing I like is the join syntax. The main thing I hate is that he overloaded the SQL::Abstract API, so that the same function does different things based on whether it is called with named or positional parameters: 

# positional parameters, directly passed to the parent class
  my ($sql, @bind) = $sqla->select($table, $columns, $where, $order);

  # named parameters, handled in this class 
  my ($sql, @bind) = $sqla->select(
    -columns  => \@columns,
      # OR: -columns => [-distinct => @columns],
    -from     => $table || \@joined_tables,
    -where    => \%where,
    -order_by => \@order,
    -group_by => \@group_by,
    -having   => \%having_criteria,
    -limit => $limit, -offset => $offset,
      # OR: -page_size => $size, -page_index => $index,
    -for      => $purpose,
   );

[download]

IMHO, he should've used different function names for the different calling interface. Why? Because a function converts input to output and different input belongs in a different function. What do you think? Do you like Laurent's approach or would you have preferred a different function like me?

Replies are listed 'Best First'.
Re: SQL::Abstract::More overloads the SQL::Abstract API
by jdrago999 (Pilgrim) on Aug 31, 2011 at 06:40 UTC

    In this case, you could create a new CPAN module based on what you see there in SQL::Abstract::More - but using different function names - and use it instead. Others who also prefer the non-clobbering way you provide may find your module more to their liking.

    You are probably not alone. I like how the ::More version accepts named arguments - but I also can see where it might cause some problems with other code I've already got that depends on the old positional-style arguments. If I had a way to get both at the same time, I'd take it. As-is, I (and everyone else) can only have one-at-a-time.

    I'll keep an eye on The hot-sheets looking for your contribution.

[reply]
Re: SQL::Abstract::More overloads the SQL::Abstract API
by dami (Initiate) on Sep 01, 2011 at 10:25 UTC

    For info, the new API is just an addition to the old API. Compatibility with the old-style positional API is preserved. The only possible collision would be if you call select($source, ...) where $source is a scalar and starts with a hyphen ... very unlikely, I'm not even sure that this would be a valid SQL table name

[reply]
      It's valid, just not recommended.
      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]
Re: SQL::Abstract::More overloads the SQL::Abstract API
by locked_user sundialsvc4 (Abbot) on Aug 31, 2011 at 01:14 UTC

    Sounds like you’re volunteering?   Thanks!

    Seriously... what would you do?   What did the original author overlook?   How would you improve upon it?   (I said:   seriously.)

      Sounds like you're volunteering? Thanks!
      No, I'm having a software engineering discussion in order to further my understanding of where my viewpoint is sound/unsound.
      what would you do?
      I would use capitilized versions of the functions for my named parameter API.
      What did the original author overlook?
      Overlook? I just said I dont like the overloading - where a single function has two different behaviors based on the type of arguments passed.
      How would you improve upon it?
      See the answer to your question: "What would you do?"
[reply]

        “No, I’m having a software engineering discussion ...”

        Thank you, sincerely, for the clarification.   It helps my understanding of your intentions for this thread quite considerably.   I have no further objections, and I have nothing in particular to contribute, so I will now be “listening” attentively.   I think it is good to examine such things.

Back to Meditations