phpjs/_octopress/source/functions/putenv/_comments.html

php.js offers community built php functions in javascript

<!-- Generated by Rakefile:build -->

<strong>
<a href="http://an3m1.com/" rel="nofollow">??????? ? ??????</a>
</strong>
on 2012-03-22 13:55:58 <br />
New and exclusive news and new articles in the world of Rate 
<hr />


<strong>
<a href="http://kevin.vanzonneveld.net" rel="nofollow">Kevin van Zonneveld</a>
</strong>
on 2009-09-04 18:38:30 <br />
If I was only creating the functions I needed. This site would have 6.

But looking at the site's stats, apparently there are many people out there that use many more.

You also have to think about people using these functions in non-browser environments like node.js &amp; rhino.

Anyway. My point is: who are we to decide who is to use what. So it's a lot easier for us to just go ahead &amp; port everything, and let the user decide what to pick.

Remember. You can compile your own packages.
<hr />


<strong>
<a href="http://brett-zamir.me" rel="nofollow">Brett Zamir</a>
</strong>
on 2009-08-30 03:35:27 <br />
Is it silly to have an environment variable or putenv() function in PHP? If you think so, fine, but we are just letting our users decide what aspects they wish to port over.

And I see no intrinsic difference between needing an environmental variable in PHP and one in JavaScript especially with uses of JavaScript going beyond far beyond client-side HTML only (and our adding it in JavaScript is hardly adding much overhead nor is it a black box); this function can be made to work with other functions, as setlocale() already does--it's not just making an environmental variable that does absolutely nothing.

And no one is compelling anyone to use a function they don't want to, nor is this function even a part of the default package... I fail to see how one not-so-useful function (if this even is one) is affecting the rest of the library. I'd understand if you were talking about something like phpcredits() (we have that under experimental for the heck of it--sometimes one just does something &quot;for the heck of it&quot;, you know--call it art, boredom or whatever), but this does actually have a potential use.

If the PHP community feels it warranted to deprecate some items, we have moved such functions into our experimental section. Otherwise, there's nothing that makes me want to scream more (and thus I don't want to be someone who does this to others) than developers who confidently make abrupt decisions for everyone as far as what aspects of an already well-established API are &quot;good&quot; and which are not, and thereby limiting my and everyone else's creative choices. Let me as a user decide which is good and which is not, unless it really is a practice which is really likely to harm me (e.g., register globals) or encourage me to really make a big mess of things (e.g., an unfettered goto).

I hope my tone is not harsh when I say this (and this is not my library anyways), but I don't care so much about what the &quot;cool crowd&quot; is doing and would rather have fun and do what is convenient or interesting for myself and others--letting a rationale, constructive, and friendly dialog decide this rather than a dogma-by-silent-consensus and fear of going against the grain masquerading itself as &quot;best practice&quot;. One can learn a lot more by seeing through one's own eyes in avoiding fears of what others think (and that is another stated purpose of Kevin's library--for students)--something which is helped along by a supportive atmosphere such as Kevin has engendered...

Some poorly implemented functions, on the other hand, could definitely, if unfairly, ruin the impression of the library for some (one reason we really need to get more tests in place and debug older functions), but this is, I think, a wholly different issue. If someone is so afraid of what others think that they will let one &quot;silly&quot; but accurate port cause them to forgo choosing from 400-500 other potentially useful and independent functions, then that is just, imho, a loss for them.

But feel free to contradict me if you can offer some concrete reasons that I've missed...
<hr />


<strong>
run
</strong>
on 2009-08-29 15:06:19 <br />
You know, with stuff like this, this whole library is just starting to get silly.

C'mon guys, get serious...
<hr />