If PHP has macro or userspace aliasing!
This is one possible solution for this.
The engine has support for aliases. See
http://php.net/manual/en/internals2.ze1.zendapi.php
If I thought this “consistency” was very important (I do not, and I fully
expect an RFC on this to fail if this thread
On Thu, Nov 6, 2014 at 3:39 PM, Kévin Dunglas dung...@gmail.com wrote:
FILTER_VALIDATE_DOMAIN checks conformance with DNS RFCs : total length,
label length and allowed characters (_ are allowed in domain names but many
other characters are forbidden such as ~/+...). I'll add IDN support too
In Python, decorators are very
powerful for modifying function behavior (i.e., attaching pre/post
conditions to functions or doing some things phpunit does is really
easy) but it is too much for just attaching data.
FWIW (and I apologize if this is just adding to the noise), one of the most
The way voting works now, I happen to know which option is winning. I
happened to know that *before* I cast my vote. The current results are
posted on the RFC, and the same information percolated into emails
encouraging folks to vote. I wonder, though, if knowing which was leading
and who
did you consider resetting the vote as the text was changed multiple times
after the voting begun?
It was reset.
S
i.e. is_null($a, $b, $c) would be the same as is_null($a) is_null($b)
is_null($c)
Note that this would not be semantically equivalent in this form, even if
`is_null()` did accept multiple parameters, because of the short-circuiting
with ``:
?php
function are_null() {
foreach
Not a good idea IMHO: it would complexify the execution a lot, think about:
To be clear, I wasn't proposing an alternative. I was just pointing out that
function call semantics are not the same as conditional (short-circuit)
semantics, as they appeared in the OP.
S
--
PHP Internals - PHP
Say we agree on the syntax above
($n) |$m| = $m * $n;
What happens when my one liner function needs to do one more operation
like checking the value of $n before multiplication?
As I stated before suggesting the syntax: It's only meant for a single
expression. It's purposefully NOT
So, if we are talking about PHP 6, then the opening ?php tag should be
accompanied by the version it was written for, it was tested with and then
the engine could switch to a compatibility mode for that version.
Seems to me that this would solve the problem where a host can't upgrade to
a
Any software written to make use of that already has
conditional checks around it plus that feature needs a serious re-think
anyway.
FWIW, we only deploy with APC, so we don't necessarily have checks guarding
apc_fetch()/apc_store().
That said, it would be trivial to write wrapper functions
Some people asked me what the advantages of using an AST-based
parsing/compilation process are, so I put together a few quick notes
in an RFC:
https://wiki.php.net/rfc/ast_based_parsing_compilation_process
It would be nice to get a few comments from other core devs on this.
Pardon my
For my vote: I think keeping this in pecl is fine, because they're all
things which can be done from the extension space.
If my vote still counts (I was somehow involved in the creation of runkit at
one point (-: ), I say the same: extension is fine. Don't monkeypatch
production.
S
Use
git reset --hard origin/PHP-5.4
to reset your local checkout to the current version on the server.
It should be noted that when you `reset --hard`, you'll lose local changes
(including branch commits, except in the reflog). You'll probably want to stash
first, reset, then stash pop
which raises the question,
if most of the PHP group doesn't care enough to vote, does it mean it is
a bad feature?
I think the disinterest is more generalized than this particular vote. As far
as I can tell, only 3½ members of the PHP Group actually still participate in
the PHP community in
can I ask how did you come up with that number, and who is the half man? :)
Rasmus, Andi, and Ze'ev. Andrei works with something PHP-related, sort of,
still, and is only involved on occasion, so I counted him for half.
The others are all names from Internets past (pardon me if I'm wrong, but I
Wooot! What's my prize? ;P
Shame.
My response earlier was meant to be funny, mostly, but I did also intend to
convey some of the same things Rasmus said. The only person who wants to
participate in a conversation where someone is hogging the floor is the person
doing the talking.
Yeah one of the problems that really
Thanks for the reminder! If it ever looks like I'm getting carried away
while standing up to these guys, please don't be afraid to let me know.
I hate to even get involved in this thread, but [especially] now that the issue
is resolved, could you please start replying to people in private
APC should join the party soon, not sure yet if it is ready yet. We
will run compat tests first.
I ran into a crashing blocker with APC on 5.4:
https://bugs.php.net/bug.php?id=60845
If anyone has the bandwidth to look into that, I'd love to help out in any way
I can.
(Sorry for the thread
I'm not sure if this is the desired behavior and i don't want to submit a
bogus bug report.
…
At first i would expect an error since A was not instantiated, at most i
would expect to return NULL but not 'stuff'.
Is this a bug ?
This is explained here:
https://github.com/preinheimer/xhprof vs https://github.com/facebook/xhprof
IMO, this is actually a good example of how it's *beneficial* to have diverging
trees (forks).
Paul's xhprof is (or at least /was/; I believe it still is, but I haven't
looked at the facebook tree in a long time) FAR
* Add a 'response_code' key, with the server response code as an integer
…
Anyone got any thoughts on this? I appreciate it'd be a BC break, but I think
it might be useful.
While I applaud the idea of making this easier, keep in mind that a single
request can have multiple status code
*BUMP*
It would be really helpful if we could find consensus on this… I feel like the
RFC process is stalled until these questions are answered.
S
On 2011-06-27, at 9:06 PM, Sean Coates wrote:
The RFC was accepted.
Ok; so is this official now, or does it need to be ratified somehow
The RFC was accepted.
Ok; so is this official now, or does it need to be ratified somehow?
If I clean up my RFC (https://wiki.php.net/rfc/objectarrayliterals) and put it
to vote, are these now the rules that will be followed?
Since I didn't use [RFC] in the original email to internals, do I
My reasoning is simple. The key for bundling extensions is to have
them available for most hosting solutions. If a shared host provides
support for mongodb, then he will most likely enable the mongodb
extension in php, if he knows what he is doing. The same applies for
all other non core
re JSON
· will never validate as JSON
·recognizablyviolates JSON quoting rules
· recognizably violates the JSON security concept…
…
-- I do not feel that the acronym JSON has any clarifying nor edifying
place in the RFC describing this syntax.
I have actually
a) JSON is actually being mentioned to advocate for the syntax with for the
sake of *familiarity*.
b) Interoperability is being confused with familiarity.
My goal is interoperability. Familiarity is a factor, definitely.
c) Actual interoperability of the syntax with JSON is just a happy
Can you provide an use case and code example of how that would look?
Sure.
Here's how an ElasticSearch query currently looks in PHP:
$esQuery = new \StdClass;
$esQuery-query = new \StdClass;
$esQuery-query-term = new \StdClass;
$esQuery-query-term-name = 'beer';
$esQuery-size = 1;
// OR
Please add the RFC header so we know what's the status.
Thanks for catching this.
$a = ['one': 1, 'two': 2, 'three': 'three'];
has anyone played with the parser to
implement it?
I have not, personally. I feel like it would be a waste of time at this point,
unless a logical problem can be
$foo = {
'bar' : function(){
echo 'baz';
}
};
$foo-bar();
I guess it's not yet too late to surpass Perl in the front of obscurity...
Since the stuff to the right of the assignment operator (`:` in this case) is
valid PHP, I don't see why this wouldn't be allowed if we
$foo = {
'bar' : function(){
echo 'baz';
}
};
$foo-bar();
I guess it's not yet too late to surpass Perl in the front of obscurity...
Since the stuff to the right of the assignment operator (`:` in this case) is
valid PHP, I don't see why this wouldn't be allowed if we
Hello.
I've posted a RFC concerning Object and Array Literals on the wiki:
https://wiki.php.net/rfc/objectarrayliterals
Please read, and if you have a comment that is not already covered in the RFC,
raise it here. I'm definitely open to discussion, but I would really love to
keep this
pls do vote here:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did
not choose which syntax they want.
If people vote on this now, will further discussion about how this SHOULD work
be shut down with we already voted on this?
S
If people vote on this now, will further discussion about how this SHOULD
work be shut down with we already voted on this?
which other discussions do you wish? Json is clearly not an option and
not enough people (but a couple) likes or wants it.
The RFC is about short array syntax and as
This discussion seems to lack real-world examples…
Derick wrote:
I'm still -1 on it. It makes absolutely unreadable code (yes, also in
JavaScript with f.e. MongoDB).
Here's an actual snippet from my production code (which interfaces with
ElasticSearch):
Now, the only reason I would personally support the array shortcut is
if it was an implementation of JSON. I know that's not on the table
here
I don't think anything is officially off the table, unless we forego discussion.
My application is largely JSON-powered. We pass data from back- to
Why not make your data in JSON and then $foo = json_encode($data) ?
For exactly the same reason people actually use callbacks efficiently, now that
they don't have to create_function() them.
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
I'm one of the people who've brought it up on Twitter. Today's discussion seems
to have earned some traction, which is a step in the right direction, I believe.
I would prefer (as Rasmus pointed out) not to start a long discussion about
it. Primarily I would be curious if anyone on the lists
Don't you think having support for both ['a':1, 'b':2] and {'a':1,
'b':2} would create confusion?
This sounds OK to me, FWIW.
Would seem to me a more elegant solution would to just drop the idea of json
interoperability and go with something that works for PHP.
('a'='b', 0=1234)
I want to request a C/C++ feature that i think is good.
MACRO
FWIW, you could use Prep ( https://github.com/andreiz/prep ) and GPP (
http://en.nothingisreal.com/wiki/GPP ) to accomplish this.
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
APC has certain effects on the code that are far from obvious, and
enabling it by default would significantly complicate the average
user's learning curve.
Can you elaborate? What average user-facing features are non-obvious?
We should document them if nothing else.
S
--
PHP Internals -
No, it is not hard to write strlen but I would also like to see these
functions organized better. I've felt that PHP has been a mess since I
learned it way back when, the naming inconsistencies are everywhere.
I don't believe there's anything stopping you (or other users) from creating
If you look closely you will see that all 5 validators in the chart
reject single-word domains.
Note that this regex also considers anyth...@localhost to be an invalid email
address.
I hear your point about the difference between a local machine named va and
the va. TLD, but I doubt I'm the
I would like to ask all developers to voice their opinions of
whether it makes sense to add this to 5.3 or to throw it away
(either one is fine btw).
I don't want to start a long discussion, but IMO this and other major
language changes doen't belong in a point release of 5.3.x (whether
so what i'm wondering is: is there an easily parseable or structured
interface (xmlrpc, soap, read-only JSON export, whatever) to the
php.net bts
that could be used to get a bug's information? or would such a bts-
link
service need to resort to scraping the page for a particular bug's
Just another question: may you please list me all the possible
'Status' field values? In particular we are interested in those
'Status'es that identify the bug as closed and wontfix.
I believe all current statuses are declared here:
So if the variable is set and contains false, we can't check it ?
And near same problem for 0, empty array and empty string.
How would you ever get false (the value, not the string) into a
request variable? (without setting it that way after the request init,
that is)
S
--
PHP
So this isset() behavior will only be available for request
variable, not for all variables ?
I'm not picking sides, but that seems to me like the overwhelmingly
popular use case.
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Maybe we can first collect a list here on internals@ on what apps have
been successfully been run on 5.3 and whether they required any
tweaking. If after we make a list there's still need to reach out
I'd be
happy to do some of that.
FWIW, I've some casual testing with Habari and 5.3 and we
I don't safe stuff relying on magic_quotes is safe but kicking it will
open up way more attack vectors... :-(
In my opinion, this isn't about opening attack vectors (one hole is
all it takes, so they're probably already vulnerable), but removing
mqgpc without fair warning to end users could
Hmm, I really think we should simply maintain BC 100% but using the
new parameter parsing API and then really think this through for the
next bigger release (presumably PHP 6.0) and come up with a set of
interfaces for objects that allow them to more sensibly work with
functions.
FWIW, I
Also cant we some how automate the BC break testing for this (aka
scan all functions that accept an array with the old API in 5.2,
pass it an ArrayObject instance and see what happens and compare
that to 5.3)?
Yes we can ;) That should be not hard to do by looking at ones
having 'a' in
Please bring up any areas you are concerned about that we might have
forgotten.
PHP_5_3 as of this morning does not contain that patch that makes
ArrayObject behave like an array (reset()).
Here's a test for that (I don't have php-src karma) if anyone would
care to commit it. Passes on
Here's a test for that (I don't have php-src karma) if anyone would
care to commit it. Passes on 5.2.6, but fails on 5.3alpha3-dev
FWIW, I committed that patch today.
I'd like for it to pass by RC1 (-:
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
I applied this to HEAD
Oops. I mean to PHP_5_3 (keep forgetting that it's not HEAD).
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
So as suggested and wished, here is a patch that add a modifier '%' to
'a' in parameter parsing API, where it allows object that implements
ArrayAccess to be accept. Although it doesn't invoke any their
methods,
i.e. just how it works nowdays.
I applied this to HEAD and ran a few minor
I'd prefer to have it fixed, but then it probably requires changing
the parameters API for 'a', which might lead to some unexpected
results with regard to functions that modify their arguments. I
think we may leave it alone for this alpha but try to resolve it for
5.3 release.
If my
Actually I've been following namespaces for a fair while, but the
issue of :: being a problem wasn't really raised until a few weeks
ago.
I realize this isn't a terribly constructive comment as it doesn't
solve any problems, but I hope it's constructive in the way that it
actually causes
btw. this also affects quite a few other functions: next/current/
key/...
at least ... and maybe more after using the new parameter parsing
API.
I would say no for 5.3. But for 6 it would be fantastic to have
all array-related operations supporting ArrayAccess interface, where
possible.
You want to force users to use the full name at all times. IOW, you
want to sacrifice convenience for performance.
(chiming in because it seems that we're overlooking something obvious
here)
If it comes down to this, I'd prefer to see an E_NOTICE for the bad
performance use, though I
array_filter($my_data, function($test){ return 3 === ($test % 4) });
What's wrong with regular functions?
At risk of wading into yet circular another discussion on internals@,
I was part of the original thread on this subject, and I agree with
Stas here: unless they're real closure,
2.) Probably a better idea, just click that DELETE button on any
emails you don't feel like reading or responding to. I find that, in
a case study performed by myself just now, it takes me about a
half-second to achieve success with this method.
Against my better judgement, I'm jumping into
Sorry about that. Does the attached PDFed screenshot work for you?
If only we knew how to publish documents on that 'web thing.
(-:
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Yes, and in even larger scale applications it can become even more
useful. I have a web framework I'm working on, it's about 9,500
lines of
code now with hundreds of functions/classes. Every function/method has
to specify global for my 3 universal variables which contain large
arrays of
So the idea now is to inappropriately force everything to be a class?
It is appropriate. That's how it was designed. Obviously superglobals
were not designed to be user-definable.
If configuration is defined in a class, then as a maintainer, you can
easily determine where the data was
$_GLOBALS
Don't meant to be too pedantic, but if anyone's looking for this in
the archives, it's $GLOBALS, not $_GLOBALS.
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I apologize in advance for jumping into this thread so late (finally
trying to catch up on internals@).
FWIW, I'd also like to move to SVN, eventually (and inevitably (-: ).
I've opposed this move for php.net in the past, but only because the
proposals I was fighting were for a partial
lemme try this again. You can in no way rely on the last digits of a float
output. Those depend on your system, your CPU, your ini settings and any
operation you do with floats reduces the accuracy
It's still a regression, and should be documented.
S
--
PHP Internals - PHP Runtime
function sort_by_key($key) {
For the record, I do like this syntax, but it COULD be rewritten using
current practices (see below).
class SortByKey {
public $key;
public function __construct($key) {
$this-key = $key;
}
public function do($a, $b) {
if ($a[$this-key] $b[$this-key])
What if I doo $a = _SCOPES, $$a[$foo]?
FWIW, this doesn't work with the other superglobals (in function context):
[EMAIL PROTECTED]:~$ php -r '$_GET[foo] = bar; function baz() { $get =
_GET; return ${$get}[foo]; } $get = _GET; echo ${$get}[foo],
baz(), \n;'
bar
Notice: Undefined variable: _GET
Well, making it work makes this thing closure. Otherwise it's just a
nice way to save a couple of keystrokes :) Not to diminish your work,
but there's a danger people would think it is closure because it looks
like one (i.e., in other languages closures look exactly this way, e.g.
If it would create anonymous function compile-time, it would be a big
advantage to Wez's patch because then this function could be cached.
Thinking about this, maybe it is the reason enough to do this even if
it's not real closure.
On mulling this over a bit more, other than quick one-off
If we can solve the scoping problem (perhaps via references as you
mentioned), then lexical (or another keyword, to be debated endlessly
for months, whose name-debate will delay the implementation of this
functionality, but I digress...) seems like a good solution to grabbing
scope, and fits the
I'm not arguing the preservation of the exact value of $rev when the
anonymous function was created (as would be the case with a closure).
I'm thinking of the variable being whatever is defined in the parent
regardless. As in my proposal, the seek could search all the way up to
the top in
Can't you just take the body of create_function with the syntax of
the patch, and marry those two?
I already explained why this can't work, in this very thread. At least
not without hacking { and } to work (mostly) like in this context.
How does the current create_function handle this same
$db = new DBConnection($properties);
// Notice, still not connected to DB
$third_party_obj-foo($db);
$db-connect();
In the requested feature, the protection is in the wrong hands (that
of the third party object).
You're much better off changing your call to:
$third_party_obj-foo(clone $db);
The strcat results were approximately *10 times slower* on 5.2.1 than on
5.2.0.
Upping the number significantly (from 20 to 2000) smooths out
abnormalities:
5.2.0:
strcat(2000) 5.556
5.2.1:
strcat(2000) 5.628
These results are typical for a few runs of each (fresh
Kristoffer Hultenius wrote:
Hello everybody!
As a webhost that offer PHP-support for hundreds of customers, I have a
concern.
The mail()-function is too easy to use for sending spam and even worse -
there is (sometimes) almost impossible to trace the sender-account.
You can solve this
Antony Dovgal wrote:
On 01/18/2007 06:23 PM, Christopher Baughman wrote:
I would like to help maintain documentation, I have noticed many
unanswered bugs,
You don't need a CVS account to start answering them =)
I think he meant answer-by-patching.
In any case, feel free to send patches to
Hello all,
A number of factors have come together to prompt me to possibly commit
mailing-list-suicide by re-opening the namespace issue.
Last week at Zendcon, a number of PHP developers/community members
chatted about namespaces in PHP 6. That chat was the prime motivator for
this email, but
That's a bit of a circular logic no? There are indeed technical
challenges to implementing namespaces, these reasons have been covered
in previous discussions many times, since no adequate solution was
devised they were never implemented. Once those issues are resolved or
at the very least
PHP 6 is not yet out and probably won't be production quality for quite
some time. Which means that migration to it en mass is probably not
going to happen this decade :-).
snippitysnip/
I'm not talking about forcing everyone to use namespaces tomorrow. I'm
trying to plan for a future where
Andi Gutmans wrote:
Cool. Yes, generating that link would be *very* useful.
Can someone hack that up?
It's actually really easy to generate.
Do an advanced search:
There is a missing function from the ibm_db2 driver documentation. I would
like to add this to the documentation package. This is my first try at
this, I hope this is done correctly.
If one of you kind folks can take a moment and add this to the
documentation, it would be greatly
Now that everyone had their say (I hope) I've made a quick tally of the
votes so far:
Rename date timezone classes to DateTime and DateTimeZone respectively
FWIW, add me to this.
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Many people (incl. php devs) asked me if I can include zip in 5.2.0.
Ilia thought it was too late in the game and planed to do it in 5.2.1.
I don't remember seeing a discussion on including Zip in core (perhaps I
just missed it, but a quick search didn't turn it up). I think Zip is
better
From my experiences the problem with this is many shared hosts wont install
non core modules, so the more modules moved from core to pecl the less
flexible php will be and the less use it will be.
I understand the need to keep the core code maintained and as clean and
lean
as possible, but
Ilia Alshanetsky wrote:
Why not just define your own custom error handler and have it filter out
the error messages that you don't want to see... To me this would seem
like a easier approach, i would be against adding a in-language filter
for this.
Inability to easily determine which errors
Michael B Allen wrote:
Is /etc/php.d a standard part of *every* php4 installation? Can I rely
on it's existance? Is it's location a configuable option?
No, you can't rely on it.
What's in there?
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Ilia Alshanetsky wrote:
Let's keep this number of lists to the minimum. Thanks to Lukas, we
already have a wiki with all this information, lets keep using it, the
release process is complex enough already without having to scramble
around looking for information on dozens of websites.
In any event, I'm just trying to indicate that others may also face
issues if they have PHP4 apps with these sorts of keywords in them.
try has been a reserved word (documented) since Fri Oct 1 08:07:16
2004 UTC:
Is there any funciton to get the system related statistics like,
meminfo, cpuinfo, etc.
Hello,
In the future, please use php-general@lists.php.net for anything not
related to PHP internals development.
As for your question, see http://pecl.php.net/statgrab
S
--
PHP Internals - PHP Runtime
Patches have been written and languish simply awaiting inclusion in HEAD
Johannes' method (olli.../li.../ol) doesn't copy paste well in
FireFox 1.5 -- you might consider this a FF problem, but in any case,
line numbers are pasted, so this is really a pain for sharing code.
Until a good method
It *has* to be an E_STRICT because it's something related to language
and possible semantic errors. E_NOTICE is not for that.
Isn't it the same as the following?
[EMAIL PROTECTED]:~$ php5 -derror_reporting=2047 -r '$a=$b;'
Notice: Undefined variable: b in Command line code on line 1
Gareth Ardron wrote:
Hi,
Sort of mailing this in as the result of the rantings of quite a few
mates of mine who look after shared hosting boxes.
Would it be acceptable to do up a patch for the mail() function which'll
listen to an ini entry[0] for a logfile to log all mail sent using this
Hi,
A week or two ago, a colleague asked me about a strange behaviour he
experienced, with seemingly-duplicate data within a foreach block. Upon
further examination, we determined that this was caused by assigning to
a referenced variable:
?php
$i = array('zero','one','two');
foreach ($i AS $j)
it's not the problem of the second foreach, any usage of $j after the
1st foreach as $j will hurt
Yes. I thought it was clear that I understand this. I guess not.
My point is that foreach is doing something that isn't immediately
obvious. The same is true of your for loop, but to a lesser
Now, it seems that $keys['file'] == $keys[0], which makes sense why the
issets
return true. However...
if ('file') echo 'true';
will print moo, therefore 'file' == 1, not 0. Why is this different when
using
it as a string offset?
IMO, using a string as a string offset, a fatal error
Ahh.. I see. That does make sense now as to why it results in the first char
in the array - however I still think it makes more sense not to cast, but
rather to give a fatal error.
PHP autocasts everywhere. This would break years worth (and thousands)
of applications.
S
--
PHP Internals -
Wez Furlong wrote:
As Gareth points out, an RRDTool extension is a no-go for the PHP
project due to a licensing conflict.
The best I can suggest is hosting your project on sourceforge.net.
... digging up an old thread, here..
I happened up the rrdtool site, today, and saw this:
1 - 100 of 154 matches
Mail list logo
