> I posted four suggestions earlier,
>
> They were:
>
> @
> &
> *
> ^
>
> My favourites are the asterisk or caret.
That’s no different than `@` being invalid because it’s already in use.
$ php -a
Interactive shell
php > define('a', 1);
php > define('b', 2);
php > echo @a . "\n";
1
php > echo
> 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 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
>> when IDN s
>> 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
> 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"
> a
> did you consider resetting the vote as the text was changed multiple times
> after the voting begun?
It was reset.
S
> 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 Ru
> 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 `&&`:
>> 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
> So, if we are talking about PHP 6, then the opening 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 more modern vers
> 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
> 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
> 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
> 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
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 frustrate
> Wooot! What's my prize? ;P
Shame.
> 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 in
> 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 h
> 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: http://php.net/language.oop5.b
> 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 re
*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
> 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
> 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
>>> $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 wo
> 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 c
> 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;
// O
> 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
>
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 ac
>> $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
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 discussi
>> 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
> 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
> 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: http://www.php.net/u
> 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
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):
http://paste.roguecoders.com/p/0747f
>> 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'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
> 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: http://www.php
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
ei
> 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
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
i
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:
http://cvs.php.net/viewvc.cgi/php-bugs-web/include/functions.
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
status
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: http://www.php.net/unsub.php
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 Interna
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 h
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 pa
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: http://ww
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 5.
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 (manua
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
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 opini
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 do
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
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
Do we have a preference of Apache's SVN or svnserve?
The former requires Apache 2+, AFAIK.
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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, they're
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
$_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
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 de
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 configu
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 conv
> 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 D
> 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->k
> 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
> 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 s
> 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
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 "P
> 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
> 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.
> Javascr
> $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(clon
> 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 comp
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 th
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 patch
> 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 :-).
I'm not talking about forcing everyone to use namespaces tomorrow. I'm
trying to plan for a future where there's a sen
> 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 leas
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 the
Hi,
> What are you thinking about adding this feature:
> echo foo()[4]; // < it that
I'd like to see this. IMO, it's similar to $obj->objproperty->property,
syntactically.
It would also simplify working with third party libraries/apps that pass
a lot of arrays around in a weird way *cough*
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:
http://bugs.php.net/search.php?search_for=&boolean=0&limit=10&order_by=&direction=ASC&cmd=display&status=All&bug_type%5B%5D=Docum
> 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 apprec
> 1. ZEND_INI_SYSTEM and make people run two copies of Apache if they want
> both modes. This is architecturally more simple and more robust, I believe.
> 2. ZEND_INI_PERDIR and let people switch modes as described above. This
> is a lot of work and will probably result in quite a few edge cases
>
> 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 possibl
> 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 suit
> 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.
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 error
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: http://www.php.
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.
Spea
> 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:
http://cvs.php.net/viewcvs.cgi/phpdoc/en/appendices/reserved.xml?view=diff&r1=1
> 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 (..) 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 is found
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 usin
Steph Fox wrote:
> Still notably haven't heard from: Lukas, Nuno, Alan K, Sean...
1) 0
2) 0
3) 0
4) 0
Sorry for the noise. I was told to vote.
I don't personally have much use for goto, and I see both sides.
I also only run PHP on dedicated platforms, so if appropriate engine
mods were made (if
> 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 -d"error_reporting=2047" -r '$a=$b;'
Notice: Undefined variable: b in Command line code on line 1
Accor
1 - 100 of 165 matches
Mail list logo
