Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 63794 invoked from network); 19 Aug 2009 00:44:39 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 19 Aug 2009 00:44:39 -0000 Received: (qmail 59959 invoked by uid 500); 19 Aug 2009 00:44:57 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 59857 invoked by uid 500); 19 Aug 2009 00:44:57 -0000 Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@lucene.apache.org Delivered-To: mailing list java-dev@lucene.apache.org Received: (qmail 59849 invoked by uid 99); 19 Aug 2009 00:44:57 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Aug 2009 00:44:57 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of yseeley@gmail.com designates 209.85.220.222 as permitted sender) Received: from [209.85.220.222] (HELO mail-fx0-f222.google.com) (209.85.220.222) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Aug 2009 00:44:46 +0000 Received: by fxm22 with SMTP id 22so3634581fxm.9 for ; Tue, 18 Aug 2009 17:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=pisnB1Tfh4UKsGY8PdDI65Ya8eEskCPUiPVWMTUkflQ=; b=DXDhSk74hza8FITnVxXf6OWYxDiySvbMAfp+5++zQm1YsL3kAt6BNksOmXKVCz8EY5 qjpsknvE5NiniaWMJOqxRRkZB2yM6qKgZ0v9YlKLq2O+YIy9XudcyvqxGurey+9IvXpt QF8ZTYVmOL17M0xVRJvnreuWSUs/jnU7Em5pc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=Yz3wbrtZiR99tkKZBZVY7MN6ON7pVp3liNw4CK2Xsy8MPtn/QqrrGtd3R/jxOBAzkJ wxH0wo1igo54Az5v740r/02EfzoHUu28HAhUYsSOycPJcz/QnXNErhfEx7K3VTVoaoQz LP0XWT8k0dAO6nl9Vez91EyN1HbP+NOwg9jgw= MIME-Version: 1.0 Sender: yseeley@gmail.com Reply-To: yonik@lucidimagination.com Received: by 10.216.53.207 with SMTP id g57mr1438578wec.3.1250642666439; Tue, 18 Aug 2009 17:44:26 -0700 (PDT) In-Reply-To: <4A8B40EF.9040400@gmail.com> References: <4A84784B.1050401@gmail.com> <4A8B40EF.9040400@gmail.com> Date: Tue, 18 Aug 2009 20:44:26 -0400 X-Google-Sender-Auth: 01903405d76ae697 Message-ID: Subject: Re: attribute thoughts From: Yonik Seeley To: java-dev@lucene.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On Tue, Aug 18, 2009 at 8:01 PM, Michael Busch wrote: > On 8/14/09 9:23 AM, Yonik Seeley wrote: >> Another thing I was wondering about was the opacity of State - one >> can't inspect or change the attributes w/o restoring it first. >> Undesirable limitation, or feature allowing more flexible state >> implementations? >> > > Excellent point! This limitation is currently there to discourage changing > values of > a state, because that would be rather inefficient: you'd have to lookup the > attribute(s) > of each state you want to change. Yeah, but restoring state also involves looking up attributes... so if one is going to skip around a cached list of States (tokens), it can still be more efficient to not restore each. -Yonik http://www.lucidimagination.com --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org For additional commands, e-mail: java-dev-help@lucene.apache.org