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.
Please, "autoload program". I still don't see the use for implementing this in Pike. In case of the security features in Pike, if a user can execute the pike executable himselfs, that is easily circumvented, in the other case, running unsafe code dynamically loaded from users input, the security system is better set up in the application, to the application's needs. Regarding adding stuff to the module path, that can be done in a much more generic way by setting environment variables in the same way as you set the search path for a shell.
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.
But would it not be a more general solution if the programmers in this case set their environment apropiately? In doing so they would have a single place for all parameters regarding the project, rather than having the pike parameters set in pike, the foo parameters set in foo, the bar parameters set in bar and so on?
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.
That was not the impression I intended to give, but in some cases there are solutions that hurt more than necessary. My opinion is that autoloaded programs is such a feature, obviously you don't share my opinion on it, and you have not convinced me on this point. Still, I'm not the person to make the final decission. If you want such a feature, please feel free to bring up a suggestion here with an elaborated description of how it ought to work with regards to semantics and/or syntax. Please use another subject line as people might have jumped this thread. If there are any serious complaints/comments/suggestions they will certainly be heard.
Yes, basically that was the original reason - given that the namespace partitioning is in effect. That would take care of possible compatibility problems.
Compatability problems in the namespace should be taken care of by the built-in compatability system in Pike. Compatability should only be used as an interim solution until the program has been fixed properly, and for that purpose the Pike version system is perfectly fine. There should be regression tests in the testsuit for older versions of the code using the compatability mode to ensure this works (although I don't know if this is the case yet). Using a site-local compatability setting would then cause developers of that site not to adopt to new concepts, since they are not confronted with them by having to actively select what version of Pike their code should run under. And if you want to make sure your Pike program works with later versions of Pike it's as simple as specifying an absolute version with the #pike pragma.
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).
That can and should be done using the Local module, rather than locally contaminating the global scope. (IMO)
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.
Out of curiosity, to you have one good example where this would be the case?
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.
Yes, I agree on that, and so do most Pike-developers afaict. That's why the behaviour of the latest version always is the default, unless the -V flag or the #pike pragma is present. You seem to argue against yourself here, since this last paragraph is a good reason not to have local compatability policies.
/ Mikael Brandström (ogg! ogg! ogg!)
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)