Pierre wrote:
Also, is it not George S, Ilia and Wez that are listed as mainters of
PDO_MYSQL?
Yes, as they do all the initial work. What's the point? Mysql was not
a maintainer/initiator of any of the .net db layers (or any other
language).
I will try to discuss this and get a commitment at
David Wang wrote:
My personal opinion is that it is ready for 5.3 and should be put into
5.3. It is stable, end-users will not be affected unless they want to
use it, extension writers should not even be affected, there is no
performance degradation and it would help make PHP a much more
credibl
Ilia Alshanetsky wrote:
On 15-Sep-07, at 7:18 PM, Stanislav Malyshev wrote:
NP ;-) Btw the detailed breakdown of the votes is available here
http://bb.prohost.org/53Features.pdf
I have taken the data from this PDF and slightly reworked things [1] so
that its easy to see which topics got mo
Andrew Shearer wrote:
Meanwhile, array_get() provides the most-needed functionality while avoiding
the issues that prevented ifsetor's acceptance.
Aside from lack of BC hacks what is the issue? I remember some fussing
about the name, but I find this a joke of an argument. You cant get much
c
Stanislav Malyshev wrote:
So, for the people that wanted multiple NS per file, would such solution
work?
I think the limitation is acceptable.
P.S. this is *not* a "should we use braces" thread, so please don't :)
The syntax is not, but since you disallow discussing this in this
thread, I
Ilia Alshanetsky wrote:
1) Backport the namespaces patch for PHP 6
+1
3) Apply the Late Static Binding Patch
+1
5) Implement Sqlite3 support via the ext/sqlite extension (patch is
already available)
+1
6) Remove safe_mode, register_globals and magic_quotes
-1
7) Introduce mysqlind
Stanislav Malyshev wrote:
10) Split off deprecation from E_STRICT into E_DEPRECATED
0. Why do we *need* it again?
E_STRICT is about general coding style that we feel should be
encouraged. Its sort of the comp sci teacher in a box.
E_DEPRECATED is things we drop are replace. People that ne
Hi,
In the spirit of forwards compabitility I think the 5.3 release will we
very important regardless if we keep or remove the unicode switch in
PHP6. From my POV 5.1 and 5.2 have mainly covered stability and
performance improvements on top of the addition of several important
extensions like
Robert Cummings wrote:
On Wed, 2007-08-22 at 13:57 +0200, Marcus Boerger wrote:
Hello Rasmus,
the limitations given here and very good explained should imo stay. They
should because that is not only easier to understand and easier for anything
that has to deal with it like opcode caches and
Hi,
Ok, so I think its becoming clear that BC is not the main issue we will
be addressing with the unicode switch. I know Zeev's mantra that BC is
not binary, but from the people that have posted feedback on the topic
from actual experience it seems that making code work on PHP5 (and even
PHP
Andi Gutmans wrote:
Maybe you guys can try with ezComponents?
So whats your target with this BC flag .. make it possible to have
PHP4-PHP6 (unicode off) apps?
Keep in mind that the camp that is suggesting to remove the unicode flag
is at the same time committing to back porting more things
Andi Gutmans wrote:
Before we continue this discussion I think there are a couple of things
which would be useful data points:
a) What is the performance difference between an implicit Unicode app
and non-Unicode. If we have 3-4 apps ported over to Unicode_semantics=on
Honestly I do not see any
Ilia Alshanetsky wrote:
Hopefully Edin will have the time to upgrade the MySQL lib on the build
farm, thanks letting me know.
add to the todo:
http://oss.backendmedia.com/PhP52
What about GD2 tests and PCRE update .. are those done?
regards,
Lukas
--
PHP Internals - PHP Runtime Development M
Hannes Magnusson wrote:
On 8/15/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
Hi,
Someone in the Doctrine channel just brought up the issue of having to
look forward to ensure mid term compatibility when choosing names for
identifiers. I guess with namespaces and other things will a
Hi,
Someone in the Doctrine channel just brought up the issue of having to
look forward to ensure mid term compatibility when choosing names for
identifiers. I guess with namespaces and other things will add new
reserved words. I think we should have a prominent place on php.net with
early wa
Hannes Magnusson wrote:
On 8/14/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
A Major bugfix maybe ( yes, it was clearly a bug/misfeature)
A bug is when code doesn't do what was intended. This is not the case,
this is the case of missing feature. While I think everybody agrees this
featur
Lester Caine wrote:
Following on
Lukas Kahwe Smith wrote:
Lester Caine wrote:
The main thing I see there is 'raw' SQL. Loading the variables
directly into the script, rather than simply binding them as params.
I have yet to work out a way of converting some of my dynamically
Lester Caine wrote:
The main thing I see there is 'raw' SQL. Loading the variables directly
into the script, rather than simply binding them as params. I have yet
to work out a way of converting some of my dynamically generated SQL
into a format that will work with PDO - on any database. I've
Lester Caine wrote:
Dan Scott wrote:
Right. And Wez posted this (partially in reply to Lester's almost
identical hysterics at that time) on this very list ages ago
(http://news.php.net/php.internals/14937 - Feb 14, 2005, to be exact):
BEGIN QUOTE:
Drivers are free(*) to implement driver specifi
Larry Garfield wrote:
On Tuesday 07 August 2007, Lester Caine wrote:
Lester Caine wrote:
Christopher Jones wrote:
Lester Caine wrote:
I keep being told that the PDO drivers can be extended to include all
of the things already available in the native driver, but the second
you do that they bec
Hi,
Its my understanding that ext/soap currently does not support
attachments (*). Is anyone working on adding this feature? If so is
there an ETA?
If not, has anyone been able to extend ext/soap to add this feature from
userland or is this even the intended way to get this feature. I must
Derick Rethans wrote:
On Wed, 1 Aug 2007, Andi Gutmans wrote:
This is not really a fix. When we worked on PHP 5 we deliberately
decided to relax on all the weird dynamic constructs which didn't
provide a lot of value for the majority of use-cases. Of course the
Reflection API was going to be
Sebastian Deutsch wrote:
hello,
is there a patch for the proposal out there? is anyone working on that
problem?
There might be a patch flying around ...
Last I heard from Marcus was that it seems impossible to find a solution
for this without accepting a slow down/memory footprint increase fo
Richard Lynch wrote:
Any gurus really offended by ereg can --disable-ereg or whatever it
is, no?
So in a dream world, Rasmus would have shipped all the features of PHP
42 as his first release.
In a slightly less dreamy, but still unrealistic world, we would have
infinite development resour
Johannes Schlüter wrote:
Ah, another thing kind of related to this thread: We really need a
proper way of having decisions declared as being made. Recently it
happened quite often that many developer's thought some decision was
made (for example from reading the Paris meeting notes) and then s
Pierre wrote:
On 7/18/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
Zeev Suraski wrote:
> Finally, at the risk of sounding like a broken record, we always
need to
> remember that BC breakage accumulates, and it's not binary. Every
> cleanup we do in PHP 6 will further
Zeev Suraski wrote:
Finally, at the risk of sounding like a broken record, we always need to
remember that BC breakage accumulates, and it's not binary. Every
cleanup we do in PHP 6 will further slow migration, and as Andi pointed
out a few days ago, things don't look too well as it is.
Agr
Rasmus Lerdorf wrote:
Derick Rethans wrote:
Regarding the unicode on/off modes, I don't think you put yourself in
the developer's view at all. Users are not going to be better of having
to deal with both modes.
Have you guys really thought this through?
Let's look at this from two angles.
F
Andi Gutmans wrote:
Hmm I don't quite understand what bad code vs. good code plays here.
Wordpress is one of the most popular applications out there so it's got
huge value to our community. I bet there's a huge amount of PHP
applications who's source code is of the same quality or worse. Anyway,
Andi Gutmans wrote:
Here's my proposed way of figuring how to make migration easier. Port
the following applications to PHP 6 and let's see what we can learn from
it:
- mediaWiki
- SugarCRM
- Drupal
- Wordpress
IIRC Wordpress is a good example of bad source code to fix. Drupal would
be a good
Larry Garfield wrote:
Non-core PHP developer speaking, so read with that in mind:
One of the things that held back PHP 5 adoption for so long, IMO, is the large
amount of FUD that surrounded it. Even now, 3 years after it was released, I
keep seeing the argument that "I can't drop PHP 4 and u
Andi Gutmans wrote:
There are clear things we want to change (like register_globals) because
we believe that ultimately they have a significant benefit to our users
with controllable downside (there is an easy one line workaround which
we can document for people to get their old apps to work). T
Ilia Alshanetsky wrote:
On 16-Jul-07, at 9:46 AM, Andi Gutmans wrote:
Why move it to PECL? I agree that PCRE is the preferred way but not
having ereg() will break a huge amount of applications for very little
gain.
I tend to agree, unless we provide wrappers via PCRE that emulate ereg
funct
Andi Gutmans wrote:
Even in PHP 6 I am not sure it's a good idea. There are a huge amount of
apps that use them and it'll be very hard for people to upgrade.
Anyway, let's do some more research on that once we get closer to PHP 6
and see what the migration path looks like. We'll have to check wit
Johannes Schlüter wrote:
Hi Lukas,
On Mon, 2007-07-16 at 08:48 +0200, Lukas Kahwe Smith wrote:
can you gives us a clarification on the question on if ctype will infact
be deprecated in PHP6?
ctype is not UTF-16 aware and therefore won't work with PHP 6 unicode
strings. Instead of ctype
Alexey Borzov wrote:
Hi,
Lukas Kahwe Smith wrote:
Just FYI: ctype is scheduled to be deprecated in PHP6.
...As stated by core PHP developer X at [Y]?
This was decided at the infamous paris PHP6 meeting and is still
listed on the php todo list on my wiki.
http://oss.backendmedia.com
On 11.07.2007, at 15:11, David Coallier wrote:
On 7/11/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
On 11.07.2007, at 14:06, Sebastian Mendel wrote:
> +1
>
> Guilherme Blanco schrieb:
>
>> Have you ever asked yourselves... why? why PHP5's adoption i
On 11.07.2007, at 14:06, Sebastian Mendel wrote:
+1
Guilherme Blanco schrieb:
Have you ever asked yourselves... why? why PHP5's adoption is so bad?
it was badly advertised!
most people don't even know how much faster it is!
to say nothing about of all the new features not known by most
On 11.07.2007, at 00:02, Andi Gutmans wrote:
I think the sooner the better as it's valuable information for the dev
team.
It'd probably be a good idea to have a Wiki where we can document
issues
that/common use-cases which are encountered.
Maybe we should have a Wiki on one of the php.net se
On 11.07.2007, at 07:15, Larry Garfield wrote:
On Tuesday 10 July 2007, Evert | Rooftop wrote:
Andi Gutmans wrote:
I think the sooner the better as it's valuable information for
the dev
team.
It'd probably be a good idea to have a Wiki where we can document
issues
that/common use-cases w
On 10.07.2007, at 18:55, Stanislav Malyshev wrote:
the application should define how things get loaded, precisely
because it decides about what libraries are used, what approach
each of them has taken etc. also on the application level you may
want to implement some way to override impleme
On 10.07.2007, at 09:17, Stanislav Malyshev wrote:
The application should define this, not the library or module...
Why not? If library needs to load files, why can't it define how to
load them?
-
the application should define how things get loaded, precisely
because it decides about w
On 10.07.2007, at 01:19, chris# wrote:
On Mon, 9 Jul 2007 14:38:03 -0700, Andrei Zmievski
<[EMAIL PROTECTED]> wrote:
Yes, backporting major features from PHP 6 to 5 will slow down PHP 6
adoption, and I'd like to avoid it if possible.
There is a way to run two engines side by side, by the
On 10.07.2007, at 00:06, Stanislav Malyshev wrote:
I know, and I use spl_autoload_register. But then I would blatantly
suggest to remove __autoload() in PHP6 and force SPL to be
compiled into
PHP.
I wouldn't go as far as removing it, but definitely would go as far
as not recommending to
On 08.07.2007, at 16:15, Alain Williams wrote:
On Sun, Jul 08, 2007 at 11:46:08AM +0200, Derick Rethans wrote:
On Sun, 8 Jul 2007, Stanislav Malyshev wrote:
The number 8 also has lots of meaning in Chinese culture. For
example
the Beijing Olympics will begin on 8/8/8 at 8:08:08 pm because
Jochem Maas wrote:
Pierre wrote:
On 7/6/07, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
There must be a reason to upgrade to a new PHP version (usually
features, maybe performance increase etc.). But there also must be no
reason not to upgrade. But you all know this, it has been said before.
N
Jani Taskinen wrote:
Antony Dovgal kirjoitti:
On 06.07.2007 14:04, Lukas Kahwe Smith wrote:
To me it boils down how we want to maintain the "fork":
1) PHP5 and PHP6
2) PHP6 unicode off/on (with PHP5 in maintenance mode)
Considering that people will not jump on PHP6 immediately
Stefan Priebsch wrote:
IMHO backporting a lot of features to PHP4 is a major reasons for the
slow PHP5 adoption. Basically, it seems that everybody who is not using
OOP feels that PHP4 is fine for them.
what was back ported aside from the memory corruption fix, which I am
sure even pushed a fe
Richard Quadling wrote:
So, all the time and effort going into PHP6 is for 1 maybe-used set of
functionality which also seems to slow down the entire system. I know
I MUST be missing something here.
yes you are missing the point both Anthony and I made, that if we remove
the unicode switch we
Rasmus Lerdorf wrote:
So yes, the only real customers for this full Unicode mode in PHP 6 are
going to be the folks that have full control over their servers and
their software which will likely limit it to hosted services and exclude
large PHP software packages that will necessarily need to be
gt;
To: Lukas Kahwe Smith <[EMAIL PROTECTED]>
References:
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
On 6/22/07, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
Pierre wrote:
> Hi Ilia,
>
> On 5/28/07, Il
Andi Gutmans wrote:
Well the point was just that Pierre enjoys complaining about everyone
else but doesn't deliver what he promised :) (yes I know he doesn't get
paid for it). Andrei and I have talked to him many times and we were
still hoping something's going to move on that front. If not I ass
Andi Gutmans wrote:
P.S. - Whatever happened to runtime JIT?
I think Dmitry is doing windows stuff and Pierre is busy as well. I
guess either one of them will do it, once they have time. Nobody else
has stepped up to take this on earlier.
Things are also not moving forward in the namespace
Andi Gutmans wrote:
Some people here said that we weren't successful in keeping BC between
PHP 5 and PHP 4. Whoever said that must not have migrated applications
between the versions. It took very little effort to do so. Most people I
know did it in a matter of hours for sizeable code bases and
Hi,
I think that PHP6 adoption will obviously come down to exactly how much
slower unicode support will make things. If its a 10% drop, I think we
will probably find ways to smooth out the kinks with some nice tweaks
here and there. If it gets considerably above 10%, then it will be more
tric
Pierre wrote:
On 6/19/07, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
But this is no different from writing code that will work on both PHP 5
and PHP 6. The only difference is that instead of checking for PHP 5
you will be checking for Unicode. Like I said, we don't want the
Unicode decision to
David Zülke wrote:
Yeah, not to mention things like temp dirs, sendmail/smtp settings etc...
meaning to make it really useful, we would need a general way to handle
such platform difference. maybe with a syntax to handle platform
specific settings or prefixing of directories, but I guess then
Stanislav Malyshev wrote:
Well the problem is that I am trying to cache soap replies in APC.
This seems to be buggy but at the very least will require a
serialize/unserialize call, which again adds overhead.
Wouldn't array require serializing too? Or APC is able to store arrays
in unserialize
Stanislav Malyshev wrote:
Well, theoretically I can imagine reason why somebody would like to
disable them - e.g., if I need super-high-performance server and I
absolutely must squeeze out every last bit of cpu/memory usage _and_ I
don't do neither SPL nor regular expressions - I might want to
Dmitry Stogov wrote:
I don't like to increase complexity of ext/soap with additional options.
It is already complex enough and simple object <-> array conversion doesn't
provide additional abilities.
Well we have way more functions to "play" with arrays than we have with
objects. Considering
Hi,
Hopefully I am not overlooking something here, but I never really
appreciated the fact that all my complex types are returned as stdClass
instances by default. Of course you can override this with custom
classes via the classmap, but I would much prefer simple boring arrays.
This has now
Pierre wrote:
It should not be possible to disable it. Or even better, we should
move what we consider as core from SPL to Zend.
Amen.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Antony Dovgal wrote:
On 05.06.2007 11:25, Sebastian Bergmann wrote:
Antony Dovgal wrote:
Hello Sebastian.
Hello Antony,
What's the status of this?
Do you have anything working?
back in February/March when I first posted about this, I discussed this
with Marcus. The conclusion was that
Hello,
getting back to the original point of Philips email. What is the
relation between PECL, especially for packages that make it into core?
Does making it into core mean that the PECL package is removed (unless
the developer in question is willing to continue maintance)?
Or is it maybe ti
Antony Dovgal wrote:
On 31.05.2007 13:04, Jani Taskinen wrote:
Antony Dovgal kirjoitti:
On 31.05.2007 03:29, Jani Taskinen wrote:
The whole idea of having that number there is pretty stupid..why not
just remove them altogether..?
Well, in some places it's just not possible, like libphp6.so e
Hi,
So I guess what we need is to figure out a bit what our current
development process is, what if it we actually want to keep and what we
are hoping to get in the future. Maybe we can brainstorm at php|vikinger
on this. One of the "processes" we have is that we have no formal
processes and
Andi Gutmans wrote:
Well I think Subversion the way it is today is already considerably
better. Just the directory versioning and the better performance would
already pay off in the PHP project.
No doubt that merge tracking is an added bonus but it's not exactly
applicable (yet) to the way we wor
Christian Schneider wrote:
Stut wrote:
It doesn't matter where the session ID comes from, the basic point is
that you have to trust it or implement some experience-degrading
mechanism like client certificates, and even there there are few
guarantees.
You want more info to be checked? Simply
Wez Furlong wrote:
Once we have that data, we could have job that periodically (daily)
reviews the activity per bug report and sends an email reminder about
reports that have missing merge activity for longer than a week.
Wouldnt we then also have to have some flag on the bug to make it clear
Hello,
A client alerted be to an issue caused by emulate prepare in combination
with LIMIT clauses:
http://bugs.php.net/bug.php?id=40740
The problem is that any integer that should be inserted into a clause
like "LIMIT ?, ?" would be quoted, which MySQL (same I would assume is
the case with
Lester Caine wrote:
Wez Furlong wrote:
I'd modify that to say that no one with the C skills is interested in
taking it over, and there is almost no incentive to do this because
"no one" uses it.
I would not say that on the firebird-php list Wez - one hell of a lot of
people rely on it for the
Lester Caine wrote:
PDO simply changes the ground rules without solving any particular
problem as has been said all along. Now you may well convince people
that all the native drivers should be dropped from PHP and only PDO
supplied but I hope that does not happen and that we have a PROPER
de
Wez Furlong wrote:
On 5/7/07, Lester Caine <[EMAIL PROTECTED]> wrote:
No one has time to work on the
Firebird PDO driver because we still need the main driver to provide the
functions PDO does not support.
Umm, no. Nobody has time for firebird because nobody uses it.
I ask people about Firebi
Stanislav Malyshev wrote:
There is no reason to have PHP_Archive in a phar. No need whatsoever...
it would be a waste of space! Not having the extension would lead to
Yes, the whole whopping 20K of space uncompressed and with comments, so
could be probably 10K or less without comments, whitesp
Stanislav Malyshev wrote:
I also just realized, these are also all tools where you probably do
not want APC to store the bytecode in memory. Furthermore it is
however still quite useful to have your unit test executing quickly.
How speed of the tests would depend on speed of the loading phpuni
Gregory Beaver wrote:
Stanislav Malyshev wrote:
I think it is a good reason. There are plenty of tool-like PHP
applications. Not having to "install" these, but just be able to
I know one - PEAR. And it's kinds special because it's library
installer. What others are there?
phpdocumentor, phpu
Stanislav Malyshev wrote:
serving them as a static page. But applications like S9Y, FUDForum,
phpMyAdmin where the *typical* usage is not to serve a large number of
users, this is usually not an issue.
In other words, it is not meant to deploy production applications, only
local-user applicat
Stanislav Malyshev wrote:
I think it is a good reason. There are plenty of tool-like PHP
applications. Not having to "install" these, but just be able to
I know one - PEAR. And it's kinds special because it's library
installer. What others are there?
Documentation and other code analyis too
Stanislav Malyshev wrote:
? Nobody is talking about sessions here, just about the serialize()
You mean you are not talking about sessions. I, however, do. Sessions
are one of the obvious examples where such functionality could improve
performance.
Well as the topic implies I am quite sure t
Stanislav Malyshev wrote:
either Greg or me as PHP customers. Nor was Phar designed to solve
that particular issue alone. It was designed to deliver a stable and
fast implementation of PHP_Archive that can be bundled into PHP as
a C extension.
That's fine, the question is why exactly we need fa
Stanislav Malyshev wrote:
can write this data to disk. So, you needs 20MB. If serialize (and of
course unserialize) would be able to write directly to disk (or read
directly from disk), you only needs 10MB.
Actually having serialize/unserialize be able to write directly to a
stream and read d
Mike Robinson wrote:
It could well be the last chance to get the mail() logger into 5.x as well,
and IMHO a lot of
people are waiting for this that can't/won't migrate to PHP6 quickly.
i have added it to the open discussion items for 5.2.3:
http://oss.backendmedia.com/PhP52
regards,
Lukas
--
Antony Dovgal wrote:
On 05/07/2007 04:18 PM, Lukas Kahwe Smith wrote:
Marcus Boerger wrote:
Well alot of people make use of our PEAR project. It comes with a
bunch of
nice sub projects. And even some external (as in non PHP)
applications and
projects make use of it. Providing a better
Stanislav Malyshev wrote:
It means you can run a phar file. How is that so hard to understand.
It is not hard to understand. What seems to be hard to understand is
that the scenario you describe is by no way the only scenario PHP files
run in. Not all applications are single entry point and o
Marcus Boerger wrote:
Well alot of people make use of our PEAR project. It comes with a bunch of
nice sub projects. And even some external (as in non PHP) applications and
projects make use of it. Providing a better internal infrastructure would be
very nice here.
Stas, not sure if you are awa
Ilia Alshanetsky wrote:
IMHO one good reason to start a new branch for 5.x would be the ability
to get rid off register_globals and magic_quotes in the 5 series without
having to wait for PHP6 to come around.
What would be the goal of that? Making it less painful to migrate to PHP
6.x since t
Stanislav Malyshev wrote:
expect some people to hold exactly the opposite opinion. The question is
however is phar so important that everybody needs it in the main source?
Yup, that is indeed the question. Like I said I think it is important
enough.
regards,
Lukas
--
PHP Internals - PHP Ru
Ilia Alshanetsky wrote:
On 4-May-07, at 3:14 PM, Lukas Kahwe Smith wrote:
Yes, to me the question is only if we want to give the message that
software producers should be able to expect phar to be there on 99% of
the systems. Thats the only way that phar has a good chance of really
taking
Edin Kadribasic wrote:
Antony Dovgal wrote:
What's the problem with having it in PECL?
I'm sure everybody interested in it can get it working in no more than
10 seconds using `pecl install phar`.
PECL is great, but it does require a build system with increasingly
obsolete set of tools (autocon
Hello,
does anyone have a patch for PHP6 to add late static binding?
have we agreed on the syntax?
IIRC, static:: as the favorite ..?
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev wrote:
I'm not having much spare time lately, but I'd like to continue
working on the patch as soon as I can. Will the patch be needed only
on PHP 6 or is there a possibility of including it in a minor version
(5.3 or 5.4, perhaps)? If it's only for 6, I'll try to adapt my pa
Guilherme Blanco wrote:
I think the best separator is :::
thats not what i asked :)
and it should not be the issue we focus on at this point either.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
Andrei asked me to bring up the topic of namespaces again. From the
meeting notes [1] and the following discussion it seems like we agreed
(once more) to include namespace support in PHP6. However after a time
where we saw a flurry of patches, things have died down. Also Marcus
does no
Hello,
From my understanding the main thing that is holding back a first
preview/alpha release of PHP6 is solving the below explained issues in
the JIT parameter handling. Pierre and Dmitry were the two most likely
candidates to implement this, but I guess both of them are busy (?).
Maybe som
Davi wrote:
Em Domingo 22 Abril 2007 21:34, mbneto escreveu:
Hi,
I saw one post earlier at php-general asking for a list of recommendations
/ practices that should be followed to guarantee that code will run fine
when PHP 6 comes out.
I am giving a talk on this at MySQL User Conference. I wil
Christian Schneider wrote:
I'm with Lukas there about the E_STRICT/E_DEPRECATED split but I'm not
Feel like working up a patch for 5.3 for this? :)
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Marcus Boerger wrote:
Hello Sebastian,
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
yes .. but given no changes to all of the above men
Hey,
I have a few more questions:
Other Additions/Changes:
7. add E_STRICT to E_ALL DONE (dmitry)
Currently the plan is to split E_STRICT into E_STRICT and E_DEPRECATED
in PHP 5.3. Once we do that I think this change should be adjusted to
only include E_DEPRECATED in E_ALL and not E_STRICT.
Hey,
What is the status regarding reflection and spl. Do we still want to
allow disabling?
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
FYI I have updated the todo list according to the recent discussions:
http://oss.backendmedia.com/index.php?area=PHPTODO&page=PhP60&view=diff&to=2007-04-17+10%3A47%3A32&from=2007-04-12+16%3A32%3A02
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
701 - 800 of 900 matches
Mail list logo
