perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [Patch mp2] PerlSections namespace
Date Wed, 10 Dec 2003 21:02:38 GMT
Philippe M. Chiasson wrote:
[...]
>>>>You mean it will break their code. In which case I'd suggest not to commit

>>>>this patch till you get it all ready.
>>>
>>>
>>>Yeah, well, things are already broken quite a bit w/r to <Perl >
>>>sections, so I wanted to fix a problem at a time, even though if it
>>>temporarely introduces another little different problem.
>>
>>Yes, but your change is going to introduce a new problem, and if it's not 
>>fixed by the time of the new release, it'll break people's code which worked 
>>fine with the previous release. Not too friendly, hey? And I think we should 
>>do a new release rsn. What do you think?
>  
> You are quite right about this. Especially with a release on the
> horizon. In that case, I'd lean towards solution #1, easily achieved by
> having PerlSections iterate over symbols in the generated namespace AND
> %Apache::ReadConfig on each pass. This ends up being just like before,
> and would fix recursive <Perl > section problems as well.

What about doing #3 - at the end of each block feed it to Apache and somehow 
mark that block as processed, so it won't be rerun again? e.g. by moving the 
symbols into a special package, which is not ReadConfig?

>>I think you also have a problem of ordering thing. As you may end up with 
>>overriding order problem, no? I think 1 is safer and making it deprecated will 
>>eventually make the problem go away completely. Am I correct to say that 
>>people don't need to work directly with Apache::ReadConfig? I think the only 
>>place this is needed when people mix config with non-config perl code in 
>><Perl>, so that they need to switch 'package Apache::ReadConfig;' to start 
>>feeding things into the config.
> 
> 
> As far as I can tell, now that we have Apache::Server->add_config, I'd
> be more than happy to deprecate direct usage of the
> %Apache::ReadConfig:: namespace.

As you can see in the other sub-thread, it's not going to be simple.

> Ordering as of today is still a problem anyways (in Location,
> VirtualHost and other containers). In mp1 we were using Tie::IxHash to
> work around this, and I am planning on doing the same thing in the near
> future to address that problem.

That's good.

>>OK, but I can still see how it it breaks. Consider:
>>
>>foo-/baz => foo_baz
>>foo/-baz => foo_baz
>>
>>whereas this works:
>>
>>foo-/baz => foo_::baz
>>foo/-baz => foo::_baz
>>
>>I think you shouldn't replace groups of chars with a single _, you must 
>>preserve the lent
> 
> 
> Correct, I didn't realize that. One question I have though is for win32.
> 
> Would it be 100% safe to :
> 
> 1. replace occurences of '/' and '\' (path separators) with '::'

careful here, as you have \\ too, you don't want to end up with ::::

> 2. replace non alphanumeric with '_'

if you assume 1:1, then yes (length doesn't change)

> 3. insure resulting package doesn't start with '::' or numeric

rather check that it starts with alpha or '_' ;)

> I know File::Spec would be the nicest way of going around doing it:
> 
> my $name = join('::', File::Spec->splitpath($filename));
> $name =~ s/[^a-zA-Z0-9]/_/g;

absolutely ;)

[...]
>>I don't think there is a good solution here, as you apply a lossful 
>>transformation. We have the same problem with registry, but nobody has ever 
>>complained, since most files include alphanumerics only.
> 
> 
> So, can we agree on what will agree to be doing ? Then I'll be happy to
> write it, stick it in modperl_util.c, expose it thru ModPerl::Util (for
> registry) and use it for PerlSection's namespaces

I think your proposition above is fine. (it's the same as the alg used by 
RegistryCooker, just reproduce it from that perl code 1:1).

__________________________________________________________________
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


Mime
View raw message