On 03.02.2008, at 18:24, Steph Fox wrote:
Hi Marcus,
Anyway my idea is to start everything in PECL and
to to move everything out that can be moved out. And that includes
all MySQL
extensions as well as SQLite. Only this way people will use the PELC
infrastructure. Otherwise we would just
On 03.02.2008, at 19:24, Steph Fox wrote:
I see no point to discuss solutions for some unknown entities willing
to contribute when they do not consider to introduce themselves.
When
they don't explain clearly why we should do the move and what will be
the actual gains for us (read: for us
On 03.02.2008, at 20:04, Steph Fox wrote:
Moin Lukas,
Now, PECL has a couple of CLA'd modules already. I don't like
them being there, and you have stated your own opinion loud and
clear. I think we should be looking for some way to separate out
CLA'd PECL modules to elsewhere but
On 01.02.2008, at 23:05, Pierre Joye wrote:
2008/2/1 Marcus Boerger [EMAIL PROTECTED]:
Crosspost, hopefully silencing this issue for 5.*
AND 6 will have an E_WARNING or even an E_ERROR on this.
What are the gains?
What are the real reasons behing strictness? I really get annoying by
On 22.01.2008, at 04:14, Andi Gutmans wrote:
I don't think this affects PHP 5.3 (http://wiki.pooteeweet.org/PhP53VoteResult
) which I believe we're making good progress on. It allows us to get
some of those features out earlier including things like namespaces
which the various framework
On Jan 17, 2008, at 10:17 , Stefan Esser wrote:
When someone injects you a cookie like +++action=logout through an
XSS or through a feature like foobar.co.kr can set cookies for
*.co.kr
(in FF atleast).
Ok, you are assuming one security issue here, that is not related to
the topic.
On Jan 16, 2008, at 9:17 , Stefan Esser wrote:
Stanislav Malyshev schrieb:
@Richard: You don't understand the Problem with _REQUEST. It is not
about the fact that someone can forge GET, POST; COOKIE variables.
It is about the fact that COOKIEs will overwrite GET and POST data
in
REQUEST.
On Jan 16, 2008, at 11:55 , Stanislav Malyshev wrote:
I dont understand the problem. You use request if you do not care
where a parameter is set and you use the other superglobals when
you do care.
The problem is that variables_order should specify what gets into
_REQUEST (as documented
On Jan 14, 2008, at 4:34 , Pierre wrote:
On Jan 14, 2008 2:58 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Voting to achieve what?
Fair decisions in a simpler, effective and right manner (and not
discutable, ideally).
I do not consider fairness, whatever that could mean, having
Hi,
I think its painfully obvious that a system to manage the voting is
needed. Like I said, ideally it should also have an email interface.
People should be able to vote from +1 to -1 and be able to add a
comment. Notifications should be send to this list about the start and
final
On Jan 10, 2008, at 8:57 PM, Lukas Kahwe Smith wrote:
On Jan 10, 2008, at 4:55 PM, Antony Dovgal wrote:
On 10.01.2008 18:33, Derick Rethans wrote:
On Thu, 13 Dec 2007, Gregory Beaver wrote:
We don't need moderation, we don't need read-only. We need
people to
follow a simple common
On Jan 11, 2008, at 1:18 PM, Pierre wrote:
+1 (for the record in this thread :)
-1
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Jan 10, 2008, at 1:05 PM, Joe Orton wrote:
I'm not sure I find the logic of the but the system-provided data
will
become stale arguments convincing; systems which are left
unmaintained
by the administrators will have old versions of software on; that's a
given. I can't see why adding
On Jan 10, 2008, at 3:12 PM, Tomi Kaistila wrote:
Well if confusing is the goal, then yes, since this is classic Perl.
I started using PHP, instead of Perl, just so that I would not need
play
around with confusing syntax.
Right, PHP was always about making it easy to see whats going on
On Jan 10, 2008, at 4:51 PM, Ilia Alshanetsky wrote:
On 10-Jan-08, at 10:33 AM, Derick Rethans wrote:
On Thu, 13 Dec 2007, Gregory Beaver wrote:
We don't need moderation, we don't need read-only. We need people
to
follow a simple common-sense checklist.
It's either that nobody saw
On Jan 10, 2008, at 4:55 PM, Antony Dovgal wrote:
On 10.01.2008 18:33, Derick Rethans wrote:
On Thu, 13 Dec 2007, Gregory Beaver wrote:
We don't need moderation, we don't need read-only. We need people
to
follow a simple common-sense checklist.
It's either that nobody saw this mail, or
Hi,
I am still wondering if we ever going to get a summary of this
discussion.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Jan 4, 2008, at 6:37 PM, Robert Cummings wrote:
On Fri, 2008-01-04 at 18:23 +0100, Pierre wrote:
On Jan 4, 2008 6:20 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
Hello Pierre,
we never accepted this as a pro argument. Infact we often saw the
necessaity to highlight something is optional
Hi,
Ok here is a genious idea. We call for a 24 hour period of silence on
this topic. All people eager to post just re-read all previous emails
and once the 24 hours are over you know what has been said already so
that you can actually make sure to say something novel. What would be
even
On 21.12.2007, at 19:38, Stanislav Malyshev wrote:
Sounds to me like we should stop accepting this legal BS. Then
they will only be able to pay for a nice little house if they
write understandable stuff or nothing is they are unwilling to
adapt to the demands of their customers.
It is
On 21.12.2007, at 10:08, David Zülke wrote:
I wonder why they need such elaborate bla bla to just say so
trivial things. The copyright part seems irrelevant given your
assessment and the patent clause seems overly complex if all they
are saying that any patents that are infringed upon by
On 30.11.2007, at 00:09, Steph Fox wrote:
Stas - we don't even know what they're planning to put into CVS.
Just
And waiting couple of days for the explanation is of course not an
option.
But opening up a module in the php.net CVS repository that php.net
contributors are excluded from
On 20.12.2007, at 16:31, David Zülke wrote:
No. This Apache CLA most of today's CLAs used by open source
projects (Zend Framework, Cake etc) are derived from require you to
grant an unlimited, unrevocable, royalte-free, blah-blah license to
use your contribution, and, if _you_ hold
On 20.12.2007, at 17:07, Marcus Boerger wrote:
should ever be necessary. And to Lukas, you either violated a signed
agreement here by telling us stuff you learned while being part of
that
group - or you are speculating. You should however not do that!
Maybe not
even IBM is interested in
On 04.12.2007, at 23:41, Steph Fox wrote:
Can I just ask one thing? If namespace support is once again pulled
before it sees the light of a release, can we _please_ document
exactly what the problems were, loud and clear, and put the
document somewhere people are likely to see it?
On 20.12.2007, at 17:57, David Zülke wrote:
Then read it again. It's pretty clear.
3. Grant of Patent License. Subject to the terms and conditions of
this Agreement, You hereby grant to the Foundation and to
recipients of software distributed by the Foundation a perpetual,
On 20.12.2007, at 18:41, Stanislav Malyshev wrote:
grant the same for those patents you own. Those CLAs do not
require that you guarantee that your contribution is not violating
any 3rd-party patents.
Nobody can require that, that'd be stupid - how one can guarantee
nobody has patent to
On 20.12.2007, at 18:58, Stanislav Malyshev wrote:
BTW - I hope you don't think that if you didn't sign the CLA and
you contributed code to PHP that you didn't have rights to
contribute, not signing would help you in any way. Or that if you
contributed code that violates patents, not
On 20.12.2007, at 19:19, Stanislav Malyshev wrote:
Of course. The only difference being that if users of my code
cannot fallback on a CLA as a deflector, they have a much bigger
interest in
Deflector of what? CLA gives the users of the code reasonable - not
100%, but reasonably good -
On 20.12.2007, at 20:54, David Zülke wrote:
Am 20.12.2007 um 19:25 schrieb Lukas Kahwe Smith:
So maybe enlighten me what the purpose of the CLA is.
The purpose is that a project/company/whoever has written
confirmation that the developer who contributes something gives the
respective
On 28.11.2007, at 00:28, Pierre wrote:
One word: transparency.
It is amazing how it helps to discuss things instead of acting like
that.
I find it amazing how oblivious to community concerns this all is.
Anyways, from some other discussions I gathered that the main thing
that is
On 21.11.2007, at 16:26, Nuno Lopes wrote:
Hi,
I was assigned a class work in the university to compare web
applications architectures, mainly PHP vs
Java+Hibernate+Struts/Stripes. I'll need to provide some benchmarks
for some typical web apps.
Well, I'm a bit afraid that Java may win,
On 20.11.2007, at 10:02, Hans-Peter Oeri wrote:
Not sure how real world useful this is. What I have seen more is a
I often run into a situation like the following: We need a framework
like class to change *joined* tables. The framework itself has no
inherent knowledge about table fields, but
On 19.11.2007, at 09:00, Stefan Esser wrote:
Wietse Venema schrieb:
Stefan Esser:
2) Using mysql_real_escape_string() on user input does not make
it safe
for SQL. It only makes SQL strings safe.
Example: SELECT * FROM table WHERE id=.mysql_real_escape_string
($id)
is NOT secure but will
On 18.11.2007, at 12:27, Gergely Hodicska wrote:
Hi!
I read this thread, and I would like to ask if is there any
decision about the behavior of inheritance?
I wrote on my blog about late static binding (http://blog.felho.hu/
what-is-new-in-php-53-part-2-late-static-binding.html), and I
On 10.11.2007, at 22:34, Gaetano Giunta wrote:
plus a 3 numbered version is very easy to assign to a lib (you
know, like a new param for a function bumps up the middle number,
a fix - any fix - bumps up the rightmost one etc... )
That is what $Revision$ CVS tag does, version number is
On 19.11.2007, at 14:05, Alexey Zakhlestin wrote:
On 11/19/07, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
I think the point of Stas reply was to use self:: instead of
parent::.
how would self help? that would mean calling this exact method, not
the method of parent-class
that way you
On 19.11.2007, at 16:26, nick loeve wrote:
On Nov 19, 2007 4:21 PM, Alexey Zakhlestin [EMAIL PROTECTED] wrote:
imho, exceptions are preferrable in a lot of php's functions…
but core php programmers are usually against exceptions if it is not
an error of object-constructor
Well in this case
On 19.11.2007, at 21:50, David Zülke wrote:
Am 18.11.2007 um 22:53 schrieb Lukas Kahwe Smith:
Stefan so what is your point then? Since neither can be 100%
secure, do not use any? Or just do not bundle either?
Yes, that is exactly the way to go. To quote Yoda (and he would
know): Do
On 19.11.2007, at 21:09, Hans-Peter Oeri wrote:
FETCH_2D is the core of my proposal. It's like the
ATTR_FETCH_TABLE_NAMES, enhanced in arrays. Columns are to be found on
the second level:
$result[tablename][columname]
Not sure how real world useful this is. What I have seen more is a
need
On 20.11.2007, at 00:47, Lukas Kahwe Smith wrote:
On 19.11.2007, at 21:09, Hans-Peter Oeri wrote:
FETCH_2D is the core of my proposal. It's like the
ATTR_FETCH_TABLE_NAMES, enhanced in arrays. Columns are to be
found on
the second level:
$result[tablename][columname]
Not sure how real
On 18.11.2007, at 14:00, Stefan Esser wrote:
Hi Stefan,
It is therefore obvious that the GRASP way cannot be made fast and
that
Venema's implementation will always be faster.
I wonder how other languages solve this dilemma? Like how does Ruby's
taint model work? What are the experience
On 18.11.2007, at 22:40, Stefan Esser wrote:
Hi Dan,
I believe the primary use case for taint mode would be to use it in
development: taint mode is a mode which can be turned on to give you
an idea of where your application may have exposed some
vulnerabilities; let you fix those identified
On 18.11.2007, at 22:56, Stefan Esser wrote:
This is different from the implicit untainting through htmlentities()
and mysql_real_escape_string() because there
are obviously cases where these functions are the WRONG functions and
the developer will never realise this
because he was not taught
On 14.11.2007, at 15:55, Hans-Peter Oeri wrote:
I just needed ATTR_FETCH_TABLE_NAMES support in pdo_firebird. W/o any
knowledge about PHP politics, please let me humbly offer the
corresponding patch.
Driver specific attributes and methods should be prefixed accordingly.
What does this option
On 14.11.2007, at 16:30, Hans-Peter Oeri wrote:
Hi1
Lukas Kahwe Smith wrote:
Driver specific attributes and methods should be prefixed
accordingly.
What does this option do btw? Is this about qualifying column names
with the table name? In that case this is something that should maybe
Hi,
A few pointers and ideas:
1) ext/pgsql has support for asynchronous queries (pg_send_query()
and friends)
2) maybe you can create something out of MySQL Proxy that splits out
a single query into multiple queries and then rejoins them
3) since MySQL AB is actively developing a new
On 26.10.2007, at 20:44, Andi Gutmans wrote:
Why is it not an if() statement?
-Original Message-
From: Ben Ramsey [mailto:[EMAIL PROTECTED]
Sent: Friday, October 26, 2007 10:38 AM
To: internals@lists.php.net
Subject: [PHP-DEV] [PATCH] Generate warning when using
PDO::setAttribute()
On 22.10.2007, at 17:31, Marcus Boerger wrote:
Hello Lukas,
I think all pecl modules should follow the core rules and that means
CODINT_STYLE should apply to pecl as much as it does to core. We
should
hence provide an easy to read (as in html or pdf or whatever)
version that
is
On 17.10.2007, at 22:11, Marcus Boerger wrote:
Hello Derick,
right, maybe we need writen down rules easy to read for pecl and
core
other then the CODING_STYLES bile.
So how do you propose to proceed? What is not easy to read in the
current CS? Should the note about not throwing
On 19.10.2007, at 02:20, Larry Garfield wrote:
On Thursday 18 October 2007, Lukas Kahwe Smith wrote:
The possibility of changing the error mode at run-time makes it
quite
hard to read code. Since you always have to check the error mode of
the
object you're currently looking at. Therefore I
On 18.10.2007, at 12:29, Johannes Schlüter wrote:
Hi,
On Thu, 2007-10-18 at 11:45 +0400, Antony Dovgal wrote:
On 17.10.2007 20:09, Lukas Kahwe Smith wrote:
Hi,
I remember that we discussed the question of exception throwing from
core in the very early days of php 5, when the suggestion
Hi,
I remember that we discussed the question of exception throwing from
core in the very early days of php 5, when the suggestion of turning
all errors into exceptions first came up. I remember that we decided
that exceptions should only be thrown from core on constructor errors
by
On 16.10.2007, at 13:43, Hans Moog wrote:
I agree. But PHP (until PHP 5.2.x) was the wrong language for
everyone who wanted to use namespaces, too.
But a programming language is able to evolve and sometimes new
features are really usefull and should be included. And in this
special case
On 16.10.2007, at 15:09, Hans Moog wrote:
When it comes to interoperation between systems and or developers,
it is always a
good idea to define strict standards of how the communication
between libarys and components
has to take place (since public methods are something like an
On 13.10.2007, at 18:46, Hans Moog wrote:
Will method overloading by method signature be implemented in php6 or
even php 5.3?
this feature isnt php .. or rather its a solution to a problem that
does not exist in php .. for good reason.
regards,
Lukas
--
PHP Internals - PHP Runtime
Hi,
I updated the 5.3 todo list [1] yesterday evening. I also just
spotted a minor mistake. I put the visibility patch under todo items,
where it should have gone under future releases. We should also
revisit the 5.2 todo list [2] and see if the items there are not yet
done and if they
Steph Fox wrote:
So I'm with Ilia over all that. The question is who? Used to be that
whoever felt they had the time to do it could, so long as nobody fought
the proposal. I don't see anyone fighting against your proposal for
Johannes (I wouldn't either) but I also agree with Pierre's
Jani Taskinen wrote:
On Wed, 2007-09-26 at 17:20 -0700, Stanislav Malyshev wrote:
The 5.3 branch was just created in the CVS and is now open for
development. Please remember to MFH/MFB your patches to this branch when
making your commits.
Maybe it would be a good idea to start 5.2.5 release
Andi Gutmans wrote:
+1 and I think it's a good way for someone to get into the role.
I do not see why we need this delayed hand over. RMs managed to take
over during the process in the past and today we even have a check list
for this purpose. The main challenge is managing the politics on
Lukas Kahwe Smith wrote:
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
Dmitry Stogov wrote:
I am not sure which behavior shouldbe in final patch.
It seems like support for inheritance provides more flixebility, but makes
concept harder to understand.
Well inheritance is an advanced OO concept. As such its something that
requires a bit of getting into. But
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
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
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
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
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
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
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
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
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
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
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
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
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
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 add new
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
feature
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
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:
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
generated
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
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
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
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
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
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.
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.
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 slow migration
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
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).
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
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
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,
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
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
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
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
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
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
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
601 - 700 of 846 matches
Mail list logo
