Ilia Alshanetsky wrote:
Its been about a week since RFS for features to go into 5.3 has gone out
and while there was not a flood of ideas there is a substantial list
of key changes people would like to go into this release. I've compiled
a list of all of the suggestions I've received, they are
BuildSmart wrote:
Is there going to be a pear installation that works with PHP6 in the
near future?
Hi,
Wrong mailing list. You want [EMAIL PROTECTED]
To answer your question,
http://svn.pear.php.net/wsvn/PEARSVN/Pyrus/trunk/?rev=0sc=0 is the most
current work on this front.
Greg
--
PHP
Jochem Maas wrote:
Dmitry Stogov wrote:
This is an implementation of Stas idea.
1) Look for existent class in current namespace
2) Look for existent internal class
3) Try to autoload class from current namespace
both ways have a wtf factor in that class with names
matching 'internal'
Stanislav Malyshev wrote:
?php
namespace Foo;
throw new Exception;
In this case PHP first looks for Foo::Exception and only then for
internal
Exception, but the first lookup may call __autoload (or corresponding SPL
functions) and it can emit error or throw exception.
The patch provides
Stanislav Malyshev wrote:
define(__NAMESPACE__.'::FOOBAR', $value) will work out of the box.
Yep, works, but looks not so nice either. I have an idea: add an
operator which prepends __NAMESPACE__.'::'. I.e. say we name if
ns_fullname (I know, this name sucks, get me better one :), so you'd
Stanislav Malyshev wrote:
1) adds unset import syntax for declaring a namespace to have local
import scope (it does NOT affect variable scope or the global
class/function table)
I don't like it. What's unset import? Seems to be very artificial
concept.
be as intuitive as possible. Having
Stanislav Malyshev wrote:
namespace __::__main;
function thing() {}
one::thing();
?
__::__ look like some weird ASCII art, maybe we need something better
for it.
:)
it could be anything, really, I just figured there's no chance that
would conflict with any other namespace. I suppose in
Larry Garfield wrote:
Greg: You say that the old java-package-style definition still works, in
addition to braces. I presume then that the following are equivalent:
?php
namespace foo;
class Bar {
...
}
?
?php
namespace foo {
class Bar {
...
}
}
?
What happens
Stanislav Malyshev wrote:
What happens if you mix them?
?php namespace baz;
namespace foo {
class Bar {
...
}
}
?
That's not the fun yet. This is:
?php
namespace baz;
namespace foo { ...whatever... }
class bar {}
?
If by fun you mean Fatal error: Namespace cannot
Dmitry Stogov wrote:
How about import statements?
The had effect on current file. How they will behave with your patch?
The import in one namespace will affect following namespaces... :)
That's correct, import remains a per-file operation, and I pray to god
that no one suggests making it
Rasmus Lerdorf wrote:
Well, outside of an opcode cache, you wouldn't care whether the logic is
in the compiler or the executor. But once you introduce an opcode
cache, anything that you can resolve at compile-time means one less
thing to do at execute time which means that the feature
David Zülke wrote:
I think there should be just one way to designate a namespace, not two
different ones with different behaviors.
Hi David,
First, the behaviors are not different, just the syntax. Of course you
can have more than one namespace per file with brackets, but the stuff
within
Stanislav Malyshev wrote:
that if you try to combine two files that contain import statements,
it will be necessary to expand the imports. Fortunately, since
What do you mean by expand?
import allows aliasing specific namespaced files and classes within a
file. For example:
But import
Stanislav Malyshev wrote:
file1.php:
?php
namespace foo;
class bar {}
?
file2.php:
?php
namespace gronk;
import foo::bar;
class bar {}
?
The problem is not this code. The problem is this code:
file1.php
?php
namespace foo;
import otherfoo::bar;
?
file2.php:
?php
namespace
Hi again,
The attached patch:
1) adds unset import syntax for declaring a namespace to have local
import scope (it does NOT affect variable scope or the global
class/function table)
2) removes namespace Name; syntax (this I am happy to add this back in
if there is uproar)
3) fixes all
Hi all,
This patch is also available at
http://pear.php.net/~greg/namespace.patch.txt
The patch adds the syntax namespace { *stuff } and allows multiple
namespaces per file with no performance penalty or added complexity as
only 4 lines of code need to be changed, and 9 lines of code added to
Rasmus Lerdorf wrote:
Sheez, guys, slow down a tad. Just because he says no performance
penalty in the description, doesn't make it true. Unless I missed
something in the patch, I don't see how I would resolve the symbols at
compile-time now which means it has been moved to the executor and
Rasmus Lerdorf wrote:
Right, which breaks the single-namespace per file rule. Opcode caches
work on a per-file basis, so I know for a single op_array that I will
never have to worry about a secondary namespace lookup because I know up
front which namespace I am in. By allowing multiple
Hi Ilia and list,
Just to let you know, I just uploaded fixed versions of
install-pear-nozlib.phar and go-pear.phar (finally) for use with the
installation tarballs of PHP 5.2.4. I have tested them on linux 64 bit,
linux 32 bit, and windows 32 bit.
I would appreciate someone with mac OS X and
Ralph Schindler wrote:
Hey David Lucas,
I brought this up a year ago on the list here:
http://marc.info/?t=11472819373r=1w=2
Essentially, the trend will continue to be that as keyword requiring
features are added, the global naming space will continue to become
smaller and less
Antony Dovgal wrote:
Ilia? Greg?
Any comments?
On 14.08.2007 15:42, Antony Dovgal wrote:
This patch breaks PEAR phar install on 64bit.
From what I can see in the source code, it compares data in the phar
with
the result of sprintf(%u..), which is different on 32bit and 64bit
because
Hi,
All of the debate over whether this is a true namespace implementation
is in my opinion completely bogus (translate: I think namespace is a
fine choice for the reserved word, and package is a dangerously
misleading choice), but since there is so much noisy dissent, I have an
alternative
Jordan Wambaugh wrote:
I've just recently begun writing PHP extensions for the first time. Sara
Golemon's article on extension development has been a priceless resource for
me, but I haven't been able to find any documentation on how to define a
class, give it methods and properties etc
Hi all,
I'm a bit concerned by the headlong rush to refactor phpbugsweb to
include PEAR and PECL bugs. The concept is fine by me, but starting
with phpbugsweb as the starting point is a big mistake if you plan to
include PEAR bugs. The PEAR bug tracker has several killer features
that you will
Steph Fox wrote:
Hey Greg,
I'm a bit concerned by the headlong rush to refactor phpbugsweb to
include PEAR and PECL bugs.
DON'T PANIC! There's not really a headlong rush to combine them all,
it's just Marcus brainstorming and me agreeing for the sake of the
PECL devs (especially but not
Arnold Daniels wrote:
Hi,
I agree that $this::$var isn't really logical, since $this is an object
and not a class name. But I do not see why $class::$var shouldn't work,
or $class::$method() for that method. You can also do $function().
Also I want to suggest that brackets can be used
Stanislav Malyshev wrote:
I think it is a good reason. There are plenty of tool-like PHP
applications. Not having to install these, but just be able to
I know one - PEAR. And it's kinds special because it's library
installer. What others are there?
phpdocumentor, phpunit, phpcodesniffer,
Pierre wrote:
I'm in general in favour of phar but I don't think we should start 5.3
for it. I don't think either that it is stable enough to be bundled. I
doubt it is possible to have a stable package in only three public
releases (even the first public release was already marked stable).
Stanislav Malyshev wrote:
include to work on those. Making a hack in PHP to allow phar://
streams to work is a bad idea, a C-extension can easily work here.
So from now on, every time we would want to user stream we'd have to do
C extension and all user stream functionality in PHP is just
Lester Caine wrote:
As for phar? It sounds a little like PDO. No one has time to work on the
Firebird PDO driver because we still need the main driver to provide the
functions PDO does not support. Proper discussion and development of
elements that are planned to become main stream would be
Antony Dovgal wrote:
On 05/07/2007 04:18 PM, Lukas Kahwe Smith wrote:
Marcus Boerger wrote:
Well alot of people make use of our PEAR project. It comes with a
bunch of
nice sub projects. And even some external (as in non PHP)
applications and
projects make use of it. Providing a better
Lester Caine wrote:
Gregory Beaver wrote:
Phar is not yet perfect, but is also not NEARLY as complex as PDO.
There is no comparison.
The 'comparison' was in the way these packages get added without proper
investigation ;) Someone decides that THIS is how it will be done, and
that is what
Hi,
There has been a bit of inevitable FUD with phar. Although the manual
(http://php.net/phar) describes a fair amount of how phar works, the
design decisions are not documented.
Originally, the phar stream wrapper was a userspace thing. Davey Shafik
designed it to take advantage of a neat
Stefan Priebsch wrote:
Stanislav Malyshev schrieb:
All power to them, but why should they use phar as runtime format?
Maybe we could agree on using phar as a means of deploying PHP code, as
I pointed out earlier? Otherwise it seems, as Greg has pointed out, that
PEAR as it is will become
Stefan Priebsch wrote:
Gregory Beaver schrieb:
Correction: the *installation* process for PEAR will have to be reverted
to the way it worked in PHP 4. PEAR is unaffected by these changes.
Which, from the end user's viewpoint, makes PEAR useless because they
cannot install PEAR
Gregory Beaver wrote:
[snip]
megabytes of information just to locate a file. The zip file format has
the same limitation - the entire archive needs to be scanned.
Both of these formats were not designed for random access in the way a
traditional filesystem is designed. In fact, I could
Ilia Alshanetsky wrote:
5.2.2 release cycle is about to begin, with a first RC planned for this
Thursday.
If you have any major patches left over, please commit them as they will
no longer be accepted for 5.2.2.
Reminder:
http://pear.php.net/~greg/halt fixes the buggy limitation on 1
(mat) Tias Guns wrote:
I would like to help develop pear/PEAR_Frontend_Web, cellog asked me to apply
confirmed,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
Don't forget, please review http://pear.php.net/~greg/halt for inclusion
to fix the implementation of __HALT_COMPILER().
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Peter Hodge wrote:
You should just need to:
- add T_SINGLETON to the parser.
- add an is_singleton flag for class definitions, activated by T_SINGLETON.
- overload the 'new' operator to retrieve from the hash table if the class is
a
singleton (otherwise call __construct() as normal).
-
Hi all,
While porting improvements of run-tests.php into the pear run-tests
command, I noticed that there are no tests for the php://input stream in
PHP_5_2 (didn't look at HEAD yet), so I thought I would offer one if it
is useful.
At the same time, I found a flaw in the implementation of
Hi,
http://pear.php.net/~greg/halt/
contains the patch (unchanged and still against PHP_5_2) and 4 .phpt
tests that prove it works.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
The last patch version still allowed:
?php
define('__COMPILER_HALT_OFFSET__', 1);
?
which would break any __HALT_COMPILER();
Interestingly enough, the current implementation makes this script a
fatal error:
?php
define('__COMPILER_HALT_OFFSET__', 1);
__HALT_COMPILER();
?
But not at the
Hi,
With the first release of pecl/phar, I have started thinking about the
implementation of __HALT_COMPILER();
Currently, this code results in a fatal error:
file1.php:
?php
__HALT_COMPILER();
?
file2.php:
?php
__HALT_COMPILER();
?
file3.php:
?php
include 'file1.php';
include 'file2.php'; //
Gregory Beaver wrote:
__COMPILER_HALT_OFFSET__. This does change behavior in that
__COMPILER_HALT_OFFSET__ can only be used within the same file that it
is defined. However, this is extremely unlikely to break any existing
scripts since it was designed for self-contained installers
Andi Gutmans wrote:
Hi,
I thought I may have brought this up a long time ago but couldn't find
anything in the archives.
For a long time already I've been thinking about possibly adding a new syntax
for array(...) which would be shorter. I'd suggest
[...]. While I am usually not in favor
Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2007-01-21 18:25:24 -0500:
Personally I think PHP related projects should avoid using PHP in
their name period as it causes far too many problems for the language
itself, since most people fail to distinguish between PHP the
language and project
Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2007-01-23 08:59:46 -0600:
Roman Neuhauser wrote:
php.net distributes programs that violate the PHP license: e. g. PHPUnit
or PHPDocumentor (see http://pecl.php.net). If php.net is ok with
ignoring the license terms (and has been for
William A. Rowe, Jr. wrote:
Stefan Esser wrote:
It should be noted, that the PHP Group is not allowed to give anyone the
right to use PHP in it's product name.
It's called a Trademark. It may or may not be a Registered Mark, but both
concepts exist carrying varying weight in any
Stanislav Malyshev wrote:
In my opinion, it would be a pity to lose the design benefits of stream
wrappers in the effort to gain more security when security can be gained
without losing the benefits. I think it would be good to allow
disabling all urls as Stefan suggested, but if there is a
Brett Bieber wrote:
PEAR package... http://pear.php.net/pepr/pepr-proposal-show.php?id=461
verified, this is to maintain the newly accepted
Services_W3C_HTMLValidator. Brett should be given karma for
pear/Services_W3C_HTMLValidator
Thanks,
Greg
--
PHP Internals - PHP Runtime Development
Hi Ilia and everyone,
E_DEPRECATED makes good sense - it can be a big warning flag that
something will be removed, and will make it very easy to code around
changes. Once something is E_DEPRECATED, however, it must stay that
way, I agree with Ilia.
The point of E_STRICT as originally stated was
+1 for reducing severity to E_STRICT
Greg
Wez Furlong wrote:
I agree. Aside from making things difficult, these extra checks are
using up CPU cycles when we don't otherwise care about the problems
that are being highlighted.
I've been out of the loop for a couple of months, so I'm really
Tim Starling wrote:
Pierre wrote:
There is no issue with PEAR or any applications using include_path and
relative paths in include/require. The system include_path, if any,
paths should already be in the open_basedir. If they are not, you
have to install the desired modules within your
201 - 254 of 254 matches
Mail list logo
