this
through all the way. So in the end we might end up having to break BC
once more in PHP 6.0. Also its not like we are fixing these bugs
because users were submitting bug tickets about this (or have they?).
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development
.
This would allow memory-efficient creation of large packets.
Andrei is the maintainer for the WDDX extension.
Could you give Mark some feedback here?
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
Hello All,
First up thanks for this every efficient thread!
Really makes the life for Johannes and myself a lot easier when we can
so easily get an overview of the opinions on internals.
After having discussed the results, we want to publish our
conclusions ..
1) ext/mhash in 5.3.
circumstances.
So what if we for now stick with the BC fix?
However maybe for PHP 6.0 we should make a real effort to figure out
how objects are supposed to be handled in our PHP type juggeling world.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
not clear how things should behave, we
should just go by how things behaved in 5.2.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
Thank you all for participating and raising any issues/concerns in a
concise manner. I will tally up the votes sometime over the weekend
and discuss the results with Johannes. We will then post what
decisions we will take based on the votes (though in some cases we
might need to hold
Hi,
Can anyone write up a summary of the situation and the options we have?
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)?
On 12.11.2008, at 20:14, Lukas Kahwe Smith wrote:
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire
BC break will be that if (extension_loaded('mhash')) will need
fixing if mhash is removed (answer both)
I) enable ext/hash by default
+1
II) remove ext/mhash
+1
2
) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
by the time
of 5.3-final, we can always provide an extra package with these
packages but with a (very) strong warning about using them in
production environment.
I agree.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
to actually care about bugs in output
buffering and that they will take care of any BC issues that pop up,
Johannes and I might reconsider our decision to not MFH OB.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
On 10.11.2008, at 12:04, Jani Taskinen wrote:
Lukas Kahwe Smith wrote:
On 10.11.2008, at 11:41, Jani Taskinen wrote:
2. Change ext/ereg to be disabled by default (scheduled to be
removed in PHP 6, iirc?)
IIRC we are not yet in agreement on the removal. AFAIK its already
an extension
On 10.11.2008, at 11:42, Lester Caine wrote:
Pierre Joye wrote:
On Mon, Nov 10, 2008 at 9:22 AM, Lester Caine [EMAIL PROTECTED]
wrote:
Lukas Kahwe Smith wrote:
There is still the problems with windows builds of PHP5.3. I've
not been
able to test anything on new builds since php_interbase
/mhash is just to allow if extension mhash
exists .. ? I think this is easy enough for people to fix by replacing
this check with an function_exists() check.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
On 10.11.2008, at 12:06, Jani Taskinen wrote:
Marcus Boerger wrote:
Hello Jani,
Monday, November 10, 2008, 11:41:44 AM, you wrote:
Lukas Kahwe Smith wrote:
Hi,
I just wanted to ask everybody to skim over the changes for PHP
5.3 we have in CVS (especially bigger stuff like the addition
,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-newlink.diff
seems like a good idea to have this and i guess there is no other
choice but to stick it at the end of the function parameter list.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
up a debate again on namespace syntax or resolution orders (I
hope to have the final behavior in CVS ASAP). This is just an attempt
to ensure we do not forget something.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
PS: I know this might sound like an invitation for a flame war, it
isnt
On 07.11.2008, at 09:30, Pierre Joye wrote:
hi!
On Fri, Nov 7, 2008 at 9:29 AM, Hannes Magnusson
[EMAIL PROTECTED] wrote:
On Thu, Nov 6, 2008 at 22:00, Lukas Kahwe Smith
[EMAIL PROTECTED] wrote:
Hi,
This are tentatively looking like alpha3 could hit on November 18th.
So everybody please
Drupal, Joomla etc. to reduce
side effects.
NO!
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
This are tentatively looking like alpha3 could hit on November 18th.
So everybody please try to get whatever you are working on ready to be
finished and committed by no later than 13th. So that packaging can
happen on a stable tree on the 17th.
regards,
Lukas Kahwe Smith
[EMAIL
the bug as fixed once the patch is applied?
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
a question: How hard would it be to implement in case we do want
this?
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
compromise, but you would do us
all a favor if you would stop killing off open thinking with useless
metaphors about 85 year old ladies.
thanks ...
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
obvious that this is not the ideal case for
performance to begin with, and the sole reason is to be able to run
even in the absence of the ideal situation for performance where the
function would be provided via an extension.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals
On 31.10.2008, at 19:02, Lukas Kahwe Smith wrote:
Hi
I have tried to collect the various opinions on resolution order
into a single RFC:
http://wiki.php.net/rfc/namespaceresolution
Proactive damage control:
I have also included some discussion on how the removable of
function/constants
the question of
resolution.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
pointed out, there is no autoload for functions, so people are
accustomed to ensuring that all functions are loaded before usage. Am
I missing something?
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
: 1000
identical array time: 0.00043511390686035
count: 1000
-shire
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
breaking actual code out there. The practice of passing traversable
objects to our views, mixed with real arrays, is already common (I
do it too).
so where do we stand here?
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
On 27.10.2008, at 08:26, Kalle Sommer Nielsen wrote:
2008/10/27 Lukas Kahwe Smith [EMAIL PROTECTED]:
On 27.10.2008, at 06:16, Kalle Sommer Nielsen wrote:
2008/10/26 Johannes Schlüter [EMAIL PROTECTED]:
On Sun, 2008-10-26 at 14:32 +0100, Kalle Sommer Nielsen wrote:
So, I propose its
On 24.10.2008, at 14:15, Felipe Pena wrote:
Hi youngs,
What about moving mSQL to pecl? :)
Derick copied it to pecl .. and i will delete it from php-src asap.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
On 04.11.2008, at 23:02, Lukas Kahwe Smith wrote:
On 27.10.2008, at 08:26, Kalle Sommer Nielsen wrote:
2008/10/27 Lukas Kahwe Smith [EMAIL PROTECTED]:
On 27.10.2008, at 06:16, Kalle Sommer Nielsen wrote:
2008/10/26 Johannes Schlüter [EMAIL PROTECTED]:
On Sun, 2008-10-26 at 14:32 +0100
,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
the movement of extensions between pecl and php-src. also a
pitty that the GSoC for a unified bug tracker apparently did not get
finished (?)
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
something to get rid of this fear (though probably never
entirely), i think we have a chance of improving the general tone and
productivity of this list.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
appended to all emails (including the welcome
email) ..
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
be higher
so less misconceptions will need to be cleared later (and
misconceptions have a way to spiral into flamewars).
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
than usual before replying. Maybe someone else will
already make the point you want to make and in the mean time you can
think things over and optimize your message.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
PS: I have published the above text as an RFC on the wiki ..
http://wiki.php.net
on the above.
Regards,
Christian
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
and deployment nightmares.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
(why deprecate if we do not remove?).
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 24.10.2008, at 14:15, Felipe Pena wrote:
Hi youngs,
What about moving mSQL to pecl? :)
I guess thats a go then.
Derick you said you could handle the move?
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
is the PHP spirit), while its brain dead easy
to detect misuse.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
userbase. we let people grow with their
needs.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to fix their performance
issues (if they have any) without having to open a manual.
in your scenario, all examples in the world will mysteriously break
when they are used inside a namespace (which they might have gotten
from another example or some inherited code).
regards,
Lukas Kahwe Smith
in this discussion are actually aware of this). So do us all the favor
and stop and think a second before you post the next time.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 26.10.2008, at 21:59, Pierre Joye wrote:
Hi Lukas,
On Sun, Oct 26, 2008 at 11:28 AM, Lukas Kahwe Smith [EMAIL PROTECTED]
wrote:
Sebastian, you have not participated in the discussion so far. Now
you post
a rumor you picked up on IRC into an already heated situation. You
do know
full
coherent before
posting to internals (in the spirit of signal to noise ratio).
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
.
As the patch is still under development it is yet unclear how this
will affect the scheduling PHP 5.3.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
[1] http://wiki.php.net/rfc/namespaceseparator
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
ago, but noone seemed to care, and I had
no use for it myself so I never bothered merging it :)
The functionality is rather handy (I think), I would +1 for its
addition to the 5.3 branch.
if someone commits it before alpha3 its fine by me.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED
a decision just yet.
Hopefully next week ...
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
words in their sentences. Accept this or accept that your
emails will go to /dev/null. Your choice.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to be autoloadable must make
sure he explicitly triggeres the autoloading.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 16.10.2008, at 18:59, Greg Beaver wrote:
Lukas Kahwe Smith wrote:
On 16.10.2008, at 17:37, Stanislav Malyshev wrote:
B. There's a huge problem with this proposal which you seem
consistently to ignore despite all my attempts to explain it. Failed
autoload on each call is BAD. Very bad
. the
question now is .. does someone else care enough to work through the
issues Stas has noted to get things in shape to be committed?
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
with a reproduceble test case that
illustrates the conflicting behavior with the manual.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
So I guess the conclusion is:
Create a feature request ticket, take the information from this thread
and put it into the ticket .. and ideally write a patch yourself or
motivate someone else ..
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
to a class, you need to move them all to a
single file.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
would be willing to update the README in a
timely manner after finishing a patch, in case we go for 3) or 4). I
hope we can also find the time to transfer any changes to docbook
quickly after this.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development
,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 14.10.2008, at 15:03, Markus Fischer wrote:
Hi,
Lukas Kahwe Smith wrote:
That being said I never used this function or the constants in my
code. So is there anyone that does actually use it and has some
objection?
Me neither, but in such cases it's probably a good idea to take
for the record, I was suggesting to add the E_STRICT in PHP6, not
in PHP 5.3.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
not, so its up to
each person to decide if they are in the loop enough to vote), unless
you simply generally mistrust the approach taken to get to this point
or the people involved.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
will not involve myself in
that any further for now.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
stopped exploring his alternative approaches.
so dont hold you breath.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
if you cannot achieve what you need within the existing extension
while maintaining BC, I am afraid imho you will have to bite the
bullet and all the features into the PDO driver.
Thats my opinion at least.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime
compared to some non PHP source
(like a configuration file).
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
be improved (of course there are
some limits in the current architecture).
So for core my opinion holds, that only PDO drivers should be added,
but PECL is of course another story.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
is not very useable, especially until we have traits.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
, it would need to be handled by an optional parameter that
defaults to false.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to an agreement, finish up the
patches by Monday so that we could release alpha3 next Thursday. Since
that is not going to happen we will see alpha3 on the 21st I guess.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http
, which would put us at an early January release of 5.3 in a
worst case situation.
Given that, are we sure we do not want to push out a 5.2.7 release
which contains some general bug fixes sometime in October/November?
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP
) those cases quite diligently.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 29.09.2008, at 17:05, Lukas Kahwe Smith wrote:
Hi,
Christian poked me offlist about the rounding patch. While talking
about that patch with Johannes I began to wonder if we have any
interest in maintaining a page on the wiki (or a README in php-src)
with contact information for each
On 29.09.2008, at 00:21, Gregory Beaver wrote:
Lukas Kahwe Smith wrote:
On 24.09.2008, at 01:17, Guilherme Blanco wrote:
For those that do not understand very well the explanation of
jvlad...
He's suggesting to change the class struct to be an scope struct,
and
have a property
Hi,
Ok before we all go crazy with the NS separator debate, some reading
(which also links to a few interesting posts/sites):
http://marc.info/?l=php-internalsm=113313170231815w=2
http://marc.info/?l=php-internalsm=113345477123705w=2
http://marc.info/?l=php-internalsm=117742643931293w=2
I
on Linux x86 we have all of internals. For windows
and IIS we have the windows team (presumably on all CPU variations?).
FreeBSD is covered by Yahoo. I guess Sun will eventually cover Sparc.
So that leaves other web servers, OS's and CPU's to ..?
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED
a second separator.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 26.09.2008, at 12:04, Michael Wallner wrote:
Lukas Kahwe Smith wrote:
well the question is does it fix some real world bugs? this late in
the
game i would not want to include these changes if they just add
features ..
Huh? :) The question to me is, why did you ask me to do it, when
have something that you think is very low risk,
unquestionably useful, with ready tests and patches, then feel free to
approach me and Johannes. Otherwise just help us to get 5.3.0 out the
door, so that you can add whatever niceties into 5.3.1 :)
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED
On 26.09.2008, at 21:59, Pierre Joye wrote:
On Fri, Sep 26, 2008 at 9:38 PM, Lukas Kahwe Smith
[EMAIL PROTECTED] wrote:
So unless you can take our worries away in terms of BC issues, I
guess we
would prefer to leave this patch out of PHP 5.3.
I strongly disagree, for two reasons:
1
On 26.09.2008, at 22:01, Jani Taskinen wrote:
Lukas Kahwe Smith wrote:
On 26.09.2008, at 12:04, Michael Wallner wrote:
Lukas Kahwe Smith wrote:
well the question is does it fix some real world bugs? this late
in the
game i would not want to include these changes if they just add
features
On 26.09.2008, at 22:06, Hannes Magnusson wrote:
On Fri, Sep 26, 2008 at 21:38, Lukas Kahwe Smith
[EMAIL PROTECTED] wrote:
and I are a bit worried, that this code did not see that much
testing since
it was checked in to HEAD quite a while ago. And seeing that the
backport
in
the game i would not want to include these changes if they just add
features ..
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
reasons).
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
for the sake of them then becoming
namespaceable. but how would allowing functions in namespaces solve
this issue?
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
also discuss removal of constants? Seems logical
as the really the same arguments apply.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
if we schedule this for PHP 6, then we might want
to mark a few things as deprecated in PHP 5.3.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
and adapting
it .. but even then the goal should be to eat as much of our own
dogfood for this .. seems like there is nothing that would be so heavy
(or long running) to make PHP totally unfit for this.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development
Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
in
it?) to the namespace separator discussion. I remember back then a lot
of people were saying lets get the implementation done first and then
worry about the syntax. I guess we are more or less at this point now.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP
might want to hold off until 6.0, considering that the
bug that was fixed did not affect that many users (just a guess).
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
that there
were discussions about if to even drop it, but I think we agreed on
dropping it in the end, so I guess using ereg should throw an
E_DEPRECATED in 5.3?
I am not sure if we should make it optional in 5.3 though.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP
that there
were discussions about if to even drop it, but I think we agreed on
dropping it in the end, so I guess using ereg should throw an
E_DEPRECATED in 5.3?
I am not sure if we should make it optional in 5.3 though.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP
if its doable or not. This is very much
appreciated!
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
only about namespaces conceptually.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 10.09.2008, at 09:13, Lester Caine wrote:
Lukas Kahwe Smith wrote:
Hi,
So let me get this straight, you are complaining that all the new
features and changes in the 5.3.0 alpha releases are not perfectly
documented yet?
PLEASE re-read the original post.
If my comments and QUESTIONS
301 - 400 of 846 matches
Mail list logo
