Re: Proposals for 1.4 framework changes

[Erik Huelsmann <..hidden..>]

Hi Chris,

On Mon, Oct 3, 2011 at 10:01 PM, Chris Travers <..hidden..> wrote:
> Hi all;
>
> As I am going over it, it seems our reasons for avoiding Moose have
> become less of an issue and now some of our dependencies depend on
> Moose.  Consequently I think I am going to recommend we start using it
> for new code starting with 1.4.  The original reasons involved lack of
> support with mature versions on many distributions, and the fact that
> it has a lot of dependencies.  However, we now have dependencies that
> depend on Moose, so I don't see a reason not to use it.

We talked about Moose yesterday on IRC. Before then I didn't know
Moose, but after looking at it, I really like what I see: since I'm
from a Common Lisp background, it really makes sense to me. However,
I'm not familiar enough with the problems you're trying to solve to
understand if the cost of not using Moose outweighs any possible
downsides of using Moose.

In other words, even though I think Moose is great, I'm not sure how I
should feel about using it in LSMB: if there's only a very small
subset of functionalities we can't address with the current framework,
but we can work around the real technical issues easily (but ugly)
then does that warrant rewriting our existing code or -if we decide
against that- to have multiple paradigms in our code - which could be
our next level of spaghetti, if we aren't carefull.

> The second set of framework changes I would propose for 1.4 involve
> stored procedure argument semantics and support for these.  For 1.4, I
> would recommend going to:
> arg_ as a prefix meaning an external argument not intrinsic to the
> type being processed, and prop_* which would refer to the property
> list of the object calling it.  Thus we might see:
>
> create or replace function get company__get(arg_id) returns company_ext as
>
> The above would suggest we do not yet have a company we are pulling,
> and therefore expect the argument to be supplied from input rather
> than from an object.
>
> CREATE OR REPLACE FUNCTION asset_report__approve(prop_id) RETURNS
> asset_report as...
>
> This would indicate we currently expect that we have an asset report
> we are just trying to approve, and therefore would assume we grab the
> id from that object.

Discussing this change with you on gChat, I can definitely see the
value of this change: it'll allow us to write our code in a much
clearer way: we won't have to get the low-level db interfacing in our
way.

> I think we'd have to check for in_ on the front of the first argument
> and handle the current way in order to avoid bugs in our code......
>
> Additionally, and this becomes a bigger deal for financial
> transactions, is I would like to set up arguments so we can handle
> arrays of hashrefs in properties or arguments and translate these
> correctly into arrays of tuples in the database interface.
> Consequently:
>
> CREATE OR REPLACE FUNCTION journal_entry__save(prop_reference text,
> prop_description text, prop_post_date date, prop_lines
> journal_line[])......
>
> These are actually pretty easy to query (select sum(amount) = 0 as
> balanced from unnest(prop_lines) l)

I'm afraid I'm missing the purpose of this bit of design. If the idea
is to have an array of hashes as the argument to the function (which
could be the return value of a query) being turned into a list of
arrays, based on the parameter names, then that sounds definitely like
an extremely useful extension of the 'get from object' paradigm. This
does not work for 'out_' parameters though, does it?

> This would allow all journal lines to be passed in at once, allowing
> us to check for imbalanced transactions before one is posted.

Yes!!

> On the latter, DBD::Pg should do most of the heavy lifting for us if I
> understand correctly.
>
> Any feedback?

Anything that makes us programmers more effective until we hit
performance problems.

My only concern so far is that we shouldn't be introducing too many
different paradigms in our code: it should still be clear to the
casual contributor which style he or she should write their code in.
Having too many different styles is going to confuse us as well, when
we have to debug across several levels of 'code age'.

Bye,

Erik.