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 - PHP Runtime
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:
That's a good point we need to make sure that main.c INI values match
those of the production INI file. There are A LOT of installs that
operate without an INI file.
I'd say it's usually ini-dist that matches the main.c value... but the issue
in this case is that ini-recommended (which is
Hi Dan,
Because the guide is in the manual. The manual is the difinitive source
on how to use PHP.
The guide was only added directly into the manual quite recently. This is
exactly what I'm trying to say; its purpose has shifted since it became part
of the manual and it's lost whatever
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.
- Steph
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 unsubscribe,
Hi Lukas, all,
'Scuse top-posting, no history marks here.
It's not actually 'open' so much as 'under way' - the file's in place and
has content, it just needs some thought applying to it.
In the last two upgrading guides, we've repeated much of what is already in
the NEWS file or in the
Hi Hannes,
Think about the online manual. In 2 years from now people should still
be able to read the upgrading guide and it should still make sense
without needing to hunt down random release announcements or outdated
NEWS files.
The upgrade which gets committed to php-src will be taken, word
But this was actually an add-on after I put the initial 5.1 upgrading
guide
together. A 200-line document became a 500-line document overnight, and
voila - nobody reads the thing.
Actually I'm wrong - that was 5.2. The 5.1 upgrade guide appears to be
as-was.
So again, why are we listing
IMHO listing new functions is useful - there could be a name collision
with
a function in users code (I know it is improbable, because the functions
are
named extname_funcname, but still possible)
Improbable indeed. The nearest we ever came to that was with the Date class
(because PEAR
An upgrade is not only about problems, it is also about solutions.
You need a problem before providing a solution. Really.
A
kind of tutorial on how to use all the changes in a given release in
your applications. It often helps to clean codes, remove work 'round,
etc. An upgrade guide is
Having ascertained that Lukas did not shoot himself on seeing this...
This is a testing of the waters RFC. If there is interest, it will be
followed with a patch. It should be noted that the patch for this has
been available through the various vortexes of namespace syntax for over
a year
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 -
Hi Kuba,
For the moment some unexpected behaviour caused by use of undefined
constant may be hard to fix with low error reporting level.
So don't use a low error reporting level.
Moreover,
treating an undefined constant as a string does not make sense. I know
that PHP is intended to be a
Hi Richard,
In looking at http://en.wikipedia.org/wiki/Leap_second, there have
been quite a few leap seconds - 34 since Jan 1st 1972.
I make it 23, according to the info on that page...
So, if PHP isn't making any changes does this mean PHP time is 34
seconds behind UTC?
No.
This would
No: http://derickrethans.nl/php_lags_23_seconds.php
Hm, Wikipedia's apparently less than open there -
[12:36] otherbird so how come PHP's different?
[12:36] Derick olson has information on it, but it's never used
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To
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 Development
Hi Pierre,
A fatal error could be more effective. And the message can make the
reason behind the error very clear.
It's a very big jump from 'enabled by default' to 'fatal error'. It will
break a lot of legacy code with no prior warning.
By the way and for the record here, they (magic
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
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
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 Internals - PHP
Hi Lukas,
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, BC concerns. Can't we just deprecate it in 5.3 and
Hey Greg,
Remember, the patch I'm proposing would only be necessary for people
using un-namespaced code combined with namespaced code (already a bad
idea) *and* scattering use statements throughout the global code.
If it's 'already a bad idea', why support it?
Also, the *only* supported use
Isn't the ability to do that one of the biggest reasons for having
namespaces? To avoid having to fill your class names with junk.
The examples are namespaced appropriately, they tell the developer that
it's
a Helper for Arrays in the MyFramework framework. I shouldn't need to
suffix
the class
This namespaces issues highlights the very fundamental issues with PHP, and
glib, childish responses like yours only serve to score points.
===
The 'very fundamental issue' here is that you're expecting namespaces to
allow things that are not legal in non-namespaced PHP code. The entire
thrust
not be official company policy, but
instead, the personal views of the originator. If you have received this
e-mail in error please notify the sender and delete the e-mail.
-Original Message-
From: Steph Fox [mailto:[EMAIL PROTECTED]
Sent: 06 November 2008 11:01
To: Dan; troels knak
Dan,
PHP may be a hybrid language, but the fact is you're implementing object
oriented functionality, and as such should be implementing it in a way
that
follows de-facto standards in object oriented language design. I should be
able to overload your internal array object, and yes,
Hi Greg, all,
For this reason, the only resolution that we should be considering is:
classes:
1) try ns::class
2) autoload ns::class
3) fail
functions/constants:
1) try ns::function/ns::const
2) try internal function/const
3) fail.
I see this as giving priority to library authors rather
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 Development Mailing
IT will break the code from everybody who doesn'T expect such a flag
exists and the average application user won't know and jsut see errors
which randomly occur.
Erm, how is that going to happen?
This is basically a tighter setting that can *optionally* be used and should
*always* be used in
Hi Stefan,
Dev writes a script, uses autoload, overrides global class.
Distributed to user, that has ns.lookup=On as you propose, user borks his
install, lacks the file containing the class, gets the global class -
obscure error messages because of nonexisting methods in places unrelated
to
Hi Stefan,
Dev writes a script, uses autoload, overrides global class.
Distributed to user, that has ns.lookup=On as you propose, user borks
his
install, lacks the file containing the class, gets the global class -
obscure error messages because of nonexisting methods in places
Hi Greg,
By doing the resolution I've suggested (and Stas, incidentally, was the
first to suggest this):
classes:
1) ns\class
2) autoload ns\class
3) FAILBOAT
functions/constants:
1) ns\func or ns\const
2) internal func\const
3) FAILBOAT
We get the best of #1 and the best of #2, and it makes
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.
- Steph
How you got both files is beyond me - winres.h is not present in either
the 2003 sdk or the 6.1 sdk (used with VC6 and VC9 respectively) - our
current instructions for building involve renaming header files in the
sdk which is a very silly thing.
Nah, it'll be a legacy thing. I've only ever
Hi Lukas,
Here I come to the key part of my idea. We would allow every PHP
usergroup to also appoint one person that gets unmoderated access to the
list.
Great idea!
Lets just create an interface were people can register their UG and manage
the email address for the contact person (and
Hi Franck,
we agreed long ago on a very easy scheme, there shall only be is-a and
public classes.
Do you really think it makes the scheme easier to allow for public
classes
only?
Well, yes, actually.
Class visibility is a common OO concept, that improves the encapsulation
of the code,
But the longer you wait, the more you're likely to run into implementation
problems.
I think what you meant to say was, 'the longer you wait, the more likely you
foresee the implementation problems'.
I don't know how many users you have. I'm not going to pretend I know how
many users PHP
Hi Marius,
Don't know i never saw something so ugly since c++ templates syntax
I find it funny that php is designed by committee and no one listen to
the community
===
You have written to this list a few times before. Here's a brief summary of
your posts:
1) We should be moving to git not
Hi Marius,
yes is true that i like to have strong opinions and yes i could be
wrong in most of them
but when all the comunity screems at the namespace issue
All the community is not screaming at the namespace issue. A minority of
the community is, but most of that minority would scream
Hi Thomas,
Anyway, my point is that there may be other options. Such as putting off a
long-sought feature until it can be implemented properly.
OK, since you obviously didn't do any background reading before posting to
this list, let me direct you to the history behind this decision once
Hi Thomas,
Actually I've been following namespaces for a fair while, but the issue of
:: being a problem wasn't really raised until a few weeks ago. So while
I'm aware of namespaces being under discussion for a fair while, yesterday
was the first I'd heard about a decision being made for the
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
This is not what I meant, but there's obviously neither use nor interest
in further discussing this topic as decision was already taken. I only
wish people would not start rewriting history as other opinions or options
didn't even exist so soon. I'm fine with making the choice, what I'm not
Hi Pierre,
Excuse me but while the idea to have an online meeting was great,
sending a mail to ask to attend an online meeting 24 hours before and
on a Friday was not a wised choice. I would have participated too if
it was during this week or the next weekend.
You were actually online
Hi,
I'm not sure what's the hell is going on with you and Step,
OK, Pierre. You got us. Greg and I have been secret lovers for the last 5
years and we've been planning to take over php.net the whole of that time.
but if we
can't answer to any of your mails without being accused of
Yes, it does not mean that I was able to actually attend the meeting.
Because... oh wait. It wasn't important to you.
OK OK I'm not going to push this publicly. Just pointing out that most of
us
keep irc logs.
Preaching by example.
I didn't want to push this publicly, Pierre. Remember
Hi Rob,
Wouldn't it be:
?php
$x = new Framework\Utils::Foo();
$y = new Project\PEAR::Bar( 'somestring' );
?
Yes, as I understand it.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi lover,
(sorry, couldn't resist)
The correct syntax is:
?php
// initialize class
$a = new Framework\Utils\Foo();
// namespaced function
Framework\Utils\parse($string);
// static method
Project\PEAR\XML::makeEntity('\\');
// namespaced constant
if ($a == Framework\Utils\FOO) echo hi;
//
Hi,
Guys, this is like junior school in here.
Yep.
Let me put some things in perspective:
No, let me. Greg worked his butt off the entire weekend looking for the
flaws in *all* the options available to us, including a couple of new ones
that never even reached the list before he
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
The german keyboard issue isn't really one. {}[] are in the same class
of
characters (alt-Gr + number-row). So, as a programmer, you either have to
live with that anyway because there's no avoiding {}[], or you switch to
the
us layout while programming (which quite a few people do).
Also
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).
- Steph
--
PHP
Hi Lester,
And there are no problems with those on foreign keyboards?
If there are, those foreign keyboards are unable to offer either escaped
chars or MS paths... which seems highly unlikely.
But do I still understand that there is an alternative method that was not
part of this last
That wouldn't be the right thread to discuss the merits of a solution,
anyway. This thread is about the tally, and I'm trying to interpret
it.
I did actually keep tabs on this. Yes the choice of separator played a part
for many. However there were just as many who were happy with it - and the
Josh, please...
What I'm wondering is how many of those many voted for or against a
proposition for the wrong reason. For instance, how many users
understood that 2 is not about the use of triple colon? If someone
disregarded 2 because of the triple colon then it was a mistake, as
the triple
Greg was so kind to give me part of his awesome upcoming Pyrus code. He
actually has it running with both ':::' and '\' as namespace separators.
So I thought I'd help out a tiny tiny bit by giving you all the choice of
having a look at actual working code:
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 List
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, 2008 at
Hi Daniel,
There are about six total concurrent threads on this right now.
Would it make sense to create an OFFICIAL voting thread and *only*
count new votes posted to that thread from now until the fifty-vote
mark? Otherwise it seems that it introduces more confusion into an
already loaded
Seems everyone is going for #3 ... I'm with the crowd. +1 on #3.
OK, this isn't a good reason. Please try to treat this poll with some
seriousness.
The voting patterns became skewed from here on, so the poll's still 5 votes
away from completion because I can't sanely use wildcard votes.
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
Hi Stas,
So far, my proposals hardly got any hearing at all, fair or otherwise -
they were totally ignored on the vote - never even mentioned except for
the note in Greg's wiki (which, despite being incorrect, was never fixed
or changed), and it looks like at least some of the persons were
... 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 at sanity with namespaces
From the peanut
OK, this is what we have. Please don't send any more votes on this now :)
NameIssue AIssue B
==
Greg#2 (alt #3, #1)Yes
Guilherme #3 Yes
Kalle
I'm just a mere user, but if we go for other namespace separator (be it
::: or : or anything else), then I'd rather see it used both between
namespace and class/function/constant name *and* between namespace parts.
OK, so maybe I should explain one little thing about the significance of
those
Hannes, Lester...
Can we please start small and then incrementally add more features?
Lets start with classes only in namespaces in 5.3.
The problem with that statement is that if it is used to ignore the other
problems, then at some point it may be necessary to re-write all the new
namespace
Please can those people who didn't already express a clear and relevant
opinion, express it now? We don't have long to play with this if there's to
be namespace support in 5.3.
At present it looks like a two-horse race between #1 full disambiguation
(:::) and #3 explicit disambiguation ('use
Hi Stas,
I think it would be better if we had limited number of variants. We have
many people here with all kinds of opinions, but the thing is we need to
choose ONE way and no more. So I'd propose to cut some options, otherwise
I suspect some people would be discouraged by too many options,
after much more thought I think you're option #2 is actually best however
the choice of ::: separator in the example really confuses things and
makes at an instant turn off..
This concept was originally presented using the .. separator, and has been
presented with others since. The separator
I was hoping to have at least 30 respondees at this stage, but actually have
29 (and that includes Hannes' abstention). However, to keep y'all up to
date, here's where we're up to with Greg's proposals.
Option #3 is in the lead, but that lead is still pretty fragile; there are
only 3 full
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
Hey Stas,
It's basically the same that my proposal does, only you have to work twice
as hard (two use's) and remember which name you assigned to what - and you
still would have to rewrite the code to use another:: - so you have to
both add use's _and_ rewrite the actual call code. And you'd
Heya Scott,
I'd much rather see ::: used and don't care too much about those with
code already written, we never guarantee BC on unreleased versions.
Well, that narrows it down to #1 or #2.
Though I don't object to #3 at all either, so indifferent!
OK, so we have #1, #2 or #3 now from
#1 and then #3.
Thanks :)
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Stas,
If you have two distinct sets of code, why you use same namespace for both
of them? Namespaces are specifically designed so you could have different
sets of code in different places.
I was unclear there, sorry. I was thinking of the situation where 'I use a
class that happens to
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 code
is
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
Useful lib would have its own namespace and you would have your own.
The assumption to date has been that most userspace code wouldn't use
namespaces. Libraries and plugins would be more likely to use them. Ie the
chance of a ns/class collision isn't likely to be so much under the control
of
Hi Michael,
Forwarding to internals@ and counting you in.
I tried to mail the list, but it never seemed to go through.
I'm just a user, but a serious one, with frameworks to maintain.
I've already done a branch of an app framework to the current
namespaces implementation comfortably.
FWIW,
just wondering if there are any cut of dates for the tally dates / rounds
etc?
When this tally started out, I'd been told that there had to be a
cut-and-dried answer by tonight or forget it. Then it was pointed out to me
that Stas' proposal wasn't getting a fair hearing. Then it turned out
Hi Elizabeth,
This can be solved in three ways.
1. Greg's leaf solution
foo::bar-baz(); - namespace foo::bar, function baz
foo-bar::baz(); - namespace foo, static method bar::baz
Personally I don't like this, get confusing even if we pick some weird
operator like :
2. Don't allow
Hi,
http://wiki.php.net/rfc/namespaceissues
Read it and discuss. Let's be clear people: the technical problems in
namespaces are limited and solvable. The problems in the political
environment surrounding them may not be. Wouldn't politics be a
stupid-ass reason to remove namespaces?
It
Hi Lukas,
Just for the record, I was suggesting to add the E_STRICT in PHP6, not in
PHP 5.3.
I'd missed that, but it doesn't make a whole lot of difference IMHO. The
reuse of an existing symbol is going to bring problems, and if we do it now
we'll be blocking the possibility of a better
Major changes like ripping the feature that most people are looking
forward to
in 5.3 out?
'Most people'? I would've expected 'most people' to be writing code that
will run under 5.1 for at least the next couple of years! Experience tells
me that takeup of new language elements is slow, and
Many people have starting working on top level application using
namespaces, so there will a very bad buzz over the php community if
namespaces are ripped out...
People working with a development branch take their own chances. We keep BC
for released code, not for dev code.
- Steph
--
Hi Vesselin,
I see the point and objections against quick and dirty, but on the other
hand the discussion about the namespaces started long time ago - two years
already?
Longer than that - they were thrown out in 5.0 too.
If for two years there wasn't an agreement how they have to be
Hi Stas,
The thing is that there's nothing here that would improve with time.
Except the chance to test approaches that are currently only theories.
Pushing in to 6.0 is basically throwing it out forever, since there's
nothing we could do in 6.0 that we can't do now, there's nothing that we
Hi Tony,
I don't think Stas is implying not to test it.
Which proposal do you think he's implying not to test? And which of the
other three proposals on offer do you think should go out there, bearing in
mind that once the thing's released it can't be changed?
- Steph
--
PHP Internals -
Hi,
Nobody talks about without testing, we are in alpha. But I'm talking
about working on it, not pushing it under the carpet and hoping it somehow
gets better there. I am working on it, so do other people, but chanting
let's remove it is not working. If anything is negative, this is.
We
Stas,
We are in alpha indeed, and still looking at proposals, and still without
consensus. The last thing I'd want is to see namespace support pushed
under the carpet, but I'd rather see it at this stage of development as
part of the PHP 6 development cycle (as originally
Why? What would
I can name two:
1. Most (not all, I know, but most) of the use cases for namespaces are in
the OO realm, and most of the problems they are to serve come from that
realm too. So at least initially most of the active users, which wait for
it impatiently, are OO users, and classes are the thing
What would happen if we give the namespace implementation a chance to
mature is that it can be delivered as a fully-fledged language element
rather than a partially-fledged and potentially flawed one.
What do you mean by chance to mature? Only chance for it to mature is
people actually
Hi Lukas,
We have 4 options. We know how things are without namespaces, we know how
things are with the current implementation. This essentially leaves 2
choices that are untested for now.
True, true.
Both of these approaches have some uncleanness to them. If functions and
constants get
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
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 - PHP Runtime
Namespaces are for big projects. Staring big project using namespaces when
it's not even clear they'll be in 5.3 is an insane risk, nobody would do
it.
Only 8 hours ago, one Jean-Phillipe Serafin wrote: Many people have
starting working on top level application using namespaces, so there will
Hi Andi,
I don't think postponing this to another big release is going to do anyone
any good. You will not see magical revelations because it's postponed by
another year.
No, but we might see a broader agreement, and that would give more of a
basis for user confidence in moving to
Stas...
And people believed us and took the risk.
Which you just said they wouldn't do.
And now you propose to teach them the lesson that trusting PHP core
developers that they actually deliver is a bad idea.
It seems a sounder policy than teaching them they can't trust that what is
1 - 100 of 692 matches
Mail list logo
