>> looks like it was more than a suggestion, since you went ahead and >> committed >> the changes despite the comments from philippe and I. > > > Not quite so. I've committed the current state of things, matching the > documentation and tests.
oh, sorry if I didn't catch everything. I didn't look any further than this > Log: > 1) Apache::Connection changes [Stas, "Fred Moyer" <fred > /about/taperfriendlymusic.org>] > readwrite => readonly: > pool, base_server, local_addr, remote_addr, remote_ip, remote_host, > aborted, local_ip, local_host, id, conn_config, sbh, bucket_alloc to see that, at least in this bunch, philippe and I specifically didn't agree that lots of those fields should be read-only. > >>> If you think some method should be settable, come up with an example >>> where it'll be useful, >> >> >> >> I believe we did that in all cases where we wanted to maintain >> writability. > > > definitely far far away from all cases. ok, I had something long-winded that I've since removed (for the better, I'm sure :) the short of it is that both sides are in the same boat - I could just as easily ask for you to give me examples of why writability for these fields is dangerous and, short of that, insist that they remain open. but to do so (in either direction) simply wastes more cycles. really, we don't need to be micromanging the project like this, and to do so is very unhealthy overall. so, with the read-onlyness already committed, I'll appeal only once again. I think some of these fields would be useful, for reasons I've outlined earlier in the thread. while the "no special ap_ accessors" argument is a good idea in general it doesn't apply to record structure fields, where almost no slot has an ap_ accessor/mutator (see r->no_cache which is right next to r->no_local_copy). so, you can either rely on the intuitions of your fellow commiters as to the utility of the writability of these functions or not. > Yes, we did and that's what happening so far (in case you were following > the development in the API docs area). For the moment a method is either > supported or not, as a whole, not partial functionality. > > We weren't talking about the more granular unsupported functionality. ok, I guess I was assuming that. sorry. > I suppose we could introduce that more granular unsupported feature, > when for example the settability of some method could be marked as > experimental. But we can just as well do that in one of the releases > following 2.0. How does that sound? by saving it until after 2.0 you're locking out a potential audience for the feature. to quote: "the success of mod_perl is being able to solve the problems right away" :) while I may not being using it in the context you were, I think it hold true here - I think it is perhaps more harmful to close off parts of the API we don't fully understand than to close them off. closing them off arbitrarily gives users the impression that there is a well-researched reason why they can't use them, and discourages them from investigating their utility themselves. sure, using some of the methods we have not researched may cause users a few segfaults or other undesirable consequences. but the history of mod_perl shows us (or at least me) that users generally care less about features that are broken than they do about having access to the features they need so they can even see if the features do what they need. --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
