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?
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.
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.
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.
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?
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.
See above.
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.
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.
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 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?
/ Mikael Brandström (ogg! ogg! ogg!)
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)
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)
Previous text:
2002-09-03 23:43: 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?
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.
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.
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.
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?
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.
See above.
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.
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.
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 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?
/ Mikael Brandström (ogg! ogg! ogg!)
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)
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)
I do realize people don't read docs, all to well, it's just the docs are always the place to point out, something to "cover your back".
/ Marek Habersack (Grendel)
Previous text:
2002-09-04 13:37: Subject: the Pike module system
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)
And my firm position is that we had better avoid having to cover our back altogether.
/ Johan Sundström (risplockare)
Previous text:
2002-09-04 16:55: Subject: the Pike module system
I do realize people don't read docs, all to well, it's just the docs are always the place to point out, something to "cover your back".
/ Marek Habersack (Grendel)
sure, but you cannot forsee nor avoid all problems, you can do another thing, though - write good docs. There will always be people misusing or abusing software, that cannot be cured - it's good to have docs then to be able to tell them to kindly RTFM.
/ Marek Habersack (Grendel)
Previous text:
2002-09-04 17:01: Subject: the Pike module system
And my firm position is that we had better avoid having to cover our back altogether.
/ Johan Sundström (risplockare)
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.
They already can - just patch the master program, for instance.
/ 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)
pike-devel@lists.lysator.liu.se
-
Johan Sundstr�m (risplockare) ＠ Pike (-) developers forum -
Marek Habersack (Grendel) ＠ Pike (-) developers forum
-
Mikael Brandstr�m (ogg! ogg! ogg!) ＠ Pike (-) developers forum