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.
I would not assume people to read the all necessary documentation, it would be naïve to do it.
Maybe so, but it's the right way IMHO.
-1.
/ Johan Sundström (risplockare)
Previous text:
2002-09-03 23:59: Subject: the Pike module system
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.
No, since those settings could be easily circumvented. Ploicy settings should not be set within a language, but rather by the operating system. Or might it be that we are talking about different kinds of policies?
It seems so. I have the pike security feature in mind, as well. Also, part of the policy might be the site-specific module locations, which could be set for all the programs executed on the machine by using add_module_path/add_include_path in the autoloaded module.
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.
I'm looking from the the point of view of a frequent Pike user, now and then writing programs which other people might have use for. I don't want to ge frequent questions why my script/hack/program doesn't work on a particular site, just because a site administrator has set up some brain-dead non-standard site settings for the Pike installation. Given the posibility of site-wide replacement of some global symbols, some administrator will at some point do such a replacement, which will in turn cause harm to the users of that system who expect a Pike program they dowload from the net themselfes to work.
I meant it more for environment (as in the example above) modification - search paths, some default values for resources, perhaps site-specific classes/objects. Sure, it can hurt if done in a stupid way, but it can help people working on site-wide projects where the programmers should share some resources/environment which have non-standard locations/values.
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.
I would not assume people to read the all necessary documentation, it would be naïve to do it.
Maybe so, but it's the right way IMHO.
oh, come on! What kind of bad karma if the docs make things clear?
Regardless of how good the docs are, there will be people who don't read them and will cry out loudly on the mailing-list that it doesn't work, and such things will be found by google et. al. That's sort of a sad fact.
Yes, it is - just as a language with no choices would be. I cannot help having the impression that you want to provide one and only way for the users to follow. And I don't like that vision, but it's just me, I guess.
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.
True, but how do you check if a module is loaded? As I've stated elsewhere, and you say yourself. Modules are always autoloaded. I don't get what you imply with "autoload". Is it systemwide import to the global namespace you want to achive?
Yes, basically that was the original reason - given that the namespace partitioning is in effect. That would take care of possible compatibility problems. Modules are autoloaded, but there might be a need to provide instances of some classes with site-dependent values (like site-wide object which gives some information to the programs running on the site).
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.;
Isn't the most widely understood Pike environment the default environment Pike supplies? What you are writing about could be useful in Hilfe though, but not interpreter-wide.
Pike ships with the most common-sense default settings, that's certain, but some sites might need different global environment (widely understood) than the standard one. It is easier to provide it by policy - i.e. set by the admin - than to force the users to make the changes to their programs.
Fourth, the autoload feature might be used by the site administrator to show some motd-like thing (a stupid example made up ad hoc :))
Yes, in Hilfe, not in Pike as such.
I've seen sites where even cc displayed a site-specific disclaimer... but that's not a very useful feature, sure - as I said, it was ad hoc.
Compatibility should be thrown away at some point, otherwise it doesn't make sense to introduce improvements.
I meant the #pike pragma och the -V option to the interpreter. That compatability should not be thorwn away, and is useful for running
yep, I agree.
legacy applications that has not been updated to current status of the language. I fail to see why this would make it uniteresting to introduce improvements?
Improvements should be accepted as the default behavior - the new code should use them, the old-time users should grow accustomed to them etc. etc. - if the old behavior is provided by default (i.e. the interpreter starts in the compat mode), then the improvements have a big chance of being ignored - just out of habit.
/ Marek Habersack (Grendel)