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
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
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:
?php echo ?; ?
In
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
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
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)
{
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
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
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
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
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
var foo = ?=json_encode($my_string)?;
... (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
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 which
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
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
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
lead
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
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
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 replacement
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,
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
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
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
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
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
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
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,
?php
use blah\blah;
$f = new blah;
namespace one {
use foo\bar as blah;
$a = new blah;
}
// what is this?
blah::hi();
?
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
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
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.
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
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 worse
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
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
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 with
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
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
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
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
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:
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
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 is
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,
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
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
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 into
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. How,
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
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
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
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
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
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
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 require
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 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
syntax
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
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,
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
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 matter
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, or
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
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 explaining
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?
Hi,
If you'll treat the INI parsing exactly
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
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,
)=='.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
I'd use those. And I bet it'll be faster too
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
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
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
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
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 namespaces per file
what I
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,
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
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 a
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
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 Stan Vassilev | FM [EMAIL
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
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
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
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
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(); //
92 matches
Mail list logo
