perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject Re: [mp2] Report on mp2 accessors in
Date Thu, 12 Aug 2004 20:02:08 GMT

>> 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/>]
  >     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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message