Felipe Pena wrote:
Hello,
just to inform, I've commited (yesterday) the patch removing the
UG(unicode) checks, etc across all source (except mysql exts). As the
patch has 492K, looks as no mail will be sent.
I'd given up hope of ever seeing that reach CVS :)
Thanks Felipe!
- Step
Hi Lukas, all,
Well the last thread on the topic ("5.3 todos") stopped with Steph
explaining that there are 2 different documents, one the UPGRADING guide
in php-src and one being the manual and that she intends to focus the
UPGRADING guide to be short and to the point for sysadmi
Hannes Magnusson wrote:
And now to the list too *sigh*, sorry Steph :)
I did wonder :)
On Wed, Mar 25, 2009 at 13:49, Steph wrote:
Hannes Magnusson wrote:
2009/1/28 Steph Fox :
sfoxWed Jan 28 17:23:28 2009 UTC
Modified files: (Branch: PHP_5_3)
/php-src
Hannes Magnusson wrote:
2009/1/28 Steph Fox :
sfoxWed Jan 28 17:23:28 2009 UTC
Modified files: (Branch: PHP_5_3)
/php-srcUPGRADING
Log:
- Skeleton version taken directly from the scratchpad and tidied.
@Lukas, Johannes: This is nowhere near complete, and may
Hi Kalle,
and in 124 tests fails for in HEAD, instead of writing an insanely
long list here, I have zipped both the test log and diffs for 5.3 and
HEAD which can be downloaded here:
Yeah, that's normal - most of Phar doesn't work yet in HEAD.
Thanks!
- Steph
--
PHP Internals - P
ended (which is generally taken as
'ini-production' by the community at large) throws warnings that are not
thrown by default, which seems pretty weird to me.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
allow_call_time_pass_reference = Off (Issue Warnings)
Eric Lee Stewart
+1
Switching it off by default in ini-dist and main.c would be good too!
http://wiki.php.net/rfc/calltimebyref
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
It doesn't matter that the XML file is long. Each section is broken up
into a separate page in the manual.
I'm talking about the UPGRADE file in the source, which is plain text.
Have you ever tried to read it?
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To u
BUT perhaps some of the more complex explanations should have their own
document. If it 'requires more explanation than we want to provide in
the documentation' that does seem to suggest that a development perhaps
DOES need better doumentation?
In the manual, really. But - quite
t whatever usefulness it had in the src as a
result.
Sure, the guide be better structured. But it should contain everything.
It's nothing to do with structure. "Everything" makes for a very long file,
full stop.
- Steph
--
PHP Internals - PHP Runtime Development Mailing L
ame of the file.
See, I _knew_ we were looking at completely different things..!
How's about a short, sane version in the src and an extended
bells-and-whistles version for the manual? With a link provided in the src
version to the extended version.
- Steph
--
PHP Internals - PHP Runtime
a bit excessive, but we do
at the very very very least need to link to the page that lists them
then.
That's not a problem. Lead me to your docs :)
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ting both, I just want to be
very clear about their purpose.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
er can possibly impact existing code;
ergo, it has no place in an upgrade guide.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
sting new extensions, functions and class constants?
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
uplicating the release notes seems a bit pointless.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
features in PHP syntax (exception: reserved keywords). We should focus on
things that are deprecating, missing or else behave differently in some way
IMHO.
Comments welcome,
- Steph
- Original Message -
From: "Lukas Kahwe Smith"
To: "PHP Internals List"
Sent: We
ver
a year now, and it is an extremely simple patch.
[RFC]
Implement importing of functions to complement importing of classes and
namespaces.
Sounds like a darn good idea to me.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Lukas,
I am also waiting on some word on the upgrading guide, Steph???
Yes, I'm on it.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
One of the big items on the todo list is turning the scratch pad into
an actual upgrading guide. Would be great if someone could take the
lead on this (and others helping out too of course).
I promised this a loong time ago, no problem with it now either.
- Steph
--
PHP Internals
be a flexible language, but for me it's a bit
thick.
Just how is PHP supposed to know that some random string is intended to be
anything else?
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
No: http://derickrethans.nl/php_lags_23_seconds.php
Hm, Wikipedia's apparently less than open there -
[12:36] so how come PHP's different?
[12:36] olson has information on it, but it's never used
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscri
would be a red herring anyway Richard, the Olson tz database used by
PHP is used by several other projects too - including the GNU C library.
http://en.wikipedia.org/wiki/Zoneinfo
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
"If not now, when?"
Later?
Would you mind reading the thread first please? :)
The subject's a tad misleading at this stage.
- Steph
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP
6.0 iirc its already off by default in that branch.
Ilia, it doesn't *exist* in that branch!
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
As much as I hate the feature, I am not certain that is a good idea in
a minor release.
"If not now, when?"
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
record here, they (magic quotes, register
global and safe mode) are already removed in php6.
All the more reason to disable them all by default and have them throw
E_DEPRECATED in 5.3.
- Steph
Cheers,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime De
Hi Scott,
Agreed, going from on by default to removed just feels odd.
I'd disable it by default in 5.3 and lets start throwing a strict
error if the configuration enables it.
Why do we have E_DEPRECATED if we're not going to use it?
- Steph
--
PHP Internals - PHP Runtime D
ke to see it in 5.3 because it was supposed to fix
several OB issues, but it's probably too late in the cycle now
8) 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
0 (not enough insight to vote on this)
Thanks,
-
?
Also, the *only* supported use case behind allowing multiple namespaces
per file is to allow people to mash pre-existing separate PHP files
together, and have them still compile. Requiring brackets is designed
to make it more readable, and the "use" restriction furthers that goal.
to support the basics in a way that
make sense.
Great, so drop PHP and go use Javascript. Oh wait - you can't. Because *it
wasn't designed do the same job*.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
you're telling
us 'cough' should rhyme with 'cow' because that's how Esperanto would have
it. But English is so much easier to learn, if more difficult to master,
that it's become the lingua franca for the 'net.
- Steph
Dan
On Thu, Nov 6,
entire
thrust of the internals discussion preceding this has been that preserving
similar resolution rules in namespaced PHP code to those that already exist,
will avoid potential confusion.
And don't tell me to 'grow up' or I'll set my grandchildren on you ;)
- Ste
s that there would be no thread... oo-er...
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
As you 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?
Yes - you're missing the possibility of overriding, AKA naming collisions
between internal and userspace funcs/consts.
-
makes coding easier in
the long run.
Stefan just convinced me of this in a *much* shorter post :)
+1
- Steph
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubs
prefix
> every
> single occurence, you just have to say at the top of the file "When I
> say
> Exception, I mean \Exception".
The point is that your dev would have done exactly that, so whether your
user has the setting on or off is immaterial.
- Steph
No, the dev
Exception, I mean \Exception".
The point is that your dev would have done exactly that, so whether your
user has the setting on or off is immaterial.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
those least
likely to be loading lots of third-party OO code in the first place.
No ini settings for basic behavior.
Ah well we might as well throw out E_STRICT too!
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
What am I missing?
That INI is the worst we could do. Because it prevents from writing
portable code.
This particular INI doesn't prevent anyone writing portable code. It simply
gives the option of a 'tighter' development mode.
- Steph
--
PHP Internals - PHP Runtime Deve
im through prefix hell.
What am I missing?
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
only ever installed one compiler :)
I bet it was overwritten with the final upgrade.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
developers are key.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
know how
many users PHP has either. I do know though that if we get it badly wrong,
it will cause a lot of people a lot of problems
It doesn't matter what other languages do, because other languages don't
have it 100% right either. If any of them did, why would there be more than
esting in
2002. This was originally scheduled for full release in PHP 5.0. (PHP is
not, by the way, 'an OO language' in the sense you use the term.) It
certainly wasn't withdrawn for the reasons you suggest.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
inority would scream whatever we did.
an semisolution would be an php.ini variable
like
NAMSPACE_SEPARATOR="::"
:-)
Now go away and think really hard about what you wrote there, and you'll
maybe understand that smiley.
- Steph
--
PHP Internals - PHP Runtime Development
am continues even if is an bad decision (they call it
technical one) if you see it from the point of view of syntax elegance
it's not so pretty even c++ looks better .
===
I'm not even going to comment on that.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
or that there
weren't several proposals of ways to get around the known problems.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
These aren't the only ways.
OK.
4) Claim that there is no real problem in addressing ambiguous situations.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
him. We couldn't have known his criteria
and symbol set were correct without that history either; we'd have been
stuck on 'why not :' forever.
Hope it all works out, either way.
As do we all :)
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ea of namespace support because whatever is done
will appear 'wrong' to /. readers
Every other option leads to ambiguity in namespace syntax. That's not
because we need more time to think things over so it can be 'implemented
properly', it's just straight fact.
o
me, I just read :: as a method call in Robert's example rather than as a new
class.
Guess I should sleep before typing 'as I understand it' again :)
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Rob,
Wouldn't it be:
Yes, as I understand it.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ierre. Remember that.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
out being accused of personal
attacks, then it is going to be painful.
You made a personal attack in a very public space. There have been a _lot_
of technical discussions off-list, including most of the recent
Windows-related changes, but you pick on Greg and myself particularly - why,
pray?
- Steph
code).
Apart from PEAR?
I'd to say that I do not care about which
symbol is used.
@Greg and Steph: Private discussions are bad. Or are you trying to say
that this list can't be used as a discussion platform (even heated)?
If we like to have a developer only list, let do it, but keep thi
iki.php.net/rfc/namespaceseparator.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
in
discussing it to death on-list at this stage.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I wasn't planning to open the ns separator discussion again. In fact I think
we'd all much rather avoid it completely...
As info, in a Spanish keyboard it's the same, Alt Gr+{the key to the left
of the 1}.
... but thanks for that part of your input (and same to Ólafur).
-
quite a few people do).
Also useful to know :)
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Well, on German keyboards, it's accessible but only by using ALTGR+?,
which is not really a comfortable combination.
Useful to know, thanks Philipp.
Any more localized keyboard issues we should know about? Anyone?
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubs
Both Stas' proposal and Greg's option #3 are flawed in that way (either to
humans or to the Engine), so the search is on to find a solution that isn't
ambivalent to either - always assuming it's possible.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
espace separator at all. As far as
I'm aware, this is still under investigation (and this time it's for real).
- Steph
marcus
shift+;(x3) vs \
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runti
was interesting that way. It implies that any sensible solution
would be accepted by the majority.
With that said, I'd enjoy having less noise on the list as much as
anyone else.
Amen to that.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
again.
I strongly suggest we all drop it and let them debate amongst themselves in
peace for a while ;)
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t; it accepts that
there will be ambiguity, and then tries to deal with it.
This is also the approach Stas' proposals take.
No more namespace separator arguments, ever. It was worth it :)
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Yes
Janusz Lewandowski* #4 (alt #3) Yes
Steph #3 (alt #2)Abstained
Josh Davies #2 (DS)Yes
Lester* #3 Yes
Alexey #3 Yes
Marc Boeren #
... and this poll is now closed. Thanks Aaron!
- Steph
- Original Message -
From: "Aaron Wormus" <[EMAIL PROTECTED]>
Newsgroups: php.internals
To: "Greg Beaver" <[EMAIL PROTECTED]>
Sent: Friday, October 17, 2008 6:12 PM
Subject: Re: my last attempt a
oader picture of the elements that PHP users would or
would not like to see.
- Steph (4 votes to go)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
My vote is option 1 please.
"use ::: as separator between namespace name and element"
That's #2 :)
Please clarify. Also - please (briefly) explain why.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
y use wildcard votes.
Would anyone still planning to vote please include a *brief* explanation of
why they're making the choices they're making?
Thanks,
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ose anyway, so just
bear with me a little longer :)
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Another one who can't get through...
- Original Message -
From: "Ken Guest" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 17, 2008 3:37 PM
Subject: Fwd: namespaceissues
-- Forwarded message --
From: Ken Guest <[EMAIL PROTECTED]>
Date: Fri, Oct 17,
Hi Lukas,
We are not ready yet. So for now I will not force a decision just yet.
Hopefully next week ...
I'm going to stop this tally at 50 responses. That should be enough to show
us where people generally are coming from.
- Steph
--
PHP Internals - PHP Runtime Development Mailing
and Dmitry come together to
work on polishing it without further ado.
But #1 might still win, and if that happens we'd need to put it to the vote
against Stas' original proposal because they're very different concepts.
So basically - I'm winging it.
Hope that suffices
Proposed solution fine by me.
Preference #3 - pick one of them, any of them, they're all
improvements over the current state.
Many thanks to all the internals folks for working on this one.
Michael Fischer
[EMAIL PROTECTED]
- Steph
--
Democracy is not average people selecting average leaders.
I
ontrol
of the application developer as your example posits.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
that is so wrong, you know 3 was better - you're not in my club :'(
Sorry to disappoint, but I'm collecting votes here, not making them up as I
go along.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Why would you do that? I.e. suppose there's library having namespace
Zend::Controller::Action::Plugin - why would your name your class
Zend::Controller::Action::Plugin and not
Steph::Controller::Action::Plugin?
Why do you assume all third-party software is going to be ZF? Or that cod
to shut up the warnings. I don't think it is
a good idea. Feature that you do not need, can not disable and have to
work around is called "bug".
Can we double-check this?
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
#1 and then #3.
Thanks :)
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
between the two (and everybody else) now.
Greg and Stas actually want the same thing here, they just misunderstood one
another. (@Greg, @Stas: correct me if I'm wrong.)
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Greg, you have questions outstanding on-list (mostly from Stas). Please
respond to them?
nb Stas - I asked the same question about warnings, Greg updated his
proposal since then to answer it.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Greg...
Hi Chris,
This is actually option #3 on the list of solutions at
http://wiki.php.net/rfc/namespaceissues
I know.
Steph: can you catalog this as a vote for it?
Not without Chris even looking at the options.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To
r lead, we could get it down to two
proposals (Stas' versus Greg's) rather than three in the final round.
- Steph
NameIssue AIssue B
==
Greg#2 (alt #3, #1)Yes
Guilherme
ns resolution in
PHP, sadly. If people on this list aren't able to fully grasp the concept,
it doesn't have a hope in user space.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
e to that accusation into the
wiki?
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
that simplicity is a
major element here.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
#4 (D/S) N/A
Liz #1 or #3 Yes
Andrei- 'agreed with Gregs approach' N/A
Janusz Lewandowski #4 Yes
Steph #3 (alt #2)Abstained
Josh Davies - '#1 and #2 are functionally the s
idea, you'd know that it removes that
problem entirely.
Please go and look at his proposals at
http://wiki.php.net/rfc/namespaceissues, and then vote?
Thanks,
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to internal classes"
I'll abstain on this one because I don't feel qualified to weigh the issues
(ie I neither use nor write third-party dev tools).
Thanks Greg!
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
amp;w=2, and read all the
way to the end. Taking ns elements and scope as different principles means
we never get the 'dots before the eyes' issue that caused ::: to be turned
down in the first place.
Derick won't like ::baz() though.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
should wait and see what Greg et al come up with. If they're
close to a solution they believe will be acceptable to all, we're voting too
soon.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
s.
And of course those same people don't mind a bit if the implementation has
changed 8 times in the last 6 months, because they understand that they're
testing a moving target. No?
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
at what is
actually delivered will be robust!
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to be less
than optimal.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
paces, so there will a
very bad buzz over the php community if namespaces are ripped out..." and
there were further objections on the grounds that namespace support has been
'announced' on php.net.
I agree with you that it's an insane risk, but that doesn't mean nobody
Broad-scale testing with the ability to alter the implementation should
problems become apparent.
What you are talking about? Who'll be doing this broad-scale testing,
when?
Users. And I think Lukas' approach is good - use alpha as a testing ground.
- Steph
--
PHP Internals - P
If you can name something that could further our progress here and that
can be done after 5.3 but can't be done right now - name it.
Broad-scale testing with the ability to alter the implementation should
problems become apparent.
Otherwise I see absolutely no reason in postponing the decisi
rstandably want
to see their work 'out there', whereas I'm far from alone in thinking it's
just not ready to be 'out there' at this stage.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
1 - 100 of 879 matches
Mail list logo
