Hi,
I'm looking at the current namespace resolution rules here:
http://www.php.net/manual/en/language.namespaces.rules.php
Something that bothers me is that for the first time in PHP we introduce a
hard difference in how internal functions and user functions are
resolved/called:
::foo(); // res
Hi,
I'd like to nudge the discussion back to issues with the resolution rules
that we're discovering :)
The actual char(s) used can only be mildly annoying to some (at worst),
compared.
Can we please agree on those (or explain why you'd not):
1) functions, constants and classes should use th
Hi,
No, not necessarily. Functions, constants and classes have different
traditional usage patterns in PHP, and as such may have resolution rules
that follow these patterns. I don't say we should look for making them
different, but if necessary, we should use rules that benefit the most
frequ
internal or user. But in namespace context I'll have to do something
along the lines of:
if (function_exists('json_encode')) {
$encoded = json_encode($raw);
} else {
$encoded = ::json_encode($raw);
}
What this code is supposed to do? If it's supposed to call namespace's
json_encode in c
Hi,
I hear this often by other developers and I tend to agree with them, that
arrays are used often, and often nested, so that having a long syntax for array
literals tend to produce less legible code than in other scriping languages.
$a = array(array(1,2), array(3,4), 5, 6);
$b = array('a' =
Hi,
There is a use case for the function allowing *explicitly* call-time pass by
reference, because the function works both ways in subtly different ways.
I have some libraries where I had to have variations of the functions like
"AbcByRefr()" and "Abc()", because of this inflexibility.
In
Hi,
Actually PHP ignores default values on parameters followed by required ones.
You can't fetch the default value even via Reflection.
This is easily detected at compile time so I wonder why the compiler doesn't
warn.
Regards,
Stan Vassilev
what stops you from declaring:
function someFu
Hi,
Please notice that I said "followed by required ones".
function foo($a = null, $b) {}
The above definition is allowed and the compiler won't complain, but
actually that "= null" is completely lost, including in Reflection.
Regards,
Stan Vassilev
2008/5/22 S
Hi,
Just making sure I understood it well. Get isn't deprecated (good), set is
(good), but what happens if I try to set magic quotes runtime *off* if it
was *on* from the config.
I couldn't see anything about the PHP config setting being ignored/removed
or throwing error in the RFC.
For c
Hi,
There are three purposes:
1) At call time, nothing significes what is the caller passing, the syntax
is the same for passing reference or passing value, so it's prone to
confusion. You're passing something which *may* or *may not* be modified if
taken as a reference. Quick, is the variab
Hi,
No one said it's a matter of life and death. But is it only a matter of life
and death improvements that should be considered for PHP?
The typical use case that benefits most from this is when a function accepts
arrays as a means of structured/named/nested options, something I use a lot.
Hi,
You examples are showing some quite horrible situations with namespaces.
Agreed, the least thing, an error should be thrown on collision.
Regards,
Stan Vassilev
I find the namespace resolution rules quite confusing. It's become quite
difficult to tell if I'm calling a static method or
Hi,
I suppose this has been discussed before, so I'll not repeat reasons unless
requested, but I just want to offer a possible feature to mitigate the impact
of "one namespace per file", which doesn't have controversial syntax and
hopefully less difficulties in the implementation:
class Fully
lasses/constants
So I'm trying to to address 1) in this thread.
Regards,
Stan Vassilev
- Original Message -
From: James Dempster
To: Stan Vassilev | FM
Cc: internals@lists.php.net
Sent: Saturday, May 31, 2008 3:43 PM
Subject: Re: [PHP-DEV] Alternative to multiple nam
Hi,
Your suggestion seems ok too, anything is better than *no functioning way at
all to do it*.
Regards,
Stan Vassilev
- Original Message -
From: James Dempster
To: Stan Vassilev | FM
Cc: internals@lists.php.net
Sent: Saturday, May 31, 2008 4:02 PM
Subject: Re: [PHP
Hi,
I'm a user-space developer. And while indeed not doing anything is annoying
enough that I've started learning the internals of PHP, I'm not at the point
where I can confidently submit namespace patches myself. And let's face it,
they'll be ignored.
I would think those with the "karma" a
How bad would it be to say that namespacing can only apply to classes and
not normal functions?
Lame, very lame. It would make them unusable for many distributed
projects that are not 100% OOP. Wordpress comes to mind. My own Phorum
as well.
I agree, namespaces need to work for all defi
Hi,
Actually starts with and ends with is a very common case. I see your
concerns, but I can see instantly quite a lot of places in my code where I'd
use those. And I bet it'll be faster too.
Many of the string functions can be replicated with one-liners using other
string functions, same f
;))
vs.
if(substr($path,-4)=='.php'))
I just don't see that this is solving any real painpoint.
-Rasmus
Stan Vassilev | FM wrote:
Hi,
Actually starts with and ends with is a very common case. I see your
concerns, but I can see instantly quite a lot of places in my code where
For better or worse 99% of the code I write runs on systems without an
opcode
cache 99% of the time so that's what I optimize for. That it is
apparently
impossible to optimize for both opcode caching and non-opcode caching
environments at the same time (the former hates conditional include, the
I have to agree, this kind of change would be very frustrating for Win32
users, even though the solution is that simple.
Nobody reads update guides or installation instructions, they're used to
write path like that and they'll continue to do it, so we'll have much
more bug reports after the re
On 04.09.2008 23:08, Stan Vassilev | FM wrote:
There won't be any bug reports, if the ini parser detects improper
backslash usage (i.e., using a backslash with a following character which
doesn't form correct escape combination) and stops with informative and
descriptive message expl
On 05.09.2008 14:57, Stan Vassilev | FM wrote:
I read it. \D in the same string isn't a legal escaped combination and
this is where the user will be warned.
Nope. This is perfectly legal, too.
# php -r 'var_dump("\W\H\A\T?");'
string(9) "\W\H\A\T?"
H
Hi,
I suppose since I use autoload and classes I belong to the first group.
Thing is, we still do care about performance.
I currenly use underscores as some other programmers do, to "fake"
namespaced identifiers, and from my tests and this discussion so far I'm
convinced the namespaces as t
Hi!
So I'd say, make it explicit and remove the vague moment.
Do I understand right that you advocate having to use ::Exception each
time you need the internal class?
As I said:
"I heard lots of objections how ugly it is to prepend everything with "::"
(not
that this is the only possibly
As you said before - how is it any different from just being able to
call escape("foo") or display("foo"); It's a matter of taste. To me
that is not anymore of a meaningful name - just a different syntax and
not one your average wordpress user would know how to handle.
Well, if it's just a matt
Hi!
And I'd ask - who wants to do new DB::mysql when they can just do mysql?
I do. Because this way I don't have to worry my mysql would clash with
someone other's mysql, and I can have all DB related stuff under one roof.
It can't clash if you don't "use" someone other's mysql namespace, o
Hi,
He means recursion depth, not input nesting depth. 5.3 had a proposed fast
function call algorithm which would avoid the stack limit and allow deeper
recursion, was this accepted and how does it affect the limit of 100 nested
calls?
Regards,
Stan Vassilev
Hi!
Currently I'm working o
Hi,
Multiple namespaces per file were introduced to allow certain workflows in PEAR
and frameworks like Symphony which can combine multiple classes and namespaces
in a single package.
They work like this:
namespace X;
...
namespace Y;
...
The problem is, no one thought of scoping "use"
Stan Vassilev | FM wrote:
Hi,
Multiple namespaces per file were introduced to allow certain
workflows in PEAR and frameworks like Symphony which can combine
multiple classes and namespaces in a single package.
They work like this:
namespace X;
...
namespace Y;
...
The problem is, no one
Hi Stan,
I realized I missed 2 of your points, response below:
Hi,
Thanks for your work on resolving these issues. My comments about
use/namespace being a hack regards just the syntax, I was wrong about the
scoping of use, but also having "namespace" act as a scope without the scope
synta
Hi,
I'm in favor of this patch for simple reason that the "nothing before the
first namespace" limitation is more of a WTF than a sound design prevented
to limit an actual problem.
We have multiple namespaces per file, so having some of the file in the
global namespace (i.e. == no namespace
Hi,
I just figured a problem related to this.
We have multiple namespaces per file so we can merge multiple files
together. We have no way to break out to global space after a namespace, and
even with this patch, no *code* can exist before a namespace.
So this means we can only merge files
On Sun, Sep 14, 2008 at 5:33 PM, Rustam Abdullaev <[EMAIL PROTECTED]>
wrote:
Hi,
Is anyone working on a suspendable request support in PHP when used as a
module in Apache?
Suspendable requests are great for supporting Server Push technology, but
are currently only supported in Jetty and Tomcat.
Hi,
1. and 2. are great. I'm happy to see this done.
But for 3. I think that's throwing the baby with the bathwater.
Since now global classes inside namespaces will need the "use ::Foo;" or
"::Foo...", I hope you can give a fresh look at my original idea that both
functions and classes requi
Hi,
The second highest vote was :::, but there was strong objection to this
as well from some. The problem, I still believe, is that we are focused
on having the same:::stupid:::operator:::between:::everything.
The truth is that in source files, there is a clear boundary between
namespace defin
Hi,
I think we need string concatenation here and there ;)
Regards,
Stan Vassilev
- Original Message -
From: Arvids Godjuks
To: Stan Vassilev | FM
Cc: PHP Internals List
Sent: Monday, September 29, 2008 9:19 AM
Subject: Re: [PHP-DEV] solving the namespace conflict
String concatenation woun't be affected, because you can't concatenate
class definitions like in my example.
To concatenate you should use variables or strings/numbers. So I don't see
any complications with that.
MyNameSpace.SomeClass::_getInstance()->SomeDBClass->Query();
You're forget
Hi!
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
Regarding internal class resolving, it seems logical but will slow down
resolution within namespaces. But I doubt this is much of an issue as it
doesn't affect those not using namespaces.
I don't think that makes sense to say "it doesn't affect people not using
namespaces" when talking about na
Hi,
Guys, this is like junior school in here.
Let me put some things in perspective:
1) The location of backslash on foreign keyboard is entirely irrelevant for
the choice of namespace separator. Why? You already use this *every day* to
escape characters in your strings and regular expressio
On Wed, Oct 22, 2008 at 5:03 AM, Ryan Panning <[EMAIL PROTECTED]> wrote:
I've been wondering, is such a thing even possible? Is there a good way
to
implement an object destruct order? Here are my thoughts:
In the class definition, specify what "level" of destruction the objects
should be on. Ho
Hi,
Naturally this line:
"$this->addObject($this, $priority);"
was meant to be:
$destructManager->addObject($this, $priority);" ...
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
That isn't very intuitive. I would think it was a typo when reading
such code and fix the header line...
I'd suggest explicit header_remove("Vary");
Agreed, a specific function with a clear name sounds better.
Christian, can you update the patch? - thanks!
johannes
I suggest header_remove(
Hi,
I want to thank you all for opting for the technically sound, clear and
performant solution. Of course some users will never understand the precise
reasons :: was avoided, but it's something we'll have to live with, given
some past design choices in PHP.
Regarding "foo\tbar" turning int
Hi,
Now that we have a separator, it's time to clarify what happened to the
resolution order for functions and classes, which if I read Greg's messages, is
still not clearly defined.
1) I think we've established that autoloading + fallback for classes is
unworkable, as it either causes excess
It doesn't take a lot to kill an application if using internal class causes
__autoload to run for a non-existing user class.
Neither caches not optimizations can avoid that, as you can't have something
cached which doesn't exist.
In my autoloader for example, an existing user class is resolve
History has shown
us that breaking code (e.g. PHP4 - PHP5) slows adoption of new
versions.
Bad example as PHP4 > 5 broke existing code. No existing code has namespaces
in it. Anyway:
A yet another compromise is possible as the lesser evil:
Resolution for classes:
namespace
I've not seen plenty of "Class::singleton()" myself, getInstance is an
accepted standard in all languages, including the PHP code I wrote, and I've
had experience with.
Regards, Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/un
We are going to ignore the inherit problems that calling
file_get_contents(__FILE__); would cause...
Also, I disagree with a PHP namespace. the looseness of the language
is one of its strong points. Some things should be made strict, I
agree, bit it start with a php namespace and where does it en
an semisolution would be an php.ini variable
like
NAMSPACE_SEPARATOR="::"
so if you have an issue with your classes can be reset to "\" or
whatever with ini_set
You're always welcome to change the separator in the PHP source code,
compile that and use your fork as you please. The source code i
I would say "no" for 5.3. But for 6 it would be fantastic to have all
array-related
operations supporting ArrayAccess interface, where possible.
+1 for this.
Hi,
cu, Lars
Just making sure but: I think the BC break should be fixed. It's breaking
actual code out there. The practice of passing
Hi,
With namespaces and "use" we'll be introducing a new kind of discrepancy
between a string reference to a function, and the short "use"-enhanced name for
the same function. This becomes very painful, when I want to load a function
before I run it.
Today I would do (due to lack of function
Note that I say "try internal" because the only purpose behind allowing
this is to make it easier to use PHP's built-in functionality. Any
userspace stuff should be specifically \prefixed or imported via use.
And (yes) we need import for functions.
Greg
P.S. my mail server has been down for
Here is a reason why we would limit this to international functions only:
- <@Stas> but note that global user-space fallback for function means
run-time resolution (which may be ok, but slower - no caching resolution
in bytecode cache)
Hi,
Not true: you can't resolve it at compile time wit
Here are some reasons why we felt that functions/constants should
fallback:
- most namespace users will be using classes and not functions
This is a self-fulfilling prophecy, the more you open a gap between classes
and functions, the more people will stick with the richer functionality
since
- people expect direct access to the vast number of php functions/
constants
Do you know rule 1 in #phpc? This is one of those cases.
People want :: and not backslash.
People want global stuff to resolve in their namespace (how does this make
any sense? the very idea of a namespace is to avoid
Hi,
I just wanted a clarification on this. Currently many of us have class names
such as:
Zend_Validate_Interface
Foo_Utils_Array
...and so on. This works fine as it's just a single T_STRING.
As you know, with the new convention, the parser will not encounter T_STRING
"Zend\Validate\Interfac
Hi,
Watching my thread devolve into a blamefest wasn't the intention. I just
wanted a clear answer if something's done about it or not.
To everyone participating in the thread: guys it's NOT trivial in the
current situation. To the parser, a separate string matching a keyword is
the token k
NOTE: Continuing from thread "Call it: allow reserved words in a class or not?":
> As much as I'd love to see more case-sensitivity, I'm afraid it would
> break quite a lot of existing apps, according to Google Code.
>
> http://www.google.com/codesearch?q=lang%3Aphp+%3D%5Cs%2AArray
>
> -JD
It's
Hi!
As you know, with the new convention, the parser will not encounter
T_STRING "Zend\Validate\Interface" but rather:
With namespaces, class name would not be Zend\Validate\Interface. Having
namespaces, it would make much more sense to make last component a
descriptive name, so you won't ha
So allowing passing objects to array stuff using HASH_OF can lead to
unexpected behavior. Dropping the old behavior makes this clear ... but
is bad for stuff like ArrayObject.
I'm not sure whether we should add special rules for a single class
though ..
johannes
The exception should be made fo
What about adding a function that behaves like __autoload, but with
respect to namespace wildcards? Something like:
Hi,
Ok so first:
1) We can't implement wildcards since a wildcard needs to be expanded to a
set of concrete classes at runtime for it to make sense, and we don't know
what tho
As another example, anyone with half a brain and more than 10 minutes
experience with the internals of PHP knows that it'd be ridiculous to
suggest that PHP's array type be re-written to act like Java or .NET.
The fact that it is ridiculous is implicit, we all know it, it doesn't
need to be sai
Sounds like an idea for custom extension, but I doubt this would work
as a general approach.
It limits dynamic nature of php, so won't be suitable for all cases
Did you see this extension?
http://pecl.php.net/package/automap
Just two points:
1) It doesn't need to be suitable for all cases, as
Technically, you could argue that blah::hi() should resolve to
blah\blah::hi(), but it is very difficult to track and figure out what
"blah" means by eye. Thus, in the patch I implemented, if bracketed
namespace declarations exist, global use statements are not allowed, but
must exist within na
Sorry for the second email, I just forgot to mention something regarding how
use statements apply from global scope to namespace x {}.
The best way regarding realworld usage and existing state of the art would
be to take into account the use statements in the scope above and apply the
use stat
Hi,
Ok so I had a quick chat with greg and reread his proposal and it's actually
a sound proposal.
My original concern was that if we don't implement proper subset of
"namespace scopes" we'll have difficulty extending PHP in the future to
support function-local use declarations etc.
Howev
I understand this new behaviour is same as using "relative paths", but
there is a common best practise to not make dependencies form topper
namespaces to deeper ones.
So it is rare to have class Company\Software\Base extending
Company\Software\Web\Forms\Control (i.e. Base extends Web\Forms\Contr
I just ran a quick benchmark on this and I'm not seeing a significant
real world change for Facebook's codebase. (definitely less than 1%)
This was a pretty small test, without a lot of code execution, so I could
see other applications doing better. I'm pretty neutral on this one,
it's not a
Or Zend Framework source code. There is no class extending class from
subpackage (class Zend_View extends Zend_View_Abstract is not
subpackage, viz
http://framework.zend.com/wiki/display/ZFPROP/Naming+conventions+for+2.0+-+Matthew+Ratzloff).
*
> *In PHP nothing bubbles, hence this doesn't work.
This wouldn't really help with the case here of "if ($array1 ==
$array2)..." though right? (not to say it's not good, just making sure I
understand ;-) ).
Yes I'm talking about speeding up scenarios full of hash lookups in general.
It sounds like this would only work if the array contents
Since nobody else has chimed in with the obvious (to me, anyways):
I've worked with some code that uses disgustingly huge (>512Mb) arrays,
largest implementation was a single 2.5 Gb array (before we took the
offending programmer into a room and had a... chat).
I'd be interested in seeing so
I don't see it would work with something like
import_request_variables() unless thats removed or extract(), which is
some of the reasons for this replacement feature afair.
There was never a need for the replacement to occur for the GPC
superglobals.
If import_request_variables() needs it, i
class Helloworld
{
public function sayHello() { print "HELLO"; }
}
category HelloworldExtras on Helloworld
{
public function sayWorld() { print "World"; }
}
$h = new Helloworld;
$h->sayWorld(); // print "WORLD"
This is extremely beneficial for lightweight "extension" of classes
without s
On Wed, Nov 12, 2008 at 03:57, Stan Vassilev | FM <[EMAIL PROTECTED]>
wrote:
I don't see it would work with something like
import_request_variables() unless thats removed or extract(), which is
some of the reasons for this replacement feature afair.
There was never a need for the
Hi Marcin,
Stan also requested this, so it should be considered as a possibility.
Personally, I would rather not introduce this land mine. It requires
the user to do an implicit prepending of namespace name ("foo") to "bar"
in the use statement as well as a translation of "A", which could fast
Are you aware of __NAMESPACE__? Also, if you are using a lot of
external namespace names, you might consider simply defining constants:
namespace foo\bar\baz;
const ns = __NAMESPACE__;
then you can simply do
use foo\bar\baz; $name = baz\ns;
I don't see a huge pressing need for nameof since t
Why? I have developed framework using PHP namespaces and studied Zend
Framework source codes and result is: if we use the new resolution rules
(1), than in nearly all cases developers must prefix class names with \,
only in few cases prefix is not required. Why? Because usually classes in
more
> Zend_Acl ==> Zend_Acl_Resource_Interface, Zend_Acl_Role_Interface,
> Zend_Acl_Role_Registry, Zend_Acl_Assert_Registry...
>
> Regard, Stan Vassilev
Stan, ZF doesn't use namespaces yet. This is not namespaced code.
Namespaced code requires different convention
(http://framework.zend.com/wiki/d
Hi!
Hmm, I really think we should simply maintain BC 100% but using the new
BC 100% makes little sense - why usort can accept object but sort can't?
And functions like next/prev are useless with many types of objects.
Especialy think this through for the next
bigger release (presumably PHP
Hi,
Earlier I proposed this construct which fell on deaf ears, maybe since it means
a new keyword "nameof":
namespace Foo\Bar;
class Baz {}
$name = nameof Baz; // 'Foo\Bar\Baz'
The same expansion to FQN happens for imports/aliases with "use XXX".
I want to suggest an alternative approach whic
Hi!
As a PHP user who'd want to migrate to 5.3 sooner than later, and uses
those heavily, I'd rather not see BC breaks in a point release, even
though just like you I see some WTF-s in the old behaviour.
You heavily use natsort on objects? What for?
If natsort covered the entirety of this B
var foo = ;
... (yes, they maybe heared somewhere that JSON is *not* javascript, I
told 'em too).
JSON is a strict subset of JavaScript, and the above scenario is something I
also do often.
Since PHP generates web pages, any time I need to generate a JS literal
json_encode() is the natural e
Hi,
JSON allows extensions. I can not understand why this is not an extension
that makes sense:
json_encode($var, $allowScalar = false);
In PHP outputting of JS literals is a common action, so all you'll achieve
by completely removing this option, is forcing people to go from this:
echo '
1. Document the fact that if you want to strictly conform to the JSON
spec and be sure your json_encode output will work in various JSON
parsers, you have to pass it a PHP array or object.
+1
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
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
Hi,
With __autoload you can throw an exception as long as you define the class
requested.
If you don't, the fatal error from the fact the class isn't there is
triggered before the exception and you never see it.
A clutch would be eval-ing an empty class with the same name right before
you t
Hi,
I had a talk with Marcus, and he has agreed on this proposed solution:
1) SPL generates a pseudo-random session id/mask (for the current request,
do not confuse with $_SESSION), which consists of 32 random
bytes/characters.
2) The object is and the handler pointer are used to create a uni
Especially in namespaced code it should be very useful to have
"something" returning fully qualified name as string. It can be operator,
but I think introducing new keyword is bad way, or it can be realized
using well known magic constant in new context:
Example:
function factory($class)
Why not just enhance get_class() function to accept the object itself
(not only the instance)?
This means:
- No new keyword
- No magic Foo::__MIRACLEHERE__
- No 50 pages documentation to help user
Hi,
You can't do this. get_class(SomeClass) would attempt to pass constant named
SomeClass t
Hi,
Try this:
use PDO;
Regards,
Stan Vassilev
-
Hello,
I've been writing in the last days a web application on PHP 5.3 (beta1
although RC was released) cause of all the goodies it brings,
specially the names
g in order to use classes declared in the global
scope? This means SPL classes and 3rd-party classes.
Is there a way to import all the SPL classes at once? ;) (use SPL\*,
use PDO\*).. just wondering.
Thanks
On Tue, Mar 31, 2009 at 5:38 PM, Stan Vassilev | FM
wrote:
Hi,
Try this:
use PDO
Hi,
A vote in support of short tags, although last time I checked they were not
removed in PHP6 (and I hate to see this brought up once more).
On top of that, the supposed XML conflict argument is not fully thought
through, since full PHP tags are not XML compliant either:
"; ?>
In the above
The question here is how to handle property accesses, in particular
accesses to unspecified properties.
I actually would expect to have a lookup mechanism which first looks in
the trait, and if the property is not found there, its going to the
object. I expect this behavior, because it is simil
trait Counter {
var $value;
public function inc() { $this->value++; }
...
}
trait Color {
var $hue;
var $saturation;
var $value;
public function getRGB() { /* ... */}
...
}
class MyClass {
use Counter, Color;
}
Ok, you could argue that you than will have to refactor your prope
96 matches
Mail list logo
