[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposals for 1.4 framework changes



On Tue, Oct 4, 2011 at 1:20 PM, Erik Huelsmann <..hidden..> wrote:
> 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?


Right now we can pass complex arguments in using two methods:
cross-index arrays (as in the single payment interface) or 2d arrays
(like in the bulk payment interface).  Both these have significant
drawbacks in terms of code clarity and type checking. Moreover it is
not very self-documenting in terms of relationships between items and
types of input expected.

This makes it really easy to query inputs to ensure that GL
transactions are balanced.   And the number of procedures which are
affected are small (2) and these will probably need to be rewritten
anyway.
>
>> 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'.
>
I think right now, we are in a little bit of a transitional stage.  I
would like to try to get things by 1.4 or 1.5 into a fairly stabilized
set of code paradigms, but 1.3 isn't it.  We were so entangled with
old code in 1.2 and the development of 1.3, I figure it should take 2
or 3 (but no more!) releases (including 1.3) to stabilize how we do
things.

Best Wishes,
Chris Travers