I don't see the point in providing site wide settings for this. Each Pike application might for some reason use a partially different namespace than the standard one. So let there be some method for it to define a namespace mapping, preferably only once and not in each source file. There might also be a reason for doing the mapping only once for a group of related applications.

But doing it on a site wide level would mean that all pike applications on the site are treated as a single group (unless those that doesn't use the site wide pike installation, of course). That strikes me as a totally arbitrary grouping; I see no reason to expect that all applications that happen to be installed on a site should want to use the same nonstandard namespace.

/ Martin Stjernholm, Roxen IS

Previous text:

2002-09-03 18:35: Subject: the Pike module system

---

...

...

that warning about clashes on the global level would be enough, but it might be useful if Pike warned about method arguments and local variables shadowing some global identifier.

No. Not per default, maybe if supplying a flag, like -Wclobber. I quite often overload lfuns (which are present globally) and I don't want Pike to complain on that.

Yep, that makes sense, sure.

...

...

...

should themselfs make sure they contain all dependencies they need. As nilsson said earlier, it would not be fun to every now and then get complaints to pike fora that certain programs fail miserably, just

I'm sorry, but I don't understand this argument. The impression I get is that you (plural) are promoting a language that is to resolve all the user's problems and, IMHO (and some people I talked to about the issue) Pike should stay a general purpose language that gives its users maximum flexibility in choosing the ways to solve one problem. As I said - the autoloading _feature_ would be fully under the control of the site administrator or the individual user - no upstream default autoloads, nothing like that. Why would such a _feature_ be bad?

There is nothing bad as such to the feature (other than that it's redundant in some sense). The problem is that given such a feature

It is very useful for site-wide policy setting - we've just talked about it on IRC, people seem to like the idea and find it useful.

...

programmers will start writing code depending on autoloaded modules,

that's ok, as long as it is a site policy. Pike docs should describe only the autoload feature, not that any modules are available through it. Don't assume all users are dummies.

...

or that certain compatability code has been run, etc. In doing so, the will make sure the program won't work unless that code has been

again, it's ok if it is a site-wide policy. Change the scale of your point of view - look at it from the site standpoint, not from the language implementor's standpoint.

...

run. The most common user will, when a script fails, not ask the administrator, but rather ask in relevant Pike fora, just to make the people in those fora reply "go blame your system administrator", and

That's what FAQ is for... Also, I assume that people will read docs - they should stress that relying on any modules being autoloaded is WRONG.

...

pike will get bad karma since people then find the people in pike fora unfriendly and non-helpful. I don't want this to happen. The good

oh, come on! What kind of bad karma if the docs make things clear?

...

thing with Pike is that it's a portable envirnoment in which you can be sure that the program works, given that the dependincies made explicitly in your code are met. These explicit dependencies will be even easier to trace given a hierarcical third party module tree with clear delegations -- and people on the lists can give the more informative answer: Check the pike module repository for that and that module, install it and it will work.

Anything unclear in that?

No, it's perfectly clear, but I've got a feeling that I didn't make myself clear enough. This is only a feature, not a way to free users from checking whether the module they need is loaded, that's first. Second, pike loads the modules on demand - your hypothetical situation will have no place, because if some module isn't auto-loaded, it will be loaded when the user accesses it for the first time. Third, the autoload feature is good for setting up some kind of widely understood environment - setting some site-specific variables, setting up security contexts etc.; Fourth, the autoload feature might be used by the site administrator to show some motd-like thing (a stupid example made up ad hoc :))

...

...

Let me give you one ad-hoc example - what if the administrator was able to autoload a simple module, loaded each time pike is used, which would set the default security settings? Resource limits, pike security - anything?

That's really nothing that should be done in Pike, especially since a user can upload his own pike to the system and easily circumvent such things.

Come on, that can be avoided _easily_ by a half-experienced programmer and is really of no importance here. And pike-security cannot be set up outside of the pike context.

...

No, to be honest, I don't see any use for your autoload feature. Especially if the hierarcical delegated module system becomes a reality. If any module is moved within the base modules of pike, that should be reflected in the current compatability system.

Compatibility should be thrown away at some point, otherwise it doesn't make sense to introduce improvements.

/ Marek Habersack (Grendel)