> 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
> 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
> 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
> 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
> 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
> 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 frustrate
> 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
> 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
> 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
> 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
> 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
Andi Gutmans wrote:
I'd like to roll PHP 5.1 Beta 1 very soon.
Wez, I've been waiting for PDO in order to get this going. Do you feel
it's mature enough or should I hold off some more time?
Before we go beta, I'd like to see php_check_syntax() disappear (as it
seems it will never be "fixed").
It
Daniel J Cain Jr. wrote:
One change adds a PHP function session_is_started() to determine if a
session has already been, well... started. :)
It also adds an optional id parameter to session_regenerate_id()
allowing the user to provide their own id instead of PHP generating a
new one. I'm not i
Andreas Korthaus wrote:
If you want to rely on users to install packages (which is a good idea
IMHO) all users (not only superusers) need a reliable tool for
installation/management (also without shell-account).
Greg has made significant progress in this area (PEAR 1.4's remote
installation cap
AnteD wrote:
Yes I know that this is a small function and yes I know it can be
copy-paste with every new project you do but from the first day I've
been using PHP until today this function follows me everywhere and I now
that everyone is using it one way or the other for debugging..
...
The
Jason Garber wrote:
If there was any way to accommodate this with userland PHP code, I
would have already done it. However it is an engine level function
that has to be added to the core of PHP.
For the record, I also find ifsetor useful, but what you want can be
accomplished like this:
Andi Gutmans wrote:
Please check http://snaps.php.net/~andi/
Try not to find show stoppers unless they format your hard drive :)
Will post public tomorrow...
Andi
Number of tests : 1912 1422
Tests skipped : 490 ( 25.6%)
Tests warned:0 ( 0.0%) ( 0.0%)
Tests fa
Andi Gutmans wrote:
I rerolled Beta 3 due to some critical patches that needed to make it in.
Please download and give a sanity test. If no new critical bug is found
I'll put it up this evening or tomorrow.
I might be too late, here, but when building:
./configure --with-mssql --with-pdo-dblib
how can i check if a method is called statically when called from inside
another object? (without debug_bactrace())
type="own">http://blog.phpdoc.info/archives/4-Schizophrenic-Methods.html
Short answer:
$isStatic = !(isset($this) && get_class($this) == __CLASS__);
HTH
S
--
PHP Internals - P
i know this hack, but it does not work, if the statically called method
is from the same class as the calling object
Good point. Sorry for not noticing.
.. I have no idea WHY someone would want to do this.. that said, I don't
know of a way to do it, either.
S
--
PHP Internals - PHP Runtime D
That won't work, eval() is not a function...
Ah yes, you're right... I guess we do need another INI setting.
Or constructs-that-look-like-functions could be governed by
disable_functions (eval, echo).. that would cause other problems (like a
disabled "return"), though.
S
--
PHP Internals
Hello core folks.
Please see this table:
http://php.net/manual/en/ini.php#AEN189095
As long as I can remember, the manual has said that PHP_INI_SYSTEM is
settable in httpd.conf.
I just ran some tests, and it seems that this is not the case. Seems
these are only settable in php.ini.
The man
I can clearly set the PHP_INI_SYSTEM option in the httpd.conf.
As stated in http://php.net/configuration.changes you should use the
'php_admin_xx' directive instead of 'php_xx'.
*cough*
Yes, you're right.
Sorry for the noise.
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubs
Ron Korving wrote:
Wouldn't it be a good feature to have users create their own superglobals?
I realize that you're probably talking about creating custom
superglobals in the PHP core, but you might want to look at Sara's
Runkit project (in PECL). It allows custom superglobals.
http://pecl.
But then everybody will just start using $_RAW_GET instead of $_GET.
What will that solve?
This was one of my concerns.
$_RAW_* is easy to grep for, though.
Sure, it can still be abused, but it'll be a lot easier to see WHERE
it's being abused. Currently, a grep for $_GET will return a large
It occurred to me, while reading different parts of this thread, that if
the named parameter feature makes it in to PHP 6.0, there's a solution
for both sides of the parameter order argument.
1) yes, would be really nice to clean up the param order for two main
reasons: a) constant manual chec
> But I was wondering if anyone could enlighten me as to why php would
> be upset interpreting the constant as the class name. Thanks.
class Foo {
function get_name() { return 'Foo'; }
}
class Bar {
function get_name() { return 'Bar'; }
}
define('Foo', 'Bar');
$C = new Foo();
echo $C->get_
Hello all,
This crept up as the result of a bug report (not mine --
http://bugs.php.net/34494), and a small discussion on IRC:
Why does an E_STRICT get raised when extending a class, and altering the
method's proto defaults? I understand why it would be thrown when
adding/changing parameters, but
Bob Silva wrote:
> It should be a function and not a language construct IMHO. Either ifsetor or
> overload the isset statement (which may not be possible within the engine).
It _has_ to be a language construct, and not a function (otherwise, we'd
get a notice when first using the variable).
It c
I discussed this with Rasmus and Derick, yesterday, but I don't think we
came to a conclusion..
Is this a bug, or intended behaviour?
[EMAIL PROTECTED]:~$ /opt/src/php-5.0.4/sapi/cli/php -r 'echo date("r",
"1132003418 ") ."\n";'
Mon, 14 Nov 2005 16:23:38 -0500
[EMAIL PROTECTED]:~$ /opt/src/php5-2
Pierre wrote:
> On Tue, 15 Nov 2005 18:59:32 +0200 (EET)
> [EMAIL PROTECTED] (Jani Taskinen) wrote:
>
>
>> If you pass bad data to a function, it should not warn you?
>> I'd rather have it as a FATAL error. :)
>>
>> Nothing to fix here, move along. (and fix your code..)
>
>
> PHP is
FYI,
I just turned on inventory control for products 89-93, and gave them
1 units each (this is to make the backend send me mail on signup).
--
Sean Coates
(php|architect)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sean Coates wrote:
> FYI,
>
> I just turned on inventory control for products 89-93, and gave them
> 1 units each (this is to make the backend send me mail on signup).
>
Sorry.
Wrong list. My apologies.
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscri
> Sean reckons that it's Shaloshayim
> (http://blog.phpdoc.info/archives/27-+1-for-Shaloshayim-Nekudotayim.html):
>
> T_SHALOSHAYIM_NEKUDOTAYIM
Changed that to Shalosh (as apparently the -ayim means "twice" (as in
PAAM=2, AYIM=twice, NEKUDOT=dot, AYIM=twice)).
Not that I claim to know very much
> How about ;; then?
> name1;;name2::myfunction();
PLEASE, MAKE IT STOP!
;; is already perfectly valid syntax:
[EMAIL PROTECTED]:~$ php5 -r 'define("name1",FALSE); class name2{function
myfunction(){ echo "foo\n"; }} name1;;name2::myfunction();'
foo
* Pre-existing operators are out of the question
Sara Golemon wrote:
>> oh, that's easy to solve '>
>> btw, th ejsp way is to have '
>>
> Marcus-
> You give me greif over ;; and ** as namespace separators then you
> suggest meaningful whitespace? *tsk*tsk*tsk*
> -Sara
>
> :)
Ah, but the whitespace is already meaningful (-:
[EMAIL PROTECTED
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
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
$_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
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
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
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
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
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 do
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
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 (manua
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.
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
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
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
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
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
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
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
Derick Rethans wrote:
> You do know that that means that we have to consistently name all
> parameters to our 4000+ functions, right?
On this note, and to throw in my 2c on the issue (from a doc
standpoint): there are places in the manual where I've (personally)
deliberately changed the parameter
Andrei Zmievski wrote:
> There is no "unconverted" function list. There is unicode-progress.txt
> file where we have been tracking what has been done, but I'm not sure as
> to its accuracy as of yet. Some of the functions listed there may need
> to be looked over after Dmitry's patch.
It would be
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:
http://peo
> 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 e
> 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
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:
(Output is: "zero one one")
I asked around about this,
> 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 ex
> 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
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
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
> 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
> 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
> 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
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
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:
> 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
> 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.
> 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
> 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
> 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
>
> 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
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
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*
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
> 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
> 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
> did you consider resetting the vote as the text was changed multiple times
> after the voting begun?
It was reset.
S
> 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
>> 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
> 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
> 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
> 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
>> 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
> 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 `&&`:
> 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
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
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.
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
> 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
> 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
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 -
> 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
1 - 100 of 165 matches
Mail list logo
