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 complexit
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 ca
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
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 g
> 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, a
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
