Personally I would want to have an audit log of emails on production. That
actually is probably more important to me than non-production environments :)
On Jan 27, 2012, at 1:37 AM, Martin Jansen wrote:
> Is there any intention behind enabling the mail.add_x_header
> configuration directive in
On Thu, May 14, 2009 at 10:05 AM, Pierre Joye wrote:
> Hi,
>
> On Thu, May 14, 2009 at 6:21 PM, Ilia Alshanetsky wrote:
>> We have a fair number of fixes in the 5.2 branch already and while 5.3 is
>> making very good progress I think it is still ways off in terms of final
>> release and stabiliza
To me, it basically creates some laziness and reintroduces a vector on
the register_globals issue.
I've been using $_GET $_POST $_COOKIE $_SESSION $_SERVER etc. since
they were introduced, and have never had any problems. Was there a
reasoning behind making a variable that essentially glues them a
On Thu, May 14, 2009 at 3:03 PM, Nathan Rixham wrote:
> bc? all the reasoning in the world won't justify it to 1 million businesses
> running php 4 code which is reliant on $_REQUEST behind the scenes.
>
> although it would generate a tonne of freelance work :p
that code has to change for 5.3 or
I think this strikes a good balance between backward compatibility...
I would hope though the code for it is very simple, to not add
overhead to PHP. Basically in PHP the pseudocode equivalent would be
if(ini_get('reigster_request') == true) {
$_REQUEST = array_merge($_GET, $_POST, $_COOKIE, $_
On Fri, May 15, 2009 at 1:32 AM, Lukas Kahwe Smith wrote:
>> The more stuff like this we remove, the harder it becomes for people to
>> quickly move to newer, faster and more secure versions of PHP. That
>> causes way more frustration for everyone than a few "ugly" legacy
>> features. If there
On Fri, May 15, 2009 at 1:25 PM, Lukas Kahwe Smith wrote:
> Confusing new code is totally different from breaking existing code.
True but aren't some changes in 6.0 at least (and possibly 5.3) going
to require code changes? Or is it still going to be "legacy enough" ?
There's gotta be a time in
On Mon, May 18, 2009 at 4:38 AM, Christian Schneider
wrote:
> There's a big difference between changing some rare features (and no,
> 5.3 needs - almost no to - no changes with the code bases I know) and
> removing something *everybody* uses.
>
> Apart from the fact that _REQUEST is not evil per
On Mon, May 25, 2009 at 1:38 PM, Ilia Alshanetsky wrote:
> Neat idea. Why not open the sqlite db at MINIT rather then RINIT and add a
> whole pile of overhead to every request.
>
>
> Ilia Alshanetsky
Also:
Pinba is something else that might be interesting to look into.
http://pinba.org
http://g
Succinct and great reply.
Better webserver: nginx :)
#3 is probably the most important piece.
I'd like to also note scaling php is pretty simple. Scaling out
typically provides better results as opposed to scaling up. Scaling
your datastore will always be your pain point. Adding new data no
On Sep 18, 2012, at 5:00 AM, Paul Dragoonis wrote:
> Yep, I see where my suggestion for filter_var() isn't relevant.
>
> I use symfony2's ecaper in the PPI\Templating\ component, and really like it.
> Zend2's also seems pretty good.
>
> It'd be nice to have this available as a ./ext/spl/ class
Also as there is also htmlspecialchars() which most people use for escaping
this seems like a better, more centralized functionality and better
nomenclature for escaping on output in general with options for various types
(and should just be utf-8 by default :))
--
PHP Internals - PHP Runtime
> It feels like this is just using classes for the sake of using
> classes, adding an unnecessary layer of complexity (and discussion)
> for no real reason except that is the RFC authors preference.
+1
First the discussion was filtering vs escaping. Now it is about how to
implement it as a clas
On Wed, Sep 19, 2012 at 9:08 AM, Andrew Faulds wrote:
> Yes, but typing the encoding every time is cumbersome. Or, if you don't want
> to set it every time, you'd have to set it globally. Then, you forgot to
> change it back somewhere when you're dealing with multiple encodings, and it
> all goes
On Wed, Sep 19, 2012 at 9:16 AM, Lars Strojny wrote:
> There seems to be a need for a procedural API. As their is one, let’s do it
> similar to how MySQLi etc. does it and use a context resource:
>
> $ctx = escape_context_create('UTF-8');
> $str = escape_html_attr($ctx, $str);
why bother with t
On Wed, Sep 19, 2012 at 9:21 AM, Michael Stowe wrote:
> Andrew, I'm the biggest advocate of OOP out there, but the purpose of this
> is to provide a nice convenient layer for all developers to use to properly
> escape code and increase security within their applications. As such, we
> need to ca
On Wed, Sep 19, 2012 at 10:11 AM, Andrew Faulds wrote:
> Please explain in detail how object-oriented code obfuscates, complicates,
> murders baby kittens, etc.
Because a simple str_replace one line will become 6-10 lines of OO
code very easily?
Maybe you write "amazing" OO code, but the stuff
On Sep 19, 2012, at 10:22 AM, Andrew Faulds wrote:
> Again, "all the OOP code is a waste of time" doesn't really add anything to
> this discussion. Arguing against this being OOP, which I think is useful and
> requires, at most, one extra line ($x = new Escaper), is silly.
Arguing semantics ov
On Sep 19, 2012, at 10:55 AM, Pádraic Brady wrote:
> I have never once expressed a problem with this being a set of
> procedural function. Not once. The RFC offers some suggested function
> signatures. So nobody has expressed any issues and nobody has insisted
> that you be required to use a cla
On Tue, Sep 18, 2012 at 10:32 AM, Pádraic Brady wrote:
> Hi Michael,
>
> See the link near the bottom of the RFC - even htmlspecialchars() has
> unusual behaviour that's potentially insecure. I have no objections to
> there being functions, of course, and the RFC makes that clear.
> However, many
On 02/19/2013 11:22 PM, Klaus Ufo wrote:
> Hi there !
>
> We all know that the current PHP API has flaws. Maybe we could use namespaces
> to build a new coherent PHP API ? Like :
>
> - \arr
> - \num
> - \str
>
> and so on. Advantages :
>
> - no more global functions
> - separation of concerns
On Wed, Feb 20, 2013 at 3:23 PM, Wim Godden wrote:
> I agree that in most cases, that's a good thing. But it's also how we ended
> up with a thing called the Y2k problem : stuff running forever.
>
> Disclaimer : I've been developing with PHP since 1997, so I'm very fond of
> the language. "If it
On Feb 21, 2013, at 1:56 AM, Zeev Suraski wrote:
> There used to be a language that was the Queen of the Web. It was full of
> clever syntax. It prided itself on having a variety of expressive ways of
> doing the same thing. You're on the mailing list of the language that
> dethroned it.
Thi
On Thu, Feb 21, 2013 at 10:13 AM, Pascal Chevrel wrote:
> I am specifically thinking of Bugzilla which is already used by many open
> source projects. It has a lot more features than your current bug tracking
> system, it scales for large projects and it has a few Mozilla employees
> working full
+1 to named params. Please please please. :)
=> is my vote for syntax. Makes sense. Doesn't make sense to introduce another
way to express something we've been used to for years with key => value, and is
it that important to save one character per assignment?
On Sep 6, 2013, at 9:39 AM, Nikita
Andrei has turned the project over to me, and I am trying to keep it
going full steam ahead.
Rasmus told me the only thing stopping it from being adopted into PHP
or PECL was the license. That has now changed.
I don't believe it can be done in PECL, as it needs too many changes
in PHP core.
It w
On Fri, Jun 26, 2009 at 12:14 PM, Stanislav Malyshev wrote:
> Hi!
>
> It would be great if someone would examine the impact of adopting it
>> as the FastCGI SAPI replacement or looking at what hooks are required
>> to get it in and perhaps keep the "userland" stuff in PECL...
>>
>
> Why it needs
I can provide multiple machines as well from single chip dual core to
quad chip quad core...
Sent from my iPhone
On Jun 26, 2009, at 3:29 PM, Hannes Magnusson > wrote:
Hi all
Is there *anyone* who needs anything to be able to debug bug reports,
run sanitychecks, developing.. or whatever?
Namespaces in PHP are scaring me.
I can only imagine some of my developers creating code and using
namespaces - and how do you identify which namespace a function, class
or chunk of code is under?
It looks like you can define namespaces anywhere.
If I'm looking for a specific function, and it's
I think it would be a good idea to also include PHP-FPM in your investigation.
On Wed, Jul 1, 2009 at 11:02 AM, Gelu Kelunden wrote:
> Hi,
>
> I'm trying to understand how difficult it is to create a new SAPI, so I
> started to poke my nose inside the "cgi" SAPI source code. I saw that
> "cgi_main
(not
>>> php.ini or php-cgi.ini) should not be present in the pure CGI SAPI
>>> implementation, but in a different FastCGI-only SAPI.
>>
>> This seems to me as if it would be a step backwards. For a long time CGI
>> and FastCGI were highly separate setups; you had to
On Tue, Sep 8, 2009 at 8:58 PM, Stanislav Malyshev wrote:
> As for bundling libevent, I have no idea if BSD code can be put in php
> tree... It'd be much nicer if these chanegs were merged into libevent - it
> seems to be pretty alive, 3 releases this year.
That's what I've been saying. If it's s
On Wed, Sep 9, 2009 at 1:01 AM, Jani Taskinen wrote:
> Very good point. And I did consider only merging the _good_ parts of this
> thing. I haven't had time to check the code yet at all (quite busy at work
> right now) but there are some stuff it does we haven't generally considered
> the "job of
On Sat, Nov 21, 2009 at 9:16 PM, Arpad Ray wrote:
> However it would be a significant BC break, as old serialized session
> records would be unreadable after upgrading. We could mitigate this by
> providing a script to convert old session files.
I would say just a note saying "old session files
Antony - thank you so much! This is quite a surprise though, I didn't
know there were plans for this... I was talking to gwynne on IRC about
the best way to get this going.
I suppose it being a separate SAPI works, but I had also thought:
"What if it was just a modification to the FCGI SAPI, and
what version of PHP-FPM code is this based off of? the latest 0.6.x at
launchpad or one of the older patches?
we have had reports of some issues with php 5.3.x and php-fpm 0.6.x.
Andrei had changed the code from being a patch to being a standalone
daemon that builds against vanilla php sources for
On Mon, Dec 7, 2009 at 1:25 AM, Antony Dovgal wrote:
> That's the thing I want to avoid, actually.
> Moving something out of PHP just because you're afraid of its release cycles
> means you make it harder to maintain, not easier.
Even if it is just the management component of it?
Any of the PHP
On Mon, Dec 7, 2009 at 2:01 AM, Michael Shadle wrote:
> On Mon, Dec 7, 2009 at 1:25 AM, Antony Dovgal wrote:
>
>> That's the thing I want to avoid, actually.
>> Moving something out of PHP just because you're afraid of its release cycles
>> means you make
Sent from my iPhone
On Dec 7, 2009, at 5:57 AM, Jérôme Loyet wrote:
2009/12/7 Reinis Rozitis :
- See if the normal libevent or libev could handle all the needs and
not a patched copy anymore (or get with the libevent team)
Isn't this is allready done since 0.6.x fpm? Afaik php-fpm needs
For #2 it might no longer be needed that might be up for debate. It's
nice to be able to override a single option. But 5.3 with it's
htaccess/htscanner behavior might work good enough for most things
(but PHP_INI_SYSTEM might be still nice to override one offs instead
of having to point to
The problem with running a static amount of processes is trying to
figure out the right number. Also it is not elastic in any fashion.
Shared hosts would love the elasticity as it will allow sites to flex
up and down as needed without giving each individual user more
processes than they rea
2009/12/7 Jérôme Loyet :
so you're saying each worker just has a worker.name prefixed
worker.name = pool1
worker.user = nobody
worker.group = nogroup
worker.static.max_children = 5
worker.dynamic.max_children = 20
worker.dynamic.start_servers = 5
worker.dynamic.min_spare_servers = 5
worker.dynami
you're probably right. i mainly am only thinking of PHP_INI_SYSTEM and
things the user can't or shouldn't change themselves in .user.ini type
files or with things like htscanner (pre 5.3)
On Tue, Dec 8, 2009 at 2:47 AM, Pierre Joye wrote:
> hi,
>
> On Mon, Dec 7, 2
> On Tue, Dec 8, 2009 at 2:47 AM, Pierre Joye wrote:
>> Why would you need that given that we have host, path or .user.ini
>> support? Which has to be backported to FPM as far as I know.
> you're probably right. i mainly am only thinking of PHP_INI_SYSTEM and
> things the user can't or shouldn't
On Tue, Dec 8, 2009 at 10:57 AM, Stanislav Malyshev wrote:
> How real would be the case of 2 hosts in the same pool having same configs,
> but the same hosts in different pool having different configs?
I never though about that but I can tell you I use all my websites
under the same pool. I part
2009/12/9 Zeev Suraski :
> We should be using INI unless there are compelling reasons against it, now
> that this project becomes a part of the PHP source tree. As far as I can
> tell there are no such compelling reasons and it can actually map quite
> nicely into INI, hence, that's what we shoul
I see it more like:
fpm.global.daemonize = yes
fpm.global.error_log = /var/log/php-fpm.log
or skip global:
fpm.daemonize = yes
fpm.error_log = /var/log/php-fpm.log
for each worker pool:
fpm.worker1.name = pool1
fpm.worker1.address = 127.0.0.1:9000 ; or socket
fpm.worker1.uid = www-data
fpm.wo
2009/12/9 Jérôme Loyet :
> do you mean that it would be included in the global php.ini file ? I
> never imagine that. For me it's an independant conf file
> (/etc/php-fpm.conf for example).
correct. I don't see any reason for a different configuration file anymore
--
PHP Internals - PHP Runtime
2009/12/9 Jérôme Loyet :
> is there a way to include files ?
> include /etc/php-fpm/*.conf ? with one file per worker for example ?
>
> I think adding include to ini should not be a problem if it's not already
> done.
I would love to see the php ini file support includes like MySQL does.
Probab
2009/12/9 Olivier Hill :
> Hello Michael,
>
> Are you talking about this?
>
> --with-config-file-scan-dir=...
>
> http://www.radwin.org/michael/blog/2006/07/phpini_hacks_withconfigfil.html
oh, duh - I guess I am. Except it would be nice to have it inside of
php.ini itself and not defined at compil
On Tue, Dec 15, 2009 at 4:25 AM, Antony Dovgal wrote:
> Here we have time, pid, function and line.
> With log_level=debug all of them are printed, in other cases only time gets
> into the log,
> which makes perfect sense to me.
+1 to Antony and Jérôme.
Having a log format parameter seems a bit
NOTE: I just remembered there -is- a config-file-scan-dir option at
compile time. However, what about doing away with this and making it
inline in php.ini, the syntax can match mysql, as it uses ini files as
well.
This mainly will help with programatically creating PHP-FPM pool
config files, but c
at 21:47, Johannes Schlüter wrote:
>
>> On Wed, 2009-12-23 at 04:40 -0800, Michael Shadle wrote:
>>>
>>> NOTE: I just remembered there -is- a config-file-scan-dir option at
>>> compile time. However, what about doing away with this and making it
>>> inline i
On Wed, Dec 23, 2009 at 10:13 AM, Mikko Koppanen wrote:
> Hello,
>
> I think you can use PHP_INI_SCAN_DIR environment variable which should
> work runtime as well.
still seems a bit archaic. i don''t see any reason why include support
can't be added in php.ini. it will probably wind up becoming
On Wed, Dec 23, 2009 at 10:47 AM, Pierre Joye wrote:
> Please tell me one benefit except "we support include"? I don't see
> any. The extra files are still there, they will be loaded too, etc.
Instead of a -single location- being defined at compile time or
execution of PHP time, this allows it N
On Wed, Dec 23, 2009 at 2:23 PM, Pierre Joye wrote:
> So what you need is multiple ini dirs, not actually include. I think
> there is a patch somewhere for this feature, or it may even be already
> in. If not, that could be something useful.
To me, it solves all of the usage models currently pro
On Wed, Dec 23, 2009 at 5:12 PM, Mikko Koppanen wrote:
> Hi,
>
> I think this is the feature (in trunk currently):
>
> http://svn.php.net/viewvc?view=revision&revision=28287
This is not the same, this is just an additional way to still have
static dirs defined only at compile time, or maybe envir
On Tue, Mar 23, 2010 at 10:25 AM, Antony Dovgal wrote:
> sapi/fpm and sapi/cgi now have quite different codebase as we've dropped some
> stuff
> not pertinent to FastCGI (there might be some leftovers, I'll deal with them
> later).
Not sure if it's best to say it here or just post to the wiki
On Tue, Mar 23, 2010 at 12:43 PM, Antony Dovgal wrote:
> I mentioned it, albeit briefly:
> * basic SAPI status info (similar to Apache mod_status)
Missed it (oops)
> We've discussed this many times and I thought it's pretty clear that php.ini
> syntax won't fit in this situation - the requireme
2010/3/23 Jérôme Loyet :
> In fact with INI syntax, there is a serious missing cause there is no
> include system shiped with. And with FPM as there is potentialy many
> "vhosts", it's necessary to have an include system to feet all system
> administrator needs.
That was something I brought up to
On Tue, Mar 23, 2010 at 1:55 PM, Antony Dovgal wrote:
> Now I was never an XML fan myself, but I think THIS particular XML config file
> is even easier to read and understand than php.ini.
There was one other suggestion / something Andrei wanted to do (at
least he mentioned to me) and that was c
On Tue, Mar 23, 2010 at 2:58 PM, Antony Dovgal wrote:
> Okay, here is XML based config quickly converted to php.ini-style syntax:
> ==
> [fpm.flobals]
> pid_file = /usr/local/var/run/php-fpm.pid
> error_log = /usr/local/var/l
2010/3/23 Stanislav Malyshev :
> Actually, if you have extension parsing the .ini, nobody prevents you from
> having:
>
> include[]=another.ini
>
> and have your extension interpret it as it wishes (i.e parse another file).
> Only problem you have is if you want PHP to do it automatically for you.
2010/3/25 Jérôme Loyet :
> ** Default Section **
> Talking about redundancy. When there is more than one pool, there is
> several parameters which remain the same. Why should we type them
> several time ? The idea is to define a special pool, which will not be
> started but only be used as a "temp
On Thu, Mar 25, 2010 at 12:47 PM, Antony Dovgal wrote:
> You can as well stop declaring (!?) what FPM should and what it shoud not
> and start doing something useful instead.
> Writing some code might be a good start for you.
As someone Andrei somewhat entrusted to try to keep the dream of FPM
a
2010/3/25 dreamcat four :
> If you intend to implement this Jerome, then perhaps (any time when /
> after you implement), just make new (seperate) RFC for that (just the
> ini). Which (obviously) can be attached as single dependancy of this
> RFC. That way, those comments / feedback can come direc
2010/3/25 Jérôme Loyet :
> Is there any sapi with directives in php.ini ? I can't see any reasons
> to have some FPM specifics into php.ini.
>
> To change the default conf file, juste specified it in the commande
> line like any other daemon you have running on your boxes.
php-fpm isn't launched
2010/4/13 Zeev Suraski :
> What he means is that it'll be implemented in the custom code responsible
> for parsing fpm.ini, and not in the ZE .ini parser which would be the layer
> below it. Implementing include() can be done at either layer. If it's
> implemented at the bottom layer (ZE) then i
On Thu, Apr 15, 2010 at 12:09 AM, Ferenc Kovacs wrote:
> My suggestion is more about releasing the allocated memory as soon as
> possible. That is, this option is similar to "max_requests".
> PHP-FPM would kill the PHP process if the requests a process handled
> exceed max_requests, and similarly
On Apr 15, 2010, at 4:55 AM, Zeev Suraski wrote:
Agreed that it's a big change, but it's certainly possible.
Requires its own discussion...
Fwiw +1
Mysql's ini file supports includes (!includedir and it supports
wildcards), so people are used to the syntax and it can follow a
pseudo-
Is this only useful for 5.2.x and is it only for realpath() or is it for any
sort of path lookup and caching? Like resolving include paths and such?
On Jun 20, 2010, at 6:37 AM, Rasmus Lerdorf wrote:
> realpath_cache_size = 256k
> realpath_cache_ttl = 7200
--
PHP Internals - PHP Runtime Deve
Perhaps by adding it to core the original reasons for alternatives will be
reduced and the things that make those special could be implemented into apc?
On Jun 20, 2010, at 1:56 PM, Ferenc Kovacs wrote:
> On Sun, Jun 20, 2010 at 10:39 PM, Lukas Kahwe Smith
> wrote:
>
>>
>> On 20.06.2010, at
I would like to know why a third party can develop a better (or more agile?)
cache than the core php devs. I would think that if anyone can align it nicely
especially when writing the core code itself and could also think about "this
is a great place for apc to hook in" or something. It's obvio
On Fri, Oct 8, 2010 at 2:47 AM, jvlad wrote:
>> Hi.
>>
>> This was discussed before.
>> see
>> http://www.mail-archive.com/internals@lists.php.net/msg37211.html
>>
>> Tyrael
I have a question after reading through that thread -
apc.include_once_override - boolean, default is 0
Optimize include_o
On Fri, Oct 15, 2010 at 10:26 AM, G M wrote:
> Okay so I am thinking about submitting a patch to PHP that would enable you
> to call functions like this:
>
> stuff(1, 2, 'separator' => '', 'clean' => true);
I don't like having the never ending growing list of arguments issue,
but I just use
fun
On Thu, Oct 21, 2010 at 12:52 AM, Ionut G. Stan wrote:
> Option 5: Implement named parameters?
Option 6: do as other have and just pass an array yourself...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, Oct 21, 2010 at 1:10 AM, Ferenc Kovacs wrote:
> With #6, you would lose the argument hinting(either be native, or phpdoc)
> feature for your method.
you would, however
a) it's already supported
b) there's no language changes required
c) do your own typecasting, sanity checking, bounds c
On Thu, Dec 9, 2010 at 2:31 AM, James Butler
wrote:
> Sorry, I wasn't being very clear there, what I really meant to say was will
> there be the will to remove it considering the effects.
> I suppose INI is enough to allow it to be easily changed, but would it ever
> become a default setting of
On Thu, Dec 9, 2010 at 2:38 AM, Andrey Hristov wrote:
> Yes, as the documentation will mention how to do it, for old applications.
> For new apps it is easy - pass all the information you need as parameter to
> the function. It works in other languages, why shouldn't it work for PHP?
named param
2010/12/9 Ángel González :
>> Not to mention, I have had issues (and I can't reproduce it properly
>> or I would report it) where sometimes i will have a variable in global
>> scope in one file, and I have to reference it as $GLOBALS['variable']
>> in another include, or I have to global $variable
Personally I'd love to see an option to make it spit out an array. Just like te
second parameter in json_decode()
Since array keys can include colons prefix work would also be easier. Then
something akin to array2XML() to spit it back out.
On Apr 26, 2011, at 7:43 PM, Tom Samplonius wrote:
>
Forgive me for injecting my $.02 here but what is the original reason
for changing the most basic language syntax to be a little bit
shorter?
Is it hurting anyone to type out "array()" or something?
I think it is silly that "shortening array syntax" is up for
discussion but ensuring Unicode compa
On Tue, May 31, 2011 at 3:06 PM, Rasmus wrote:
> Because most of those can't be done without breaking millions of lines
> of code out there. And a couple of people worked on Unicode for years
> and got very little support. That is not a small project. This short
> syntax for arrays is probably th
I've always considered json an awesome machine to machine interchange format
(the most efficient one) but not the easiest to read for configuration or
manually defining anything.
I see nothing wrong with the initial example. Has worked well for years. :)
On May 31, 2011, at 3:43 PM, Marcel Ess
I don't really want to stand on my soapbox any longer, as it's obvious
where the crowd leans on this one, but I need to clarify a couple
points a bit and feel obligated to reply to another.
On Tue, May 31, 2011 at 10:15 PM, Stas Malyshev wrote:
> Fundamental changes means "throw out your product
On Wed, Jun 1, 2011 at 1:01 PM, Pierre Joye wrote:
> I modified the vote page, pls move your votes to the desired syntax
> (or global -1)
This is a good idea to group things like this.
Back on the soapbox. All of this is just to reduce typing "array" (5
characters) before things?
Old:
$foo = a
First, why not go the opposite way and standardize the syntax - why
not make object() or Object() work like array() or Array()?
$person = object('name' => 'Justin',
'city' => 'ogden',
'state' => 'ut',
'country' => 'usa',
'favoriteNumbers' => array(4, 12, 37, 42),
'unluckyNumber
On Wed, Jun 1, 2011 at 3:09 PM, Sean Coates wrote:
> This is not about saving five characters every time I type array(), it's
> about making my systems all work together in a way that's a little less
> abstracted, and a lot less prone to error.
Why not make your data in JSON and then $foo = js
Why doesnt voting happen using a poll/voting engine. Written in (gasp) PHP!
(although soon PJSON)
On Jun 3, 2011, at 1:03 AM, Stas Malyshev wrote:
> Hi!
>
>> Voting on the wiki? Yuck. If you want participation, do it here on the
>> mailinglist and store the record in the wiki. If all "votes"
+1 the way for change is to add the new, add an E_DEPRECATED style
warning for a point release or two, and then nix it.
On Sun, Jul 3, 2011 at 2:04 PM, Kiall Mac Innes wrote:
> FPM is still new, and only just getting the experimental flag removed, now
> is the only time to make any BC breaking co
90 matches
Mail list logo
