Quoting Greg Beaver <[EMAIL PROTECTED]>:
Part 3:
judgment of value
Current approach:
advantages:
1) internal classes resolve very fast
disadvantages:
1) potential unexpected name resolution to internal class when
namespaced classname exists
New approach:
advantages:
1) code runs the same regar
Quoting Marcus Boerger <[EMAIL PROTECTED]>:
actually it was a bug. We, sorry I, did not spot this in earlier versions.
Now saying you rely on a bug in PHP 5 to be able to execute PHP 4 code
simply does not work.
The bug is that with callbacks in PHP 5.3+, E_STRICT is enforced even
when E_S
Guys, there is really no point to argue about aesthetic or taste. Make
your point by using +1/-1 and that's it. As said, the trolls quota has
been used already.
+1
-chuck
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Could someone please take a quick look at bug #43231
(http://bugs.php.net/bug.php?id=43231)? Johnannes said in mid-November
that he had a patch for it but it's been sitting idle since then.
Should be a pretty simple issue.
Thanks,
-chuck
--
PHP Internals - PHP Runtime Development Mailing L
Quoting Martin Alterisio <[EMAIL PROTECTED]>:
Knowing that I'll have to strongly encourage the developers to dump that
patch. The namespace declaration shouldn't do more than what it's expected
to do. Why this:
namespace yadayada;
import yadayada;
Should work different that:
import yadayada;
A few different proposals have mentioned the possibility that import
or use statements might trigger autoload.
My initial reaction is that this would be bad, BUT: it could let us
use autoload to handle namespaced function libraries and namespace
constants also - as long as they were importe
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
Yes. I think that if you use an unqualified name it should always
be relative to the namespace (and importing internal classes into
your namespace lets you use short names for them, avoiding
::Exception).
Unfortunately, there are problems wi
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
import Exception;
-> name conflict, which seems correct
import Exception is a no-op, so I don't understand how you could
have got name conflict. Do you mean "import Test::Exception"? That
should work, if it didn't it's a bug.
It turns out t
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
I'm not sure I follow you. If you intend to always use internal one,
why you define the local one? If you sometimes intend to use one and
sometimes another - I propose you a way to ensure the right one is
always used, this without using potent
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
"import PHP" is a no-op now. However, I have another idea about it
(besides the fix for the import thing that indeed looks like a bug
to me) - what if we add some syntax to say "use this namespace"
which would use autoload, so you'd say:
nam
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
But you shouldn't even look for Exception then. I'm saying that if
you want the global Exception class you should import it.
That would be double bad - that means you have to go over all your
code and add :: to all instances of global classes,
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
This is even better than requiring, and makes the intent very clear.
I don't think it decreases intuitiveness, on the contrary - from the
look of the code it is immediately clear which exception would be
used.
I went ahead and tried to apply
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
... which is correct as far as it goes, there are no side effects.
However, if I flip the include order, including 1.php before 2.php,
then I get this:
Test::Exception
Test::Exception
Of course, since once Test::Exception is defined, Excepti
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
Because if you say "Exception" inside any namespace, we should check
if Foo::Exception not exists anywhere, which means full search of
all autoloading possibilities. Only after we ensured that no such
class exists anywhere, we might use Except
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
Not entirely correct - namespaces needed to reconcile _multiple_
libraries, while in case of Exception you need to stay away only
from _one_ set of classes - namely, internal ones. While indeed even
that could be inconvenient, the problem is t
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
Except that it makes it unclear what happens in _other_ files, which is
In other files you specify what happens to other files.
even worse. Once you include the file above, any other file in the
Test:: namespace that throws an Exception will t
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
This is even better than requiring, and makes the intent very clear.
I don't think it decreases intuitiveness, on the contrary - from the
look of the code it is immediately clear which exception would be
used.
Except that it makes it unc
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
If it worked this way, you couldn't easily use global classes and
old applications would be much harder to convert to namespaces. We
think that using global Exception is much more frequent than
defining your own Exception - and in the latter c
Quoting Gregory Beaver <[EMAIL PROTECTED]>:
Are you suggesting there be namespace-specific autoload? This sounds
interesting to me, but also quite complex, not sure the benefits would
outweigh the difficulties for implementation. For instance, PEAR2
namespace would be different from PEAR2::Som
Hi folks-
I've hit upon something with namespaces and autoloading that I think
is a little out of order. If you take the attached 3 files, put them
in the same directory, and run demo.php, you will see this:
Fatal error: Uncaught exception 'Exception' in /Users/chuck/Desktop/test.php:7
If
Quoting Markus Fischer <[EMAIL PROTECTED]>:
Just to support your proposal: yes. Even as a long term PHP user I found
exactly this problem some months ago. Since I'm familiar with the PHP
source and usually have a checkout around somewhere I can quickly check
functions and I was lazy not reportin
Quoting Ilia Alshanetsky <[EMAIL PROTECTED]>:
In this case the "facility" was implementing, poorly might I add a
handler for a clearly incorrect behavior. Removing it was not only
appropriate but necessary to encourage proper code being written.
I know that other people have other points of v
Relax, I'm not debating the decision. Just:
PLEASE can someone put a big fat warning on the php 4.4 announcement on
www.php.net that it breaks existing code?
I already have people upgrading to it and wondering why they get tons
of warnings now. We're fixing them as quick as we can, but honest
Quoting Andi Gutmans <[EMAIL PROTECTED]>:
OK guys. I'd like to roll so please check this problem and give me an ack
if it's OK.
I believe with Ilia's correction it should be fine now.
-chuck
--
"Regard my poor demoralized mule!" - Juan Valdez
--
PHP Internals - PHP Runtime Development Mailing List
Quoting Jon Parise <[EMAIL PROTECTED]>:
The patch, as committed, breaks backwards compatibility in a point
release. The proper "fix" is to revert it unless someone has a
version that actually works.
I committed a change that should avoid the range check if the FT_UID flag is
set. If someone could
I've just updated cvs.php.net to use mod_rewrite to allow URLs such as:
http://cvs.php.net/pear/Mail/
Old URLs will still work just fine, but the above style is used by default, so
if you want to update any website links, you can. Note that for top-level
directories, you *must* include the trailin
Quoting Hartmut Holzgraefe <[EMAIL PROTECTED]>:
actualy in this special case i have been whishing for an operator for ages,
maybe a modification of the good old ternary:
$foo = ?$bar : "default";
or
$foo ?= "default";
If this were added, wouldn't it make sense to use the convention
alread
Quoting Allowee <[EMAIL PROTECTED]>:
http://cvs.php.net/co.php/livedocs/README?r=1.14
Notice: Undefined variable: flowed in
/usr/home/Web/chora.php.net/horde/framework/MIME/MIME/Viewer/plain.php on
line 38
and a link (www.php.net/license) found on that page:
http://cvs.php.net/horde/services/go
Quoting Stefan Walk <[EMAIL PROTECTED]>:
As far as i can see, that is not neccessary. PEAR naming and PHP naming
would only conflict if a PEAR class extends a PHP class. And i fail to
see cases where that would happen.
That doesn't mean it's not going to happen. Try to be a little
forward-thinkin
> > I just tried a test parse of phpDocumentor CVS using a fresh compile of
> > HEAD on windows xp. It went bananas with warnings and a fatal error.
> > Tracking down the error turned up get_class() returning "parserDesc"
> > instead of "parserdesc", which ruins every time I test whether
> > get_c
I'm not sure which branch, if any, this should be committed to...
- Forwarded message from [EMAIL PROTECTED] -
Date: Thu, 13 Nov 2003 18:08:58 +0100
From: Friedhelm Betz <[EMAIL PROTECTED]>
Reply-To: Friedhelm Betz <[EMAIL PROTECTED]>
Subject: [PATCH] proto fix php_imap.c
To
31 matches
Mail list logo
