>>> connection, canonical_filename, header_only, main, next, prev, >>> pool, per_dir_config, request_config, proto_num, protocol, >>> request_time, server, the_request, unparsed_uri >> >> >> opening up $r->request_line() is probably acceptable. I'd also consider >> protocol and maybe proto_num (after researching what it is), >> unparsed_uri, and perhaps header_only. but that's about all. >> >> thoughs from other devs? > > > I think one of the biggest gains I made as a programmer was when I > overcame the mental block of what you could do with writing to 'read > only' methods. I know I was one of the people who suggested that those > methods be read only - in retrospect I think that was a big mistake, and > I have regretted it ever since I broke through that mental block.
:) > > I would suggest making them _all_ read write :) You can do so much > cool stuff with the API, and I'd rather see it break because someone was > pushing the limits, rather than having to say "we don't allow that > because it might break". > > my $0.02, for what it's worth :) appreciated :) some of those fields, though, are really messy. for example, per_dir_config is an internal httpd configuration vector, so to set it properly we'd probably need a whole new typemap entry. and there's no reason you'd ever want to mess with it since we have an interface to all the custom config stuff already. similar for something like write access to a $r->pool - that's just no good no matter how you look at it :) I think making logical things like header_only or request_line writable is good for subverting when we know better, but that's because they represent attributes of the request we'd be interested in faking. making something like $r->next() writable makes far less sense, since it represents private httpd bookkeeping that could have core-dump like effects. things like $r->server() or $r->connection() would be ok, but you'd really want to set those to your own subclass I'd think, not things at random. I'd have to mull that one over. anyway, for the fields I've mentioned, making them writable is just flicking the appropriate flag in apache2_structures.map (see ModPerl::MapUtil for an explanation) and I guess adding some basic tests to make sure things don't blow up when you try to write to them. low-hanging fruit :) --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
