Return-Path: X-Original-To: apmail-commons-dev-archive@www.apache.org Delivered-To: apmail-commons-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0F30296E1 for ; Mon, 9 Jul 2012 05:09:15 +0000 (UTC) Received: (qmail 30496 invoked by uid 500); 9 Jul 2012 05:09:13 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 30263 invoked by uid 500); 9 Jul 2012 05:09:13 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 30220 invoked by uid 99); 9 Jul 2012 05:09:11 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Jul 2012 05:09:11 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of SRS0=1vhy=FK=m4x.org=sebastien.brisard@bounces.m4x.org designates 129.104.30.34 as permitted sender) Received: from [129.104.30.34] (HELO mx1.polytechnique.org) (129.104.30.34) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Jul 2012 05:09:04 +0000 Received: from mail-gh0-f171.google.com (mail-gh0-f171.google.com [209.85.160.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 4F21514078D1A for ; Mon, 9 Jul 2012 07:08:43 +0200 (CEST) Received: by ghy10 with SMTP id 10so13313927ghy.30 for ; Sun, 08 Jul 2012 22:08:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.66.79 with SMTP id xp15mr19570811icb.41.1341810522170; Sun, 08 Jul 2012 22:08:42 -0700 (PDT) Received: by 10.64.103.138 with HTTP; Sun, 8 Jul 2012 22:08:42 -0700 (PDT) In-Reply-To: <20120709004234.GI25337@dusk.harfang.homelinux.org> References: <20120709004234.GI25337@dusk.harfang.homelinux.org> Date: Mon, 9 Jul 2012 07:08:42 +0200 Message-ID: Subject: Re: [math] Fluent interface in RealVector From: =?ISO-8859-1?Q?S=E9bastien_Brisard?= To: Commons Developers List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Mon Jul 9 07:08:43 2012 +0200 (CEST)) X-Org-Mail: sebastien.brisard.1997@polytechnique.org X-Old-Spam-Flag: No, tests=bogofilter, spamicity=0.012010, queueID=8F8A914078D1B 2012/7/9 Gilles Sadowski : > On Sat, Jul 07, 2012 at 01:49:25PM +0200, S=E9bastien Brisard wrote: >> Hello, >> most existing methods in class RealVector allow method chaining. > > Chaining does not always make for readable code. > >> However, some methods just return void instead of this >> - addToEntry >> - set >> - setEntry >> - setSubVector >> - unitize >> >> Are you OK with having all or only some (which ones) methods return this= ? > > +0 (for people who like it). > I agree, I generally find confusing methods which return {@code this}, but I have to admit that in this context, a fluent interface is very useful. S=E9bastien > > [And for API consistency.] > > > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > For additional commands, e-mail: dev-help@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org