Hi Chris, On Mon, Oct 3, 2011 at 10:01 PM, Chris Travers <[email protected]> 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. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
