Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <5166B552.3060107@cord.dk>
Date: Thu, 11 Apr 2013 15:06:26 +0200
From: Daniel Gruno <rumble@cord.dk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: svn commit: r1466669 - /httpd/httpd/branches/2.4.x/STATUS
References: <20130410210152.1EFA423888FE@eris.apache.org>
 <5165D7D5.8010200@apache.org> <51668AD0.2050502@cord.dk>
 <51669165.6000101@apache.org> <516693FE.7060003@cord.dk>
 <5166AE5B.2080405@apache.org>
In-Reply-To: <5166AE5B.2080405@apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 04/11/2013 02:36 PM, Guenter Knauf wrote:
> On 11.04.2013 12:44, Daniel Gruno wrote:
>> it's a userdata object, so you can't iterate over the key/value pairs,
>> you can only access the values directly if you know the key.
> I was hoping that its possible to create a table from the userdata with
> some Lua magic, and then iterate over the table ...
> 
> oh, and some more questions:
> whats the benefit of having banner(), port() and started() as functions
> (or methods)?
> isnt it fine accessing these like f.e. r.filename?
> r:put(r.banner) would be even shorter than r:put(r:banner()) ...
> 
> and why is it:
> r.module_info(module_name)
> and not:
> r:module_info(module_name)
> 
> ??
> 
> 
I'll look into adding them as variables instead :)

r.module_info is because it doesn't need the request_rec object to get
module information (foo:bar(baz) is short for foo.bar(foo, baz) ).

I admit, it can be a bit confusing, and perhaps we should consider
turning it into r:module_info for the sake of conformity, but I don't
consider it a bug or anything that would stall a backport.

With regards,
Daniel.