You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Geoffrey Young <ge...@modperlcookbook.org> on 2004/01/19 20:49:08 UTC
our beloved API...
moving to a new thread, since there are multiple issues in the other one...
> In most languages, defining class A methods in class B would not even be
> allowed, and I kind of wish it wasn't allowed in Perl either so we
> wouldn't have to have this discussion.
good thing Perl isn't most languages ;)
>> mod_perl is access to the Apache C API in
>> Perl - the more they look the same (and the more people that understand
>> this) the better.
>>
>>
>
> Obviously keeping these close is good for development of mod_perl, but
> no one is going to use mp2 if the API is confusing and difficult.
well, I don't think it's either, really. I'll grant you that there is a bit
of an initial learning curve wrt the module loading that at first feels
quite painful (remember my NYC talk started with how all this sucks :)
really, the API is quite nice: all request-time functions are $r object
methods. that's what makes the mod_perl wrapper for Apache as it exists now
so great - it's Perlish. doing something like
Apache::RequestUtil::is_initial_req($r) (or whatever variant) is not very
Perlish.
> Remember, most people programming mod_perl applications have never even
> looked at the C API, and I don't think there's anything wrong with
> that.
me neither. I do think they would understand it better if they looked at is
as a wrapper, though, but that's neither here nor there.
> Doug seemed to recognize that an easy Perl API is a necessity
> when he designed the simple filter stuff.
yes, and I think that's what users have now with $r.
granted, $r is not a typical Perl object, but it can't be - $r is the same
object throughout the entire request, which is odd in and of itself. it
also has no real constructor, especially in mp2 where Apache->request
doesn't always work. and you can't subclass $r's underlying class the same
way you can normal Perl objects.
but I think all of this is ok - persistent, complex environments like
mod_perl have their quirks. and, as I said before, there isn't much
different here than there was in mp1 wrt classes that add methods to $r,
just a bit more of it.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: our beloved API...
Posted by Stas Bekman <st...@stason.org>.
Perrin Harkins wrote:
> Stas Bekman wrote:
>
>> I don't have much to comment on these issues. I'm not going to repeat
>> again and again why the separation into multiple modules is important.
>
>
>
> I don't think anyone would have a problem with the multiple files, if we
> can just hide that unexpected complexity from end users.
+1
>> It may be unimportant to many users, but we aren't going to take it
>> away from those who need the ultimate performance.
>
>
>
> My suggestion about autoloading would not take away anyone's ability to
> preload things. It would help people who are not sure what they need
> yet though, and avoid worrying about what to preload until you are ready
> to do performance tuning.
please re-read my reply to this earlier suggestion of yours. In order to use
AUTOLOAD'ing you need to load that module that contains the wrappers first. It
[Apache::RequestRec] is not loaded by default and it won't be loaded by
default because it is not always needed. That means that the user still needs
to load something. And that's where my wrapper suggestion [Apache::whatever]
comes in.
>> Granted we want to make simple things easy and complicated possible.
>> And that's exactly why I've suggested to create another easy layer for
>> those users who don't care about saving a few msecs here and there and
>> don't care about a few hundreds extra k's of memory wasted. Why don't
>> you like that suggestion?
>
>
>
> Because it's not transparent. People still have to think about what
> they are going to load in a very early stage, and they still need to
> know which files (or import sets) the methods they call on $r are
> defined in. If they get it wrong, their program will die.
IF they call preload_all_modules() at the server startup, it'll just work.
> It also doesn't address the docs issue.
That's a good point. But this is an easy problem to solve. For example,
methods in other manpages can be cross referenced. e.g.:
Apache::RequestRec
TOC
Methods living in this package
...
Apache::RequestRec Methods living in other packages
...
...
I'm sure we can come up with some other good ideas.
OF course what you seem to be advocating is to throw all Apache::RequestRec
Methods in one package and therefore it solves the loading problem and the
documenation at once.
> With an autoload scheme, we can have a little app that tells you what to
> add to your startup.pl when tuning or we can have a flag that prints
> that info to the error log when it autoloads something. People can feel
> comfortable with the fact that their app will still work if they forget
> to preload something.
>
>> You want to preload all modules, go for it.
>
>
>
> I think that would be a better default than the current scenario, at
> least for $r (load everything by default, and have import options that
> load specific things instead), but autoload seems like a better
> compromise. And this doesn't address the docs issue either.
Where do you put the limit? You suggest to load all modules for $r, but many
modperl modules need many other modules, to work on $s, etc. You have one need
someone else will have another need for what needs to be loaded by default. I
see no better solution than loading everything by default and having a config
option which will prevent this from happening. So you will start with a
working mp2 no matter what, just like it was mostly for mp1 (minus several
modules that you *did* have to load before you could use them, like Apache::Log)
> Is there a technical reason why autoloading the $r methods wouldn't work?
IMHO, there is no need for it. You either want to fine tune and you load only
what you need. Or you don't care and you load them all. I fail to see why do
we need to complicate things any further.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: our beloved API...
Posted by Perrin Harkins <pe...@elem.com>.
Stas Bekman wrote:
> I don't have much to comment on these issues. I'm not going to repeat
> again and again why the separation into multiple modules is important.
I don't think anyone would have a problem with the multiple files, if we
can just hide that unexpected complexity from end users.
> It may be unimportant to many users, but we aren't going to take it
> away from those who need the ultimate performance.
My suggestion about autoloading would not take away anyone's ability to
preload things. It would help people who are not sure what they need
yet though, and avoid worrying about what to preload until you are ready
to do performance tuning.
> Granted we want to make simple things easy and complicated possible.
> And that's exactly why I've suggested to create another easy layer for
> those users who don't care about saving a few msecs here and there and
> don't care about a few hundreds extra k's of memory wasted. Why don't
> you like that suggestion?
Because it's not transparent. People still have to think about what
they are going to load in a very early stage, and they still need to
know which files (or import sets) the methods they call on $r are
defined in. If they get it wrong, their program will die. It also
doesn't address the docs issue.
With an autoload scheme, we can have a little app that tells you what to
add to your startup.pl when tuning or we can have a flag that prints
that info to the error log when it autoloads something. People can feel
comfortable with the fact that their app will still work if they forget
to preload something.
> You want to preload all modules, go for it.
I think that would be a better default than the current scenario, at
least for $r (load everything by default, and have import options that
load specific things instead), but autoload seems like a better
compromise. And this doesn't address the docs issue either.
Is there a technical reason why autoloading the $r methods wouldn't work?
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: our beloved API...
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
[...]
> as for your earlier suggestions, I was waiting for stas to comment on them.
I don't have much to comment on these issues. I'm not going to repeat again
and again why the separation into multiple modules is important. It may be
unimportant to many users, but we aren't going to take it away from those who
need the ultimate performance.
Granted we want to make simple things easy and complicated possible. And
that's exactly why I've suggested to create another easy layer for those users
who don't care about saving a few msecs here and there and don't care about a
few hundreds extra k's of memory wasted. Why don't you like that suggestion?
You want to preload all modules, go for it.
You want to preload all $r modules, go for it too. We can provide easy
wrappers that will do all that preloading for you. It's just a matter of
designing an intuitive API.
It doesn't have to be black or white.
This way everybody is happy and everyone can decide what's the best for them.
The only, but, is that we don't want these wrappers to be used in CPAN
modules. Exactly because we want to be able to control what's loaded and what not.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: our beloved API...
Posted by Perrin Harkins <pe...@elem.com>.
Geoffrey Young wrote:
> I don't think so. beneath it all each object method needs access to the c
>
>request_rec, and $r needs to keep its singleton nature. which doesn't mean
>you can't subclass it, you just need to use the bless { r => $r}, $class
>syntax. that's what I meant by "the same way you can normal Perl objects" -
>subclasses have a non-standard syntax.
>
>
>
I typically call the superclass constructor and then re-bless the
result, or else simply inherit the constructor completely. Those
approaches would still work, wouldn't they?
>>I always thought it was pointlessly dangerous to subclass $r in mp1, but
>>I know people did it with alarming frequency.
>>
>>
>
>I've never seen it be dangerous, though I suspect it could be abused. but
>it's also amazingly powerful
>
>
I just mean that people sometimes seem to subclass and create an "is a"
relationship when a simple "has a" relationship (a pointer from some
other object) would work just as well.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: our beloved API...
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Neither is loading a bunch of modules that you don't actually access
> directly,
well...
> or using a program to look up where the docs for the method
> you're calling are. There are basic expectations that programmers have
> about when they need to load things and where they can find docs, and
> these are being foiled right now.
I agree totally with that. yet another thing that I thought sucked :)
> Incidentally, is there a decent tutorial for the apache 2 C API
> anywhere? The stuff I found on httpd.apache.org was pretty thin.
not that I know about. ryan bloom's book I think is the closest, but I've
not read it.
> I'm not complaining about $r, but rather about the inconsistency between
> calling the methods on Apache::RequestRec but loading them and reading
> their docs in other classes..
the docs are definitely an issue.
>
>> granted, $r is not a typical Perl object, but it can't be
>>
>
> I don't understand why.
well, for one it's singleton-esque, which makes it kinda unique.
>
>> and you can't subclass $r's underlying class the same
>> way you can normal Perl objects.
>>
>>
>
> Why not? Because of the stuff I'm complaining about?
I don't think so. beneath it all each object method needs access to the c
request_rec, and $r needs to keep its singleton nature. which doesn't mean
you can't subclass it, you just need to use the bless { r => $r}, $class
syntax. that's what I meant by "the same way you can normal Perl objects" -
subclasses have a non-standard syntax.
>
> I always thought it was pointlessly dangerous to subclass $r in mp1, but
> I know people did it with alarming frequency.
I've never seen it be dangerous, though I suspect it could be abused. but
it's also amazingly powerful
>
>> there isn't much
>> different here than there was in mp1 wrt classes that add methods to $r,
>> just a bit more of it.
>>
>>
>
> No, there's tons more of it, and unlike mp1 it is for methods that
> people actually will need to use. The stuff in mp1 was pretty obscure.
:)
as for your earlier suggestions, I was waiting for stas to comment on them.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: our beloved API...
Posted by Perrin Harkins <pe...@elem.com>.
Geoffrey Young wrote:
>>In most languages, defining class A methods in class B would not even be
>>allowed, and I kind of wish it wasn't allowed in Perl either so we
>>wouldn't have to have this discussion.
>>
>>
>
>good thing Perl isn't most languages ;)
>
>
>
There are some legitimate uses for this feature (autoloading, code
generation), but the key is to hide all this from users of the API.
>I'll grant you that there is a bit
>of an initial learning curve wrt the module loading that at first feels
>quite painful (remember my NYC talk started with how all this sucks :)
>
>
Right. I think it should not suck. :)
>really, the API is quite nice: all request-time functions are $r object
>methods. that's what makes the mod_perl wrapper for Apache as it exists now
>so great - it's Perlish.
>
That's fine with me. What I want is to put all the docs for those
methods in Apache::RequestRec's POD, and not require users to load any
other modules to get access to them. I think the approach I outlined in
the other thread would work for the latter. I don't enough about how
the doc generation works to know what's required for the POD.
> doing something like
>Apache::RequestUtil::is_initial_req($r) (or whatever variant) is not very
>Perlish.
>
>
>
Neither is loading a bunch of modules that you don't actually access
directly, or using a program to look up where the docs for the method
you're calling are. There are basic expectations that programmers have
about when they need to load things and where they can find docs, and
these are being foiled right now.
>>Remember, most people programming mod_perl applications have never even
>>looked at the C API, and I don't think there's anything wrong with
>>that.
>>
>>
>
>me neither. I do think they would understand it better if they looked at is
>as a wrapper, though, but that's neither here nor there.
>
>
Incidentally, is there a decent tutorial for the apache 2 C API
anywhere? The stuff I found on httpd.apache.org was pretty thin.
> I think that's what users have now with $r.
>
>
>
I'm not complaining about $r, but rather about the inconsistency between
calling the methods on Apache::RequestRec but loading them and reading
their docs in other classes..
>granted, $r is not a typical Perl object, but it can't be
>
I don't understand why.
>and you can't subclass $r's underlying class the same
>way you can normal Perl objects.
>
>
Why not? Because of the stuff I'm complaining about?
I always thought it was pointlessly dangerous to subclass $r in mp1, but
I know people did it with alarming frequency.
>there isn't much
>different here than there was in mp1 wrt classes that add methods to $r,
>just a bit more of it.
>
>
No, there's tons more of it, and unlike mp1 it is for methods that
people actually will need to use. The stuff in mp1 was pretty obscure.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org