Von: Steph Fox [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 5. Dezember 2007 02:34
import nstest::test as whatever;
This works in the global space, right? Now along comes, say, Pierre or
Derick or Marcus with this class they just have to add to an existing
(non-namespaced) core
To summarize the patch lead to approx. 5% slowdown and 3% memory
overhead for typical applications (as always, you mileage may vary
depending on your system's architecture and OS although my guesstimate
is that you will see even worse results in a 64bit environment).
Does that slowdown result
Is it possible to always perform (unconditionally compile in) the
necessary housekeeping tasks but stick with the current GC, so that
cycle-detection only happens when the user calls a
gc_go_find_cycles()
function? Would that significantly improve the above numbers?
Yes, that would be
1) recommend all global non-namespaced code that wishes to import
namespaced code via use Namespace::Classname add a namespace
__php__; at the top of the file, and that the __php__ namespace be
reserved for use by end-user applications.
5) namespaces provide these benefits that are not
Von: Gregory Beaver [mailto:[EMAIL PROTECTED]
Exactly - which is why you should never put classes, functions or
constants in the __php__ namespace. The convention I am proposing is
to
only use __php__ for code that *uses* re-usable components, not
*declares* them.
Let alone __php__. If
-Ursprüngliche Nachricht-
Von: Sam Barrow [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 10. Dezember 2007 22:48
An: internals@lists.php.net
Betreff: [PHP-DEV] Namespace resolution
Ok, it's supposed to be this way right? If i define a custom class in
the global namespace called
Von: David Zülke [mailto:[EMAIL PROTECTED]
The problem I see with that is that if I have an application that uses
a 3rd-party library which does not use namespaces, I need to
use ::LibClass everywhere. Until they switch to namespaces - then I
need to touch hundreds and thousands lines of
Von: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
But you could achiever
the same just by avoiding naming classes the same as internal classes,
you surely know which classes are in your own namespace?
...
Not using names of classes same as internal classes is not a big deal
either - all
-Ursprüngliche Nachricht-
Von: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
If the class for which autoloaded request is issued *exists*.
However, we are discussing the case where this class *does
not exist*, so it can not be loaded. Thus, autoload request
will be repeated on
Just a quick idea - what if requiring that autoloaders behave
deterministically, that is, once a certain autoloader
implementation
has been given the possibility to find a class it will
never be asked
again (because it wouldn't find it later on either).
I'm not sure if it's a
I know this is weird and off-topic but I hope that someone here can give
me a starting pointer.
With installing a security update for the pcre3 library on Debian
(http://lists.debian.org/debian-security-announce/debian-security-announ
ce-2007/msg00177.html), preg_match('|^\(|', 'xxx') suddenly
Hi all,
first of all I do not want to set off yet another discussion about the
changes 4.4 brought. I do understand why the changes were necessary, and
in most of the cases, I would even endorse that pieces of code that
trigger the new only variable... waring are bad code.
Anyways, to me it
So, in case of return new, wouldn't it make sense to remove the
warning as the code is 'legal'? And please, don't start a new it's
just a friendly notice flame war.
It's just a notice, tune your error_reporting level accordingly.
Sorry, but that is just a stupid killer argument.
The return new... is just a subset of the problem, but not
the only one that is in wide use. For example, this is very common:
function getstuff($in)
{
if ($in=='ok')
return new MyObject();
else
return false; // this is the common line
}
The false obviously is not a
I agree that allowing = new and disallowing return new
by reference is inconsistent.
I'm so stubborn with this one because there might be good reasons if
you're the mechanic lying under the car fixing the engine, but it does
not make any sense if you just want to drive the car :)
But PHP4 is
Hi internals,
I was experimenting with different approaches of maintaining state and
serializing objects in PHP5. The problem is handling static class
members and static variables inside methods.
First, I noted that static variables inside methods are shared between
instances. C++ seems to
Von: Wez Furlong [mailto:[EMAIL PROTECTED]
As you mentioned, static properties and statically scoped
variables don't belong to an object instance, so it doesn't
make sense to serialize them.
Ok, but on the other hand they are just variables - so the question was
if there is any (possibly
my suggestion would be, to simply shorten the string that
gets exposed to php - and not show any version numbers (or
maybe leave it to the user, say 0 for no exposure, 1 for
only php and 2 for php with version number.
At least it would be interesting to know about the spread of
You mean something like SRM:
http://www.vl-srm.net/
Though a bit more finished :-)
Derick is probably too busy to finish SRM all alone, and my C skills are
way too bad to help him :) So this gets off-topic here, but what about
writing something like SRM in PHP itself to avoid the need of
I think all of us who were upset making the transition to 4.4.0 would greatly
appreciate if (in the future) there will not only be short there's a new
release notices, but if these notices would directly point to a list like this
one.
E. g. MySQL does a pretty good job with their upgrade
why does the engine care about the visibility of interface
methods I declare?
I understand the argument that interface methods only have
'meaning' when applied as public methods of objects - but
thats rather academic and personally I can think of useful
ways to abuse interfaces using
Jochem,
the point with most of these issues is that there's no common
understanding of what things like protected or static interface members
mean; from an OO point of view, they make no sense, and I was only
trying to explain why.
Unless there is a common understanding what a certain language
- abstract is no longer valid in interfaces.
- that curly brace thing?
I've some fear of terrifying would-be upgraders with an
unnecessarily long list here :)
You're kidding.
If you're intentionally not adding things to that list, better do not
compile the list at all. If people use it as
Anybody interested in my two cents? (I shouldn't have asked as I'm going
to tell you anyway.)
rant mode on
You will break many more scripts by dropping [] for strings than the
other way around. Do you agree? - Heck, this sounds as if you're doing
a let's drop stuff for some technical reason no
For the 13th time. {} is not going away in 5.1.
From the NEWS file:
16 Nov 2005, PHP 5.1 Release Candidate 5
- Added an E_STRICT warning on the usage of {} for accessing of string
offsets.
(Ilia)
That is, code that has been tested with RC4 and that worked (not even a
notice on whatever
I suggest removing that warning immediately until the matter
is resolved.
+1 ( times the discount-for-rants-factor )
-mp
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
If I got that right, you still want to discourage {} and un-deprecate []
again, despite all the good reasons given on this list not to do so?
PHP5.1 would be accomplishing facts as to this one. (Let's remove {}
altogether in 6 - nobody should be using them anyway as they were
deprecated since
Derick,
If you prefer a PHP which causes strange crashses and memory
corruptions, please downgrade to 4.3.11. I am getting tired
about this
bickering about this **FIX** that makes PHP stable.
You got me wrong here. I did not want to say anything against the 4.4.0
fix or even blame you for
This is a non-issue for phpDocumentor. All we need is at
least 6 months
to a year of lead time on the final decision in order to
adjust the code.
As I wrote, I happend to have Smarty and phpDocumentor checkouts at
hand. I just checked a recently installed version of Mediawiki and they
Great, I have been waiting for this list sine Derick mentioned the
meeting in his talk at the conference :)
@Derick: There have been some questions and issues raised during your
talk... Dou you remember them? It was about reading from files with the
new unicode semantics, and you said these were
Now that was a quick reply :)
Also known as runtime inheritance, or late binding. It's not a new
thing, we have it today. The discussion was about whether to
have a way
...
That is, one can write
if (...) class A extends X {} else class A extends Y {}
right now? Seriously ;)?
Every
I don't see why you can't specify that a class definition must have a
constructor. Obviously the constructor is not for the
interface itself.
Ok, that is, having __construct in the interface asserts that everything
you get passed (as an implementation of the interface) has been
constructed
Anyway, I see only one use case for interface constructors:
...
I also thought about that:
$whichClass = ...
if ($whichClass instanceof ISomehowConstructable)
$foo = new $whichClass(...);
would even work without reflection, but of coure would require to change
instanceof a little, too
-Ursprüngliche Nachricht-
Von: Jani Taskinen [mailto:[EMAIL PROTECTED]
We could start with making it an E_ERR..erm..E_STRICT notice
if you use {} with arrays or [] with strings. And really separate
them in PHP 6. But does it make any sense?
At least some people
Well, safe_mode could prevent someone of doing a shell_exec(cat
/home/otheruser/web/config.php); open_basedir can't do the same
thing.
We were in a continual losing race against that sort of thing though.
In pretty much every single release there have been ways to
do this that got
Well, safe_mode could prevent someone of doing a shell_exec(cat
/home/otheruser/web/config.php); open_basedir can't do the same
thing.
disabled_functions=shell_exec, etc
But safe_mode is more safe because it disables these functions
altogether? It's difficult to maintain a
Or
a) am I missing something
b) is it the core developers' opinion that core classes have
the right of way?
kidding
If things behave like that at least there should be a list of reserved
class names just like with other keywords. And of course that list must
not be changed as it is
Then I have to ask both of you: why is there no mentioning in
the release notes or the upgrading guide regarding Date
being reserved for PHP now?
I was also curious as to that. Once again the release announcement (more
precisely, the upgrade document) greatly understates the
Yes, and that will break code again as I just explained to
Sebastian Kettler. And it will break *my* code ;-)
Too bad I don't find the right mail to qoute you now literally - but
nobody forces you to use the official PHP codebase for your stuff; go
ahead and maintain releases for yourself.
obviously one problem is that PEAR does ignore coding standards.
Classes should be prefixed in both pear and core. And
neither Date nor
File is in any way prefixed.
Err, how are we supposed to prefix PEAR::Date?
PEAR_Date?
Date_Date?
Lala_Date?
The whole thing is nothing
I didn't say that my code is more important, but if we don't
get the date class now, we will get it in 5.1.1 and then
break your code - so that doesn't really matter. THe only
correct solution is to start prefixing the pear date class,
as that needs to be done in the long run anyway.
I have always maintained that shared hosts should be running
per-security context Apache instances as different users.
The problem with that is that it makes name-based virtual
hosts pretty
pointless because each apache instance will at least need an ip
address on its own.
It
Von: Andi Gutmans [mailto:[EMAIL PROTECTED]
BTW, just to clarify, I am not against a Date class (whatever its
name) in the long run but I think it'd probably be a
combination of work Derick, Pierre and new contributions.
It would be nice if there would be some 'official' statement as to
I have to back Sebastian with what he said. Obviously the release methodology
currently applied does NOT work, neither for the project nor the community
around it.
Do it how ever you like - discuss whether it's legal to add new features on
HEAD only or on release branches like Jani said.
BUT:
Von: Jessie Hernandez
So, the question is, can we scrap both namespace constants
and namespace functions and just stay with classes (as was
agreed on several months ago, Andi himself agreeing to it)?
...
I think this is the best solution thus far. If any one of you
still feels a need
From: Soenke Ruempler [mailto:[EMAIL PROTECTED]
BUT let derived constructors change parameters
a) as constructors are never called from the parent, but
optionally from a child class, it's completely valid IHMO
b) constructors are usally not used in object aggregation /
setters, but
Hi all,
I'm afraid that recent changes in filestat.c [1] that were meant to fix
a bug [2] with file_exists() also altered the behaviour of
is_readable(). According to the docs [3] [4], is_readable should *not*
take safe_mode limitations into account, whereas file_exists should do.
?php
print
I think the current behavior solves made old bug reports,
where by people used is_readable() to see if they could read
from a file, only to have the operation file due to
safe_mode/open_basedir restrictions. Taking the check away
would also mean it would be possible to explore file file
i dont think this is a recent change. i think its only an
oversite in the documentation.
[EMAIL PROTECTED]:~$ php ./bug.php
5.1.4
string(0)
bool(true)
bool(true)
[EMAIL PROTECTED]:~$ php -d safe_mode=1 ./bug.php
5.1.4
string(1) 1
bool(true)
bool(true)
With 5.1.4 both file_exists() and
-Ursprüngliche Nachricht-
Von: Ants Aasma [mailto:[EMAIL PROTECTED]
That would indeed be too slow. The standard way to handle
this, is to only check visibility periodically. That is how
Java, .NET, Python and countless others do that. Check
-Ursprüngliche Nachricht-
Von: Etienne Kneuss [mailto:[EMAIL PROTECTED]
Gesendet: Sonntag, 10. Dezember 2006 15:55
Cc: internals@lists.php.net
Betreff: Re: [PHP-DEV] [RFC] Magic Method that handles unset($object)
You could use references, you would have to move some code
Hi internals,
please consider:
?php
print PHP_VERSION . \n;
$a = array('a', 'b');
foreach ($a as $ref) ;
$b = $a;
$a[0] = '*';
print_r($b);
?
Result:
5.2.0
Array
(
[0] = *
[1] = b
)
Same with 5.1.4 and 5.1.6. I suppose that using foreach and referencing
the values turns the
Did you try a snapshot?
5.2.1-dev
Array
(
[0] = a
[1] = b
)
Thanks, sorry for the noise.
mp.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Dear internals,
recently I was hurt badly by https://bugs.php.net/bug.php?id=53611. In short,
the FCGI variables PHP_VALUE and PHP_ADMIN_VALUE can be used to pass ini
settings to FPM. This feature was added in
https://github.com/php/php-src/commit/34ba9e39fafa3a980a1b69285f68b0e12ad6b876.
54 matches
Mail list logo
