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 D
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 gene
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/uns
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, vi
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
--
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 usef
So in summary, I feel the key point for this document is:
- a single document that lists all changes
- contains pointers that enables someone to look up more details in the
documentation
- enables people who get new "strange" error messages to find pointers
towards the documentation
- some leng
Then I guess I need to read the archives.
I can't imagine why a system admin would give a damn about new
language features, object model, reference changes, pdo, new error
levels or how to check if a class inherits another class.
They'd need to know that there had been major changes in the langu
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 often
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 alread
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 ne
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
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
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 no
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 fle
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 unsubscribe, visit: http://
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 be
"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 Runti
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
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 quot
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 M
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 an
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 us
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, arraysshoul
e or otherwise) arising from any third party
acting,
or refraining from acting, on any information contained in this e-mail is
excluded. The views expressed may not be official company policy, but
instead, the personal views of the originator. If you have received this
e-mail in error please notify th
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
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 n
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
-
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
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
> unr
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
t
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
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 Li
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 than
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 inst
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 m
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 has
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,
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 wh
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 svn
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
fin
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
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 b
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 aga
Hi lover,
(sorry, couldn't resist)
The correct syntax is:
Note that static class elements are accessed using T_DOUBLE_COLON (::),
and that the namespace separator \ is used to join namespace and element
name.
OK... thanks for the clarification. That does actually make perfect sense to
me,
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
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 tha
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 personal
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 througho
And I must agree with Sebastian: How do you test something that isn't even
implemented yet? :D
You apply the 'rough draft' patch against PHP_5_3 :D
http://pear.php.net/~greg/backslash.sep.patch.txt
As referenced in the original rfc for the backslash approach cited at
http://wiki.php.net/rfc/n
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 rejected
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 Inte
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
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 unsubscribe,
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 roun
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:
http://php.net/~helly/triplecolon.html
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 c
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
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
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
... 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
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 und
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
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.
Wo
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 iss
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 List
T
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 tha
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,
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
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 code
is goin
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 hav
#1 and then #3.
Thanks :)
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 you.
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 ha
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 unsubs
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 vote
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 separat
i guess i should note that Steph's tally only includes votes on Greg's
proposal. Stas proposal is obviously also still up for vote.
Yes, we're going to have to go head-to-head at some stage very soon. Getting
it down from 5 proposals to 2 would make that a bit more possible though.
In that s
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, o
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 name
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
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 su
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 fun
anyways, given the current state most people voted to remove namespaces
from PHP 5.3. i assume that all people that casted these votes were (and
still are) confident that they actually know what they voted on. maybe
some of the people involved in finding the current proposals will try to
do
Hi Josh,
I'd like to point out that those people started working with
namespaces *before* the idea of dropping them (or postponing them to
PHP 6) appeared on the list. I doubt those people would have done the
same if they had been told that namespaces may very well not be
available until PHP 6.
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
actua
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 namespace
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
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 D
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
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
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 start
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 th
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 hap
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.
1 - 100 of 728 matches
Mail list logo
