Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 56513 invoked from network); 9 Apr 2004 11:44:30 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 9 Apr 2004 11:44:30 -0000 Received: (qmail 74903 invoked by uid 500); 9 Apr 2004 11:44:24 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 74858 invoked by uid 500); 9 Apr 2004 11:44:24 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 74831 invoked from network); 9 Apr 2004 11:44:23 -0000 Received: from unknown (HELO unxcoms01.ecnetwork.co.nz) (202.135.116.201) by daedalus.apache.org with SMTP; 9 Apr 2004 11:44:23 -0000 Received: from serpent.ecnetwork.co.nz (serpent [202.135.190.10]) by unxcoms01.ecnetwork.co.nz (8.12.8/8.12.8) with ESMTP id i39BiMgU028951 for ; Fri, 9 Apr 2004 23:44:22 +1200 Received: from pcjohns.ecnnz.ecnetwork.co.nz (unknown [202.135.190.30]) by serpent.ecnetwork.co.nz (Postfix) with ESMTP id 70AD51035 for ; Fri, 9 Apr 2004 23:51:37 +1200 (NZST) Subject: [digester] InvokeMethodRule From: Simon Kitching To: commons-dev@jakarta.apache.org Content-Type: text/plain Message-Id: <1081511061.16932.44.camel@pcsimon> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 09 Apr 2004 23:44:22 +1200 Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Hi, I've created a branch called DIGESTER_INVOKE_METHOD_BRANCH, and committed some code to it. This is an implementation of a new variant of CallMethodRule. This new variant invokes its target method as soon as all parameters are available. As discussed earlier on this list, this makes behaviour more intuitive in most cases. It also takes the opportunity to learn some lessons from CallMethodRule, and hopefully provide a cleaner API. And hopefully it provides a model for implementing "immutable object creation", where it is desired to create objects with non-default constructors, but where the data is present as child tags, not as attributes. I don't think this is candidate material for release 1.6, as it is a reasonably large body of new code. But it does pass *all* the tests provided for CallMethodRule (modified to suit the InvokeMethodRule api). I'm committing it now so that people can see the code (and so I don't lose it!). All comments welcome. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org