Re: [PHP-DEV] ereg deprecation?
Hi, I think I asked this before on IRC, but I've forgotten the answer. I was just remembering that the ereg extension was due to be deprecated in PHP6 - does this still apply to trunk? Deprecated since 5.3, and was to be removed in 6.0. In that context, it remains deprecated in all new branches. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Obscure token name
T_PAAMAYIM_NEKUDOTAYIM is hardly un-google-able. If users have to Google it, we've already failed ;) By the way, the Hebrew name was (at some point) for removal, to be fully replaced by its alias T_DOUBLE_COLON. With the PHP6 branch being scrapped I lost track of what happened. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A critique of PHP 6
Come on. Is it really that hard to write strlen? Or array_merge? Would it be better if they were len (of what?) and merge (what?)? I don't think so. Ahem. We all secretly know how it should've been from the very start. Pseudo-methods for the basic types. $array-merge($array2); $string-len(); Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A critique of PHP 6
4. PARAMETER ORDER. Two letters: BC. Changing variable order in an existing function is a big fat BC break. And if we put such a bomb into a new version, what would be the incentive for people to use it? So that apps would have to be shipped in 2 versions, for the old php and the new php? Is this something that could be fixed if it's moved to a namespace? The new alias can have the correct order but original function can have the old order. No, it would me having two implementations. Derick There's only one way to both maintain BC during a transition period, and fix flaws to prepare for the next 10 years. And that's having two implementations. The original one will gradually be deprecated and eventually removed. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Turkish/Azeri locale support
As at least some of you would already be aware, there's a long-standing issue with using PHP in a Turkish or Azeri locale, namely that case-insensitive lookups within the Zend engine (method names, for example) fail on lookups involving upper-case I characters, since lower-case I in those languages is ı instead of i (note the lack of a dot). The long term plan for this, per bug #35050 and any number of duplicates, was to deal with it in PHP 6. Since PHP 6 isn't going to happen in its original form, I think we're going to need to revisit how we want to deal with this. There's a patch linked in the bug from Tomas Kuliavas and Marcus that fixes the problem by simply redefining zend_tolower() to a simple locale-insensitive ASCII tolower() function, which does fix the Turkish and Azeri locales. As you illustrated in your post, fixing it for locales becomes... complicated. If you ask me, there's only one way to fix this, which is how most other languages fixed it: make the next major version of PHP case-sensitive for all identifiers. For less bugs, less locale problems and more performance. It was somewhat-the-plan, even before the Turkish locale issue was brought up. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: shorthand object property setting syntax.
Hi,
There is another solution to this problem, which is sort-of-on-the-table,
and it's named parameters:
$myLongNameObject = new MyLongNameObject(
'property1' = '1',
'property2' = '2',
'property3' = '3',
'property4' = '4',
'property5' = '5',
);
With proper update, code hinting for named parameters could be introduced in
IDEs in order not to end up slower than the current syntax.
It also solves other issues and doesn't suffer from the scope resolution
problems with() {} suffers from.
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: shorthand object property setting syntax.
Hi,
There is another solution to this problem, which is sort-of-on-the-table,
and it's named parameters:
$myLongNameObject = new MyLongNameObject(
'property1' = '1',
'property2' = '2',
'property3' = '3',
'property4' = '4',
'property5' = '5',
);
With proper update, code hinting for named parameters could be introduced in
IDEs in order not to end up slower than the current syntax.
It also solves other issues and doesn't suffer from the scope resolution
problems with() {} suffers from.
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Raise warning first on Maximum execution time exceeded
With the help of Scotts last suggestion, I made some changes. It seems to work, but then I don't really know how to test it properly. I can verify that A) it allows userland code the grace period of 1 second for shutting down and B) shuts down regardless of the userland error handler returning or not. I have tested by running the following: Hi, Thanks for your patch, but you're going to affect a whole group of users who do advanced logging and recovery in the shutdown phase. This is why these things have to be considered when they're first added. A grace period of 1 second seems sufficient on a pristine condition unused server, but when your server is loaded, a spike in load may cause a number of shutdown handlers to take more than 1 second, and stop middway running, causing a lot of unpredictability and trouble for those who rely on this feature. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where are we ACTUALLY on Unicode?
If Unicode were the solution, the PHP project was on the right page with 6.0. Sure there remained work to do, but... How long did it take to realize UTF16 wasn't the end of the story? UCS-4 is the minimum to solve this, and we all agree that 32 bits aren't storing a single char in the western world, no way, no how. The UTF-8 solution is probably the right answer... you maintain 95% of char *UTF behavior, and you gain international character representation. The only Unicode OS I can think of offhand is NT, and of course they hit the UCS-4 problem early. They found this out 15+ years ago. Sure it doesn't appear as atomic, one Xword per char, but the existing library frameworks contain most of the string processing that is required. There is no 16-bit network transmission API that I can think of, you are still devolving to UTF-8 for client results. To move forward with accepting -and preferring- UTF-8 as the representation of characters throughout PHP, recognizing UTF-8 for char-length representations, and so forth, would do wonders to move forwards. And 8-bit octet data can be set aside in the same data structures. It is the straightforward answer, which is probably why Linux did not repeat Windows NT decision, and adopted utf-8. Hi, UTF8 is good for text that contains mostly ASCII chars and the occasional Unicode international chars. It's also generally ok for storing and passing strings between apps. However, it's a really poor representation of a string in memory as a code point can vary between 1 and 4 bytes. Doing simple calculations like $string[$x] means you need to walk and interpret the string from the start until you count to the codepoint you needed. UTF8 also takes 4 bytes for representing characters in the higher bit planes, as quite a lot of bits are lost for every char in order to describe how long the code point is, and when it ends and so on. This means memory-wise it may not be of big benefit to asian countries. Since the western world, as you put it, wouldn't want to waste 4 bytes for characters they use that fit in 1 byte, we could opt to store the encoding of a string as a byte enumerating all possible encodings supported by PHP (I believe they're less than 255..), so the string functions know how to operate and convert between them. This means you can use Unicode only when you need it, which reduces the impact of using full 4 bytes per code point, as you can still use Latin-1 1-byte encoding and freely mix it with Unicode, and still produce UTF8 output in the end, for the web (the final output encoding to UTF8 from *anything* is cheap). Another alternative is doing what JavaScript does. JavaScript uses 2-byte encoding for Unicode, and when a code point needs more than 2 bytes, it's encoded in 4 bytes. JavaScript will count that codepoint as 2 chars, although it's technically one codepoint. It's awkward, but since PHP is a web language, consistency with JavaScript may even be beneficial. It also solves the $string[$x] problem as you no longer need to walk the array, you just blindly report the 2 bytes at address string points + 2 * $x. With this approach, all characters in the BMP will report correct offsets with char index and substr functions as they fit in 2 bytes. Workarounds and helper functions can be introduced for handling 4 byte codepoints for the other planes. It of course makes certain operations harder, such as character ranges between two 4-byte codepoints in regex will produce unexpected results, and regex will see these chars: [2bytes2bytes-2bytes2bytes] i.e.: [a b-c d] and not this: [4bytes-4bytes] Still, having variable-width encoding UTF8 or UTF16 doesn't cut it for general use to me as in tests it shows drastic slowdown when the script needs to do heavy string processing. I'd rather have it take more RAM for Unicode strings while being fast, and use Latin-1 when what I need is Latin-1. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Scary note for gettype() in docs
On 03/01/2010 11:35 PM, Stan Vassilev wrote: Hi, The gettype() documentation warns people that the returned string is subject to change. Why is there a function that's subject to change in the API? Because life is complicated. Because gettype(test) returns string in 5.x and unicode in 6.0. What exactly are you trying to fix? And what exactly are you proposing? If I have to propose anything, that'd be for 6.0 unicode strings to return string and binary strings to return binary, as that is more apt for the real-world use cases people will find themselves in (and migrating code will be easier). A PHP user stumbled onto the subject to change note and asked if it's safe to use. If differentiating both types of strings in 6.0 is what was intended, then it's perfectly safe to use, and I'll probably file an issue with docs to be more clear about the actual situation. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unserialize is broken
Hi, If visibility is an issue why not just use json_enode/decode for this case then?it doesn't seem like a typical enough problem to be solved low-level and json seems fast enough for the job ;-) Hi, I don't know whether it should be fixed or not, but it definitely shouldn't have received resolution Bogus in the bugbase. Bogus means the issue doesn't exist as described, is not caused by PHP, or it's part of the expected, intended, documented behavior of the language. In this case the issue is an undocumented edge case, it's counterintuitive, and it's reproducible with the provided code. If it not feasible to fix due to performance reason, the resolution should be Won't Fix. Marking a real issue as a bogus one deprives people who work on PHP from having a handy log of issues that could be reviewed and possibly fixed at a later point as the egine changes and a solution no longer is a BC or performance issue. It's also insulting to the submitter, who took from his time to file an actual problem and was basically dismissed as uninformed on the issue. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Scary note for gettype() in docs
Hi, The gettype() documentation warns people that the returned string is subject to change. Why is there a function that's subject to change in the API? And just to clarify: I agree is_*() is better if we test for a certain type (as the note says). However, the use scenario for gettype() is when we do not test for a certain type (as in, we test for any type), which is less optimal when executed as 5-6 is_*() calls. Regards, Stan Vassilev
Re: [PHP-DEV] About optimization
The gc code when combined with apc is still a bit shaky in 5.3. I haven't figured out why yet. And my motivation for figuring it out is pretty low as code that relies on gc is slow. -Rasmus Motivation for relying on GC in 5.3 is pretty low because 5.3 is still a bit shaky... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dots and spaces in variable names are converted to underscores.
And I'm not sure who would actually use 'a.b' and then expect 'a_b', but I have to assume somebody has done that, perhaps consuming an API from somewhere else. OpedID protocol uses dots in query string arguments. The implementations could be broken by the patch. While the keep arguments as is behaviour is certainly better in the long run - issues like OpenID should be taken into account. Hi, PHP6 *is* the long run. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dots and spaces in variable names are converted to underscores.
Dots and spaces in variable names are converted to underscores. For example input name=a.b / becomes $_POST[a_b]. Any reason why? and any way to modify this behaviour to preserve dots and spaces? (dots specifically) I'm also using dots for this reason, so I feel your pain. What I ended up doing is converting dot syntax to PHP array syntax as I compile my templates. So when I type this: input ... name=a.b.c.d what I get actually compiled and sent to the browser is this: intput ... name=a[b][c][d] The reason for this quirk is register_globals. The symbols not suitable for symbol names, such as dots, are replaced with underscores, so that you can access your POST variable foo.bar as $foo_bar in global space. Of course it never made sense the conversion is applied to the superglobals like $_COOKIE/GET/POST, but it was, and now there are claims that it'll break backwards compatibility if changed. I hope PHP6 will remove this processing as register_globals will be completely removed at that point. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dots and spaces in variable names are converted to underscores.
Well, that conversion still needs to happen somewhere, since plenty of
apps call extract() on those superglobals, but with register_globals
entirely gone in PHP 6, I suppose that conversion can be moved to the
extract() call.
-Rasmus
Hi,
I'm not sure it needs to happen anywhere. Such symbols could be simply
referred to with the intended syntax: ${'a.b.c.d'}.
By the way, extract now seems to just ignore those vars when given an array:
extract(array('foo.bar' = 'baz'));
echo ${'foo.bar'}; // notice, no such variable
echo $foo_bar; // notice, no such variable
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dots and spaces in variable names are converted to underscores.
I'd be happy if it stayed like it is, for backwards compatibility. If not, then there needs to be some reasonably straightforward way for an app to work out how PHP has messed up its input so that it can put it back together (compare get_magic_quotes_gpc()). In any case, it could be better documented. I see it is documented in these places: Hi, I look at this feature more as a broken compatibility with HTTP, since there's data lost from otherwise valid field names on the way from the server to PHP's userland. Since the bigger feature in question (register_globals) is removed, people who use the underscore filter with register_globals have already lost backwards compatibility. For those who want to *emulate* register_globals with extract(), they can easily emulate the underscore filter as well (it's 3 lines of code). Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] function call chaining
If everything is chained, it's a pain to figure out such basic workings. Hi, I still find it hard to understand why some should artificially claim basic constructs supported by other languages for years are somehow more complex than PHP's existing semantics. Supporting dereferencing in all situations where it produces unambigous results is necessary to improve consistency of the language, so we stop seeing people surprised why something works in one context, but not another. Working around PHP's limitation with redundant factory methods and temp vars do not help code readability. They are just arbitrarily imposed because of an irrational fear that suddenly everyone will be jumping on the new feature for his entire codebase. Even most poor coders are smarter than this. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Autofunc patch (automatically loading functions like autoload)
Hi, Unfortunately there may be a problem with this path and namespaces in 5.3. I tried to warn about this while namespaces were being implemented, but everyone was in the autoload will always be for classes only. Right now when you use fully qualified name of a class when inside a namespace, you need to always prefix it with backslash: \Foo. For functions, it was deemed too hard as most internal functions remain in global space, so inside a namespace one would need to prefix every call with a backslash. If you don't prefix with backslash, the interpreter will try both options at runtime: if there's a local function, it'll run, if there isn't, it'll try to find it in global space, and only if it's not there, it'll fail. The only reason this double lookup works is because there's no autoload for functions, and it's the reasons why classes don't have this feature. There was a big discussion back about how to enable them both without severe performance penalty or unintuitive behavior, but none was found. I am myself a big proponent of autoload for functions, as there was never a good reason for excluding them from autoload (except for the artificially introduced one in 5.3). Regards, Stan Vassilev - Original Message - From: Rack-Soft security To: internals@lists.php.net Sent: Friday, October 16, 2009 5:32 PM Subject: [PHP-DEV] Autofunc patch (automatically loading functions like autoload) Hello, I am submitting quite an interesting patch to PHP 5.2.11 and PHP 5.3.0. It is used in production on hundreds of machines without any issues. Basically the patch adds the autofunc function that performs quite in the same way like autofunc, only that it does it for functions. As do you know, if PHP can not find a function it will issue a fatal error. With autofunc you can find the function somewhere and load it. Management of large no OOP projects (or mixed OOP/procedural) is much easier with this. I know that there are workarounds for loading functions, like adding them static to classes, but this is not efficient and involves important changes to code. I have attached some PHP files to test with, you must execute index.php that will load autofunc when the loaded functions can not be found. Let me know if you have any questions regarding the patch. Best regards, Bogdan -- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bitwise Declaration of Flags
Are there any plans to allow bitwise declaration of flags?
Example:
class foo {
const FLAG_1 = 1;
const FLAG_2 = 2;
const FLAG_3 = 4;
private $Flags = self::FLAG_1 | self::FLAG_3
}
Hi,
This is not allowed since declaration values should be resolvable at compile
time. I.e. they can not be an expression, but only a value literal.
While technically expression folding is possible, it's not implemented in
any part of the PHP engine (AFAIK), and I don't think it's planned any time
soon.
To do what you want, initialize the value in the constructor:
class foo {
...
private $flags;
function __construct()
{
$this-flags = self::FLAG_1 | self::FLAG_3;
}
}
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] reference caller object
And really, you're not talking about a caller object but about accessing
variables in scope from the next-highest step in the call stack, which may
or
may not be an object. (Hybrid language, remember. It could be a lambda
function as of PHP 5.3, or global scope, or...) ...
function foo()
{
$caller = get_caller(); // returns standard PHP callback format
}
Results with various caller contexts:
// instance method
array(object $instance, string $methodName)
// static method
array(string $className, string $methodName)
// function
string $functionName
// closure
object $instance (instance of Closure)... or alternatively: array(object
$instance of Closure, string __invoke__)
// global scope
null
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] reference caller object
I, for one, am quite happy that it's fairly complicated and convoluted to get the caller of a method, since it could lead to some seriously incomprehensible code in the hands of someone who don't know what they are doing. Requiring the user to use the backtrace is a clear warning sign, and I think that's a good thing. What is the basis for all this. When someone says a feature is ugly and it leading to seriously incomprehensible code, I'd really like this is explained and supported by evidence somehow, than just thrown around without facts. Most OOP languages expose the caller in some fashion. You'll be hard at work to see in which of them it led to masses of convoluted code. Practical uses for the caller reference include: - implementing private/protected members in __get, __set, __call. Currently they're all public, since PHP knows the caller, but userspace doesn't. Visibility is caller-based. - implementing friend classes. When two classes in a namespace or a logical unit, want to communicate on private matter, the only option is public methods/members. This can lead to a third party calling the code intended for internal use and breaking something somewhere. The only solutions today for properly capsulating such code are ugly slow hacks (including debug_backtrace). Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] error masks
Hi, I think the idea is good intended but will cause troubles of introduced in 5.3. I alone have a bunch of code with custom error handlers that expect to receive all errors at all times. If the feature allows runtime tweaking via ini_set/get, then one could add more plumbing code and workaround, but it still doesn't make it BC to the expected behavior for existing 5.x apps. However I fully agree E_NOTICE should: 1) be reserved for informational may-be-bad-but-usually-is-ok messages 2) not have performance impact when disabled (i.e. production) The problem? Right now important errors that could cause data damage if ignored are E_NOTICE instead of E_WARNING. I'm talking E_NOTICE when you using variables that don't exist, missing constants and so on. All of this should be E_WARNING so my production code can stop and notify me when it's encountered, then I wouldn't mind filtering E_NOTICE. Also Stas, consider why are you trying to treat the symptom of unwanted errors slowing things down. I would bet it's something like the stream APIs emitting errors on 404 response and such. Some API-s really throw notices and warnings where it makes no sense, so people mute them out of necessity (or use handlers). I'd rather fix the API-s instead of pretend it doesn't happen by masking the errors. All of the above would be a job for 6.0 IMHO, 5.x has pulled enough changes under our feet and it's really not fun anymore :P Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting - Request for Discussion
I want to remind everyone that this discussion is inadvertently sabotaging the work/schedule of maintenance 5.3.x point releases, which we actually need, for the 5.3 branch get to a point where it's stable enough to be used in production. So, knowing this can go on forever, it's time to pick which you want first: A) Stable 5.3 with namespaces, closures, late static binding, phar, SPL additions and more (essential brand new functionality, feature complete, only needs bug fixes). B) Strict type casts/hints (shortcut for existing is_*() / cast functionality). Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hinting/casting request for vote
+1 if the object type hint is change to use T_CLASS so we don't break every external package using Object as a base class. http://www.google.com/codesearch?as_q=class\s%2BobjectbtnG=Search+Codehl=enas_lang=phpas_license_restrict=ias_license=as_package=as_filename=as_case= Greg Or this can wait until 6.0, when (as I hear) we'll have case-sensitive class names, so Object/object, Int/int won't cause collisions. I'm really puzzled why a non-essential, and for the past months (years?) controversial and always rejected feature such as strict type hints, has everyone turning 180 degrees and putting it in a minor release in the course of a week. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] weak and strict type checking RFC
I can't see the difference between your proposal and the conclusion I
reached yesterday?
(which was that there is a near consensus around strict checks by
default, with casts allowed with some syntax).
Well to me it Sounded like you wanted to Rely on Standard Type juggling
and what i am proposing is more strict than that. More over i am Not
convinced that strict should Be the Default.
Regards,
Lukas
Just wanted to note the weak string check is the same as the strict one in
the RFC since it appears to be incomplete. It should encompass any type that
can cast to a string. That includes any scalar, and also objects with
__toString method.
Also if this will be introduced, it needs to account for mixed type
arguments, such as null/bool/int or null/numeric etc. The RFC doesn't
mention null at all leaving me to assume null is always allowed, no matter
what.
I'm a supporter of strict typing for languages in general, however, in *PHP*
in particular, strict checks don't make sense to me, given its current
behavior.
This is a language where summing up an integer and a string can result in a
float. API authors will start assuming strictness from their clients that is
hard to achieve, and in the end result in peppering function/method calls
with explicit type casting on each argument. We do not want that, I suppose.
There is one type of check that can be added right now, however, while this
discussion continues:
function add_user(scalar name, scalar phone_number, scalar age) {}
I think we can all agree, if we can check for a class and array, then
checking for a scalar is a natural constraint. It's both strict and weak at
the same time since it's generic enough not to need that separation. Scalar
here is defined by the same rules as is_scalar(), but also allows null as a
passed value to be consistent with the other check types.
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Test for edge cases with __get and property access flags
3. When the caller tries to retrieve $object-foo, and foo is a private/protected member the caller has no access to, instead of an error, __get is called. I'm not very sure the current behavior on item 3 is the best one (maybe error should be thrown regardless?), but freezing on either would be better than leaving it undefined :) I always thought that this is the supposed behaviour. I believe I even relied on it in one of my projects Hi, If the community wants it like it is, then I'm just fine with that: as long as the test is committed, so that it doesn't change overnight. Any volunteers :)? Regards, Stan Vassilev
Re: [PHP-DEV] Is there a technical reason ?= considered a short tag?
Hi,
Plain ? has an additional problem of affecting the ability to include XML
files from PHP source code.
readfile('file.xml');
From what I know, in the future versions of PHP short tags are going to be
disabled by default. Considering the conflicts with XML syntax, that's
understandable.
// no conflict
?='?xml version=1.0?'?
// conflict with full PHP tags
?php echo '?' ?
// conflict with full PHP tags
?php $a = $b; /* ? */ ?
I think these four examples should render any argument containing XML and
PHP in the same sentence invalid.
My suggestion is, follow your own notes: Leave short tags alone - never
talk about it again (http://wiki.php.net/summits/pdmnotesmay09).
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] NaN still broken on Windows builds?
Hi, Can someone please point me to a Win32 build which has a working NaN? The last few releases on php.net all share the same problems, which are leading to real-world bugs in userland code: var_dump(NAN); // float(0), should be float(NAN) $realNaN = sqrt(-1); var_dump($realNaN); // float(NAN) var_dump($realNaN == $realNaN); // true, should be false, NaN should never match NaN Regards, Stan Vassilev
Re: [PHP-DEV] NaN still broken on Windows builds?
hi, Try VC9 snapshots from http://windows.php.net please. Cheers, -- Pierre Hi, Thanks for your pointed, though I couldn't find VC9 builds for any stable release (5.2.x) of PHP? I'll check with 5.3.x a bit later, but what is the recommendation for those of us who have to deploy PHP on Windows today? Go with the RC of 5.3? Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Grafts, Traits, horizontal reuse
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 similar to what we have with inheritance and properties defined by a superclass. If a property is not jet defined, I would expect it to be created in the most inner scope, like local variables. On the other hand, I also would expect, as in inheritance, properties to be found defined by super classes, or the class which defines the composition. But this only my intuitive solution, so this could of course be specified different. Best regards Stefan Hi, I see this in a much simpler fashion. Treat traits as a preprocessor step semantically. Internally, trait methods on multiple classes may point to the same method to save resources, but in my opinion there's no need to complicate matter by introducing new resolution rules, scopes, and so on. The way I see it: 1) Property/Method name conflicts on trait/class, within the class including the trait raises Fatal Error. 2) Extending classes can override the property/method, unless it's a final method, just like as if they override normal parent class property/method. 3) There's a single space for a class property and its trait properties, so access works as if it was all class properties. Feedback? Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Grafts, Traits, horizontal reuse
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 property
names in your state. But then you will break other traits. Even worth,
this trait is defined in a widely used framework and your breaking other
peoples code just by changing implementation details which should not
even be visible to your users.
I do not think that this simple model is practicable. Unfortunately, it
is implied by the current state-less proposal, if we do not forbid any
access to properties inside of trait methods (which sounds like a stupid
idea to me). :(
Regards
Stefan
Hi,
Since the expectancy of a trait is it'll be used in many other classes
horizontally, I wouldn't think people will start taking generic names in
traits as they do in normal classes.
I'd personally expect this naming convention more likely:
trait Counter { protected $counterValue; }
trait Observable { protected $observableListeners; }
And so on. The benefit is it's easy to implement, understand, and use.
However if this is not acceptable to many, and we could live with the
complication of it, the best idea for trait property access I suppose would
be this:
trait Observable {
protected $listeners;
}
class Any {
use Observable;
function accessTraitProperty() {
var_dump($this-Observable-listeners);
}
}
Hence namespacing trait state into an automatically created object of the
same name, and we're done.
On the other said, a all traits could have an automatic property owner,
which gives it access to the class state/properties.
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Is it true that short_open_tag is deprecated in PHP 6?
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 the above example, XML parsers would do this: Processing directive: ?php echo ? Text node: ; ? Parse error: As you see, it's a much simpler world when we realize PHP was never supposed to be XML in the first place. However it was supposed to be a preprocessing templating engine, and so we need to keep it optimized for that. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] User namespaces and PHP classes
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 namespaces, however I've been a bit stuck and
*surprised* that the only way to use a PHP class (like Iterators, PDO,
etc) is to call them from the global scope, this means: adding the \
at the beginning at the class.
My short question is: is it the only possible way? That means that I
need to be very careful when invoking PHP classes, like PDO? Currently
when I do:
$pdo = new PDO(..);
throws an error if I use it from one of my namespaced-classes, the error
is:
Fatal error: Class 'MyNameSpace\PDO' not found in /foo/bar/foome.php
throws an error, since spl_autoload can't find the 'MyNameSpace\PDO'
class. And yes I know I could create a class that extends from it, but
I don't think that's the best idea, just imagine the number of classes
I just need to create to cover the PHP classes I plan to use.
So, are there other workarounds for this? Like an autoload function
for PHP objects created inside a non-global scope (MyNameSpace)? I was
reading a thread about namespaces of last year and someone suggested
something like:
if (($p = strrpos($class, '\\')) !== false) {
$name = substr($class, $p+1);
if (class_exists(\\$name)) {
spl_autoload(\\$name);
// or use \\$name;
return;
}
}
However that wont work cause: 1) one can't use use at the middle of
a PHP files, it needs to be used at the beginning afaik, 2)
spl_autoload will definetly find the class I'm passing (supposing PDO)
but it's useless since what is expected by PHP is a MyNameSpace\PDO
class. Probably I could use Reflection but I'm not sure if that's the
best idea...
Any other plans to use PHP objects (SPL, PDO, etc) inside non-global
namespaces? Maybe a PHP namespace that spl_autoload could catch,
like:
use PHP;
use PHP\SPL;
use PHP\ArrayObject;
(this idea was given in a previous thread :-))
.. or perhaps having something like spl_namespace_alias, when someone
can use inside their autoload functions:
spl_namespace_alias('/PDO', $classname); // where $classname is the
parameter received by the __autoload functions.
I don't have any problems to prepend the \ but I think PHP should
catch that stuff automatically as it does with constants and
functions, no? Find a bit annoying to write the \ to PHP classes I
want to use imho.
Thanks!
--
Pablo Fischer (pablo [arroba/at] pablo.com.mx)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Enhanced __CLASS__ constant
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 to the function. In PHP you can have constant/function/class of the same name and the only way to tell them apart is context. It needs to be either a magic constant or a language construct. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Enhanced __CLASS__ constant
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)
{
return new $class;
}
$obj = factory('MyClass'); // returns object MyClass
$obj = factory(MyClass::__CLASS__); // returns again object MyClass, code
is little bit more selfexplaining
Hi,
I've discovered this omission earlier and I have proposed two solutions:
1) $x = nameof Foo;
-or-
2) $x = Foo::__NAME__; // very similar to yours, Foo::__CLASS__ may even be
better
Since passing identifier references as strings is relatively pervasive in a
lot of the PHP code out there, I hope this is resolved for 5.3, before we
figure out we need it the hard way after we've littered our code with tons
of manually written out explicit references.
One problem with your proposal / my second proposal is, it works for
classes, but doesn't address namespaced 1) functions 2) constants.
A new keyword would address this, but then, who wants a new keyword,
right...
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New function proposal: spl_object_id
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 unique identifier for the object, by padding each pointer to 16 bytes and joining them together. 3) The resulting byte sequence is XOR-red with the session mask so the object id/handler are not retrievable in userland, and the resulting sequence/string is returned. This is better than spl_object_hash for two reasons: 1) no printf of numbers, no expensive md5 hashing, no hex conversion. 2) no possible collisions Drawbacks: 1) might generate some non-printable chars after xor (but this wouldn't matter for operation). The idea above can be tweaked to solve this. The 32-bit string format is to preserve compatibility with spl_object_hash, so it can replace it, instead of introducing a new similar function. I've had no time to look further into this, but Marcus seems to like the basic idea, so feel welcome... Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tip for 5.3: exceptions in __toString and __autoload
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 throw. I leave up to you how appropriate that is. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Undefined constants producing E_NOTICE
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 flexible language, but for me it's a bit thick. Just how is PHP supposed to know that some random string is intended to be anything else? By the quotes :). Undefined variable $foo doesn't fall back to string 'foo' it falls back to null. It's a sane strategy for constants as well. I have no information how people rely on this, I know the reason for this fallback is bad syntax like: echo $hi[there]; I'd fix it in 6.0 though. Regards, Stan Vassiev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode()
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, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode()
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(hello world); ...to this: echo 'var foo = '.substr(json_encode(array(hi world)), 1, -1); A flag that defaults to false would be just as explicit and educational, and more efficient, than forcing hacks on us like the above one. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Removing basic types from our JSON parser
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
json_encode() is the natural equivalent of var_export(.., true) for PHP
literals.
Since it may not match the RFC apparently, I suggest a flag as some other
people said:
function json_encode($var, $allowScalar = false) {}
This way we gain best of both worlds without disrupting either specs nor
existing workflows.
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] array_key_exists BC break
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 6.0) and come up with a set of interfaces for objects that allow them to more sensibly work with functions. We already have set of interfaces. They aren't just used consistently. And that's a bug. We shouldn't let BC to prevent us from fixing bugs. Especially BC with things that were never documented to work at the first place and are working in half of functions and don't work in others without any logical order. 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. Full rethinking of this and consistently respecting the Array/Iterator interfaces would be great and needed for 6.0, though. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Proposal for nameof functionality without new keyword...
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 could work just the same
internally, but without a new keyword:
namespace Foo\Bar;
class Baz {}
$name = Baz::__NAME__; // 'Foo\Bar\Baz'
[IMPORTANT] Baz::__NAME__ should be replaced at parse time (like the magic
constants), so that class Baz is not autoloaded (we don't need it autoloaded
just for the name).
Why is this good:
1) Would cover our basic needs for this feature when passing class names around
for factories, callbacks, strategies, handlers and so on.
2) Doesn't introduce a new keyword, and apparently class constant __NAME__ is
very rarely used by anyone, if at all (Google Code Search shows 0 hits on PHP
code).
3) It's intuitive as it follows the conventions established by the other magic
constants, and serves a very similar purpose.
Regards,
Stan Vassilev
Re: [PHP-DEV] array_key_exists BC break
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 BC break, I guess we wouldn't be having this discussion. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
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/display/ZFPROP/Naming+conventions+for+2.0+-+Matthew+Ratzloff). In namespaced code there cannot be class Interface in namespace Zend\Acl\Role. There must be class RoleInterface in Zend\Acl namespace. Similary class Zend_Acl become Acl in Zend\Acl namespace. So look at the code with namespace-eyes. Classes Zend_Acl, Zend_Acl_Resource_Interface, Zend_Acl_Role_Interface... will exist in one namespace. I've checked that wiki page before, and I'm following with interest how they end up naming those, but that changes nothing. Today, Zend_Acl uses Zend_Acl_Resource_Interface. Tommorow, Zend\Acl uses Zend\Acl\ResourceInterface (or similar). The fact is, PHP frameworks and especially Zend use plenty of factories and facade classes, which by definition reach into inner-more classes and provide simplified paradigm to the outside world. The Interface and Exception classes won't stay like this, but they'll still be inside a subnamespace. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
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 to unreadable code.
It is probably best to simply require a fully qualified name where it is
intended. Thus
1) require leading \ in use statements
2) allow namespace\blah in use statements, as this is a valid fully
qualified name.
?php
namespace my\ns;
// this is a better way to do the suggested use bar as A;
use namespace\bar as A;
use \bar as B;
class mine extends \my\parentclass {}
?
Greg, I can't spot where does your example differ from what I and Marcin
suggested? Please explain.
As for the leading \ for fully qualified identifiers, well it's a necessary
evil. As you said yourself PHP is PHP, and we have unique constraints to
meet, we have no scopes, we have no compile time packaging of the resources,
and since we don't have meta files describing the namespace resources (wink
wink...), we should stick to a single-rule no-ambiguity system.
For me the only way to make it clear to both humans and parsers alike is the
filepath semantics, in all places, including use. It's not perfect, there's
no completely problem-free solution, but prepend \ for absolute path is
able to become muscle memory, while other mixed solutions I've seen are more
confusing and require more thinking: wait in this context what was what?.
And there's one more pain point which I posted earlier on the list about,
but now as I prepare my framework for 5.3 namespaces, I *really* feel the
pain in practice: the inability to pass a class/function name without
specifying it fully as a string.
My suggestion was: use foo\bar\baz as alias;$name = nameof alias; //
$name == 'foo\bar\baz'
But this introduces a new keyword: nameof, which could clash with
function/class/constant nameof in existing source code. I could suggest
simply not having nameof and having direct assignment assign the class
name, but then we clash with constants which have the same name as the
class. So that's not doable either.
But it's definitely in-your-face issue while using namespaced code.
Regards, Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
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 the above is 3 extra lines of code - total - per NS. If this sounds good, I will add an example to the new docs yet-to-be-committed. Greg I'm aware of __NAMESPACE__, and your example is kinda creative, but I think that's a touch too much acrobatics for something that's a basic need :P Consider callbacks, factories, strategies, drivers, adapters, proxies and so on which typically may and do pass class/function names around. I don't know. I'd rather endure the pain and write the string in full every single time than cause extra confusion in my source code :) Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
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 nested namespaces extends classes in less nested namespaces. If you don't believe, look in framework sources :-) A quick study on the Zend Framework source reveals most top-level classes requiring, using, and accepting as arguments more inner classes and interfaces in the relevant namespace: Zend_Acl == Zend_Acl_Resource_Interface, Zend_Acl_Role_Interface, Zend_Acl_Role_Registry, Zend_Acl_Assert_Registry... Zend_Auth == Zend_Auth_Storage_Session, Zend_Auth_Storage_Interface, Zend_Auth_Adapter_Interface... Zend_Cache == Zend_Cache_Core, Zend_Cache_Frontend, Zend_Cache_Backend (including all specific frontend/backend adapters). Zend_Db == it's a factory for all classes like: Zend_Db_Adapter_* Zend_Pdf == Zend_Pdf_Page, Zend_Pdf_Cmap, Zend_Pdf_Font, Zend_Pdf_Style, Zend_Pdf_Parser, Zend_Pdf_Trailer, Zend_Pdf_Color etc. So, I really suggest we leave that argument out. Regard, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] register globals - PHP6 still replaces . in variables from outside
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 to occur for the GPC superglobals. Isn't that fixed already? I could have sworn seeing a commit from Ilia that allowed dots in the superglobals (duplicating the key, one with dot and one with underscore) some months ago...? -Hannes It's not fixed, if it was, it was not checked in. In the 5.3 nightly, foo.php?a.b.c = 10 shows up as $_GET['a_b_c'] in PHP Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] register globals - PHP6 still replaces . in variables from outside
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, it can do it there only for that import. I.e. $_GET['foo.bar'] is just fine, and importing 'foo.bar' with the above function could still produce $foo_bar only for that specific edge case. It's just a premature replacement too early the stack. Regards, Stan Vassilev. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP
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 subclassing.
This feature is identical to the C# .NET Extension methods. The best use
of it is for selectively extending the primitive type classes on the fly
with methods you need (string, int, array, etc.).
The irony in this is, in PHP the primitive types are not OOP capable, so
with this in mind I wonder how much this functionality would serve to make
the life of people easier, and how much of it will be just the rope they
need to hang themselves. The concept of categories and extensions is not as
popular to the average developer as say classes and interfaces.
Also we can't overload use for this as use specifically only imports
symbol names, not actual code, into the environment. It doesn't have the
knowledge of whether something is a namespace, or a class, or a category, so
to know how to trigger autoload.
Regards, Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
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\Control), and it is common have class Company\Software\Web\Forms\Control extending Company\Software\Base. So in real world it means that nearly every usage of partially qualified indentifiers (Sub\Object) have to be written with preceding backslash. David Grudl Can you please point us to an example describing this best practice? Aside from this, the problem is: scopes. In other languages we don't have preceding separators and those conflicts hence don't exist, since with scopes, if a name doesn't exist in the local scope, it's automatically bubbled up until it goes right back to the global scope. In PHP nothing bubbles, hence this doesn't work. We have just one exception to this, with global functions in local space which bubble up to global even without the prefix (which I believe will come to bite us later on). However there's still one more issue, use clauses only understand full symbol names, which causes yet another inconsistency: namespace foo; use bar\baz as bar_baz; $a = new bar\baz(); //instantiates class with absolute path foo\bar\baz $b = new bar_baz(); //instantiates class absolute path bar\baz In fact, use doesn't even know what the prefix would mean: use \bar\baz; // parse error So it has to be decided which way the system goes to avoid confusion and bugs IMO. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An optimization idea
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 really big change so might be worth adding if it's going to give a few applications out there a gain, but I couldn't see doing this everywhere of course. -shire Hi, Something that could give arrays a boost would be to: - pool all string literals in each file - give each stringl iteral an id (unique in the loaded environment) - bind early all array access with string literals (a common occurence), so they don't need to be resolved with a hashmap lookup, but rather, a direct stirng literal id lookup. The benefit of this approach are: - There's no need to generate a hashmap in the first place - String literal id-s are unique integers and have no conflicts, so no need to do conflict resolution. That would help with objects as well. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace resolution rules has been changed?
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. We have just one exception to this, with global functions in local space which bubble up to global even without the prefix (which I believe will come to bite us later on). * *I understand but I think it doesn't matter. PHP has not qualified identifiers yet, so any qualified identifier can be understand as and only as fully qualified identifier (ie absolute path), like former namespace implementation does, and not like relative path. David Grudl The Zend Framework is chock full of classes reaching for inner classes and providing them to the world in the form of Adapters, Factories, Drivers, etc. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An optimization idea
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 where static though, as you're mapping a constant string to the contents of the hash (or did I misunderstand and you'd be mapping string const. values to hash IDs?). My point is, replacing this process: $a['foo'] or $a-foo - compute hash of 'foo' - find item for hash 'foo' - many items? - resolve conflict - return item With this process: $a[% string_literal_id_5 %] - lookup item key 5 for array - return item Notice we skipped hash generation, and conflict resolution altogether. We only have the lookup for the integer id. If some additional work is done, even this lookup can be eliminated and make this an O(1) process. If instead the coder used variable: $a[$bar] or $a-$foo (var array lookup and var var object lookup), then this optimization can't kick in, and the existing algorithm will be used. However static access is the predominant usage, especially for objects, but also for arrays, so this should have significant impact. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An optimization idea
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 some metrics on the needed extra CPU ticks for determining if an array (or array sub-element) is static or dynamic under the scheme, as well as the extra memory for storing an (many?) extra value(s). That's not exactly what I had in mind: I don't split whole arrays into static and dynamic (this could be an entirely orthogonal optimization to what I'm saying, similar to what Chrome's V8 engine does currently). We just know a lot more at compile time about member lookups that are defined by a string literal: $obj-foo(), $obj-foo and $arr['foo'] as opposed to fully dynamic accesses which we don't know at parse time: $obj-$bar(), $obj-$bar and $arr[$bar] And we can optimize based on that. I've not spent significant time with the PHP source code yet, to be honest, but if no one is willing to look at it, I could start tinkering with it in my free time and post patches if I arrive at anything. Then we can test how it impacts real world code. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call it: allow reserved words in a class or not?
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 those classes are (due to autoloads and conditional require/include constructs). 2) There can't be a method to resolve wildcards, since namespaces currently work 90% at the parse level, before any PHP code has executed. This is required for good performance and simplicity. 3) I have emailed Greg a simple idea for solving this with a INI-like meta namespace file, a simple file we can put in our include path, which describes the resources of a namespace and optionally their location. For example let's say you have namespace My\Name\Space, and inside you have classes Foo, Bar, functions baz and constants ONE, TWO. In one of your include paths, you'll create a file called My.Name.Space.nsmeta and put the following inside: class Foo = path\to\Foo.class.php class Bar = path\to\Bar.class.php function baz = path\to\baz.func.php const ONE = \path\to\constants.php const TWO = \path\to\constants.php This file you can generate from your framework, or even write by hand, as you see it's very simple to write/read, and tokenizes with the existing PHP tokenizer. Since this file will be read at parse time, it has the ability to solve the following problems: 1) zero-performance-impact namespace wildcards (especially with an opcode cache like APC, XCache etc.) 2) faster resource loading (PHP can autoload resources from the location map above without you writing a slow __autoload runtime procedure) 3) you can load on demand now any namespace resources: class, functions, constant, not just classes. Naturally this is not for 5.3 as we all want 5.3 stable and out as soon as possible. But it has the potential to simplify drastically some workflows, especially in large complex frameworks, so if it picks up, maybe 5.4, or 6 or who knows. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Case sensitivity
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 said. Hi, I don't know why case sensitivity as I layed it out, is put in the same group as ideas for removing $ from variables or redoing the PHP primitives, or what have you... Knowing the guts of PHP doesn't protect people from making really bad proposals, as anyone following this list for some time is well aware. Core devs know the PHP engine well, but sometimes have little idea of accepted standards, syntax and common workflows in and outside the PHP community. Also: those truly hilarious joke replies some people keep producing on this list, including to this thread: they're not funny. The idea of OSS forums like this list, isn't to generate easy entertainment for bored programmers. A valid point elsewhere is lost everytime a thread heads this way. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call it: allow reserved words in a class or not?
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 you can still require/include or autoload your file exactly as today. It's an addition, not a replacement. 2) It doesn't limit the dynamic nature of PHP as those files can be generated from a script just as any text file, and will be used for large redistributable libraries, frameworks, which are more static in nature than the application code utilising them. As for the extension, I'll check it out, thanks. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] bracketed namespace declarations
?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 I implemented, if bracketed
namespace declarations exist, global use statements are not allowed, but
must exist within namespace ns {} brackets.
This creates a problem - how do you combine namespaced and unnamespaced
code? To solve this, I introduced the oft-suggested namespace {}
...
Well, here's a cheesy mod of your example:
?php
$f = 10;
function one() {
$f = 20;
}
echo $f; // what is this? 10 ;)
?
I guess it's clear that code below or above a namespace is in the same
global namespace, so use blah\blah will apply ot blah::hi();.
However, we do also need your suggestion: namespace [nothing] { ... } since
one of the major design goals of the {} syntax variation was to allow people
to merge multiple files for deployment. Something which several frameworks
already do.
When we merge two files with use clauses, we need a way to provide blank
namespace scope so the use applies only to the relevant part of the code.
We can't avoid your code example above either, since by default we don't
require every piece of code to be in a namespace. If we allow {} scoping,
it'll be awkward to suddenly require the remaining global code to be put in
an explicit scope too, and people will be confused.
Hence a solution that seems most natural to me, and covers all use cases is
the following (where the scope # tells you where the use declarations
apply):
?php
// global, scope 1
namespace { // global, scope 2 }
// global, scope 1
namespace { // global, scope 3 }
// global, scope 1
namespace foo\bar { // foo\bar, scope 4 }
// global, scope 1
?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] bracketed namespace declarations
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 statements inside the scope after them.
So if I write this:
?php
use A;
use B;
namespace {
use C;
}
?
In the namespace, it's the same as if I wrote use A, B, C in that order
explicitly. Implemented this way, in a future version of PHP we could allow
this typical scenario (which I suspect won't work with this patch?):
?php
use A;
function foo() {
use B; // use A applies implicitly, use B applied only for the scope of
the function
...code...
}
?
Which code above is in fact a sugared version of what is actually happening:
?php
use A;
function foo() { namespace {
use B; // use A applies implicitly, use B applied only for the scope
of the namespace scope
...code...
} }
?
The above significantly helps with larger function/class libraries in a
single file, as you can make your use statements more local (typically you
will use certain classes globally, and most locally in a function/method),
and is supported by most modern languages that handle namespaces.
Regards, Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] bracketed namespace declarations
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. However Greg's proposal is in fact a strict subset of scopes, which could be extended in the future in a backcompat nature. It also covers all use cases by the community, so I'm +1, if anyone is counting that is. Sorry for the noise :) Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call it: allow reserved words in a class or not?
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 keyword. Reverting this or making it context sensitive is not trivial by any means. Still though: it IS possible, you'll find plenty of examples of context-specific keywords in other languages (including C# which was quoted here). Oh and btw, greg, in your example: you should print 1. There's one trivial solution: make the keywords and class names case-sensitive. Then classes If, Array, Interface will never class with the all-lowercase keywords. I have to say, we sorely do need consistency on that front as well, and since vars are already case sensitive, making it all case sensitive is one way to go forward. Why is this a problem at all? Well as people said, in .NET words like array are not a reserrved word. Even more, if I have Foo.Utils.FooUtils, that's some redundancy I can easily avoid in .NET by using Foo.Utils.*. In PHP, we can't do star-imports since the parser doesn't know what's there to import at runtime. So we can't easily avoid the redundancy, unless we manually import the classes we want to use, one by one. So that's one more hassle which make redundant names a pain. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Case sensitivity
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 than I thought, really out of the question for 5.x. Though I still think it's something we should consider for 6.0 as it's something we need to fix in the long term (and 6.0 already has breaks, such as strings used in binary operations need to be changed to binary strings). I can provide a short PHP script which can automatically fix the case of internal classes and keywords like array() in most source code out there. We can test such automated porting scripts on samples collected from PEAR, Google Code and projects like Drupal, Joomla etc. to reduce side effects. Regards, Stan Vassilev
Re: [PHP-DEV] Call it: allow reserved words in a class or not?
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 have code like this:
if($object instanceof Interface) { // wtf am I checking here?
...
As for how exactly that descriptive name should look - I guess each
framework's developers that plan to support namespaces think about it hard
right now. I know ZF developers do :)
Hi,
Fully agreed. Though since we (PHP users) will all be using namespaces
together, it makes much more sense that we have a paradigm, recommendation
for namespace usage that all frameworks will follow.
Maybe the ZF, Agavi, CI, CakePHP etc. authors should get together and craft
a single recommendation list for people to use.
It's not just a matter of consistency, it's a matter of makming the language
work well with the recommended scenario and use patterns of namespaces.
Two things are obvious:
1) What worked with underscores won't work with namespaces.
2) What scenario above with instanceof Interface isn't very likely. Why?
Well imagine you want to use 5 classes in namespace foo\bar, called A, B, C,
D, E (ex. foo\bar\A). In most any language with packaging system, to flatten
the space you simply do this:
use foo\bar\*;
$a = new A();
$b = new B();
...
In PHP, due to lack of packaging system and knowledge of the user resources
at parse time, instead we're painfully explicit:
use foo\bar\A;
use foo\bar\B;
use foo\bar\C;
use foo\bar\D;
use foo\bar\E;
$a = new A();
$b = new B();
Which makes this usage pattern with aliases much more likely to see:
use foo\bar as fb;
$a = new fb\A();
$b = new fb\B();
So your example above would rather be:
use Zend\Validate as ZV;
... instanceof ZV\Interface;
And this is why it's worth it to arrive at a single list of recommendations
for namespace usage, and see what works there and what might not work, and
tweak the language for it.
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] array_key_exists BC break
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 for any class implementing the relevant SPL interfaces, and that's not just ArrayObject. It may be seen as just one class but actually all of the transparent iterator implementations (for iterating SQL, XML, or whatever data you have) hinge on those interfaces and that class to work as a normal array with the array functions. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace Resolution
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 internal-only functions,
since you still don't know what *namespaced user functions* will be loaded
at runtime with overlapping names.
I.e. :
FILE aaa.php
namespace Foo;
function strpos() {}
FILE bbb.php
namespace Foo;
if (runtime condition) include 'aaa.php';
strpos(); // parse-time resolution will ignore the loaded Foo\strpos() and
resolve to internal anyway.
So, no performance benefit whatsoever, any fallback requires *runtime*
resolution.
Furthermore, don't you guys see that coding IDE-s will have issues with code
hinting those functions. Is it the namespaced function or the global one?
The IDE can't know, an IDE can't resolve vague runtime conditional includes.
Eclipse PDT works great right now, with autoload and all, since it a given
functionc/class identifier can be either internal, or in the project, and
each has a unique name. With the magical fallbacks, all this goes to hell.
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace Resolution
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 it's just too much hassle to bother with two different paradigms. Case in point: do you know a major reason why people keep using static methods to fake functions? It's not as much to namespace it. I mean Foo::bar() or Foo_bar(), who cares? It's all the same. But the big difference is, I don't have to explicitly load the function library if it's a static class. Classes have autoload, functions mysteriously don't. Hence, even I have abandoned using functions today and use fugly static method hacks. It's less hassle to do it wrong right now, than do it right. So I do it wrong. Namespaces won't change any of this, since I still can't autoload my function library. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Namespace Resolution
- 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 this stuff). We should know better, and in fact we do know better since all those resolution order discussions won't be happening, trying to find a perfect intersection between what we know works, and what the (less informed) general public thinks it wants. And the reality is that the whole hatred to the mandatory leading slash is overblown beyond any proportions: 1) Newcomers to PHP won't be writing namespaced code. So their WON'T be confused. 2) They'll eventually use libraries with namespaces, in which case they're STILL not affected. 3) They'll be pasting code samples from the manual and forums in a blank file in global space, so they STILL won't be affected. 4) One day, their projects will start growing a lot, their experience with it, and they'll have the basic clue to prefix their global classes/functions when inside a namespace. So they STILL won't be affected. What do we do instead? We discuss how to optimize the non-existing scenario of noobs being irritated or confused when hammering global identifiers in a namespace, while producing unimanginable pain to every PHP coder out there from all ranges of experience and knowledge, with magical fallbacks and autoload mysteries. I suggest we all clear our minds a little and give a serious thought to all this again. If you just say no fallbacks, some people will bitch 2-3 days, then try it, and see that it was not all that bad after all. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Call it: allow reserved words in a class or not?
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\Interface but rather: T_STRING Zend T_NS_SEPARATOR \ T_STRING Validate T_NS_SEPARATOR \ T_INTERFACE -- parse error I understand it's not trivial to fix this, but I wanted a clarification: is there a plan to do something about it, or it'll remain an invalid syntax by the time of release of 5.3. Regards, Stan Vassilev
Re: [PHP-DEV] namespace separator and whining
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 almost a week, apologies to anyone who is wondering why I haven't replied to your message, I probably didn't get it. Hi, This is starting to bother me, to be honest. Every time we go back to this fallback to internal X I give examples and real world scenarios that will become broken in namespaces which work today outside a namespace. I get nods, agreement, people start talking that we should either fallback to *all global* functions, or *not fallback at all* so that the behavior is predictable for PHP users. ... And in few days we all forget problem and start talking about falling back to *internal* again. People do implement fallbacks for internal functionality as userspace functions/classes on their own, TODAY. In namespace, if you don't treat internal/user equally in resolution, things will work outside a namespace, and break inside it. This will be confusing to people, who especially use fallbacks to transparently implement missing PECL extensions or functionality, or augment the internal functions of PHP with other, for ex. user implemented ifsetor(), array_*() or str*() functions. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Proposal for new construct: nameof
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 autoload.. hopefully one day..):
F::loadFunc('Foo_Bar_Baz');
echo Foo_Bar_Baz();
Tommorow I could attempt to do:
use Foo\Bar as B;
F::loadFunc('B\Baz'); -- failure, strings are not resolved agains the use
statements
echo B\Baz();
so it becomes:
use Foo\Bar as B;
F::loadFunc('Foo\Bar\Baz'); -- works, but negates some of the use for use...
echo B\Baz();
I suggest we introduce a new construct which will return a string when passed
any identifier to resolve against the current file's use clauses:
nameof Symbol\Name;
With this identifier, the above example can be normalized to the following
code:
use Foo\Bar as B;
F::loadFunc(nameof B\Baz); -- will send 'Foo\Bar\Baz' as the argument
echo B\Baz();
NOTE: As a side effect this means less direct writing of string function/class
names, and less complaints about \ being the escape characters.
Regards,
Stan Vassilev
Re: [PHP-DEV] Clarifying the resolution rules
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 Foo; new Bar(); 1) Try to find class Foo\Bar. 2) Try to autoload class Foo\Bar. 3) Try to fallback to global *internal or user* class Bar + E_NOTICE; namespace Foo; $result = bar(); 1) Try to find function Foo\bar(). 2) Try to fallback to global *internal or user* function bar(). They key change is: not to make difference between internal and user global functions, just fall back to global ones, so that there's no additional confusion among drop-in replacements, user resources, and internal resources. Send feedback. Thanks. Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding pecl/http to core
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/unsub.php
Re: [PHP-DEV] Re: Clarifying the resolution rules
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 end? If your not careful you end up with c# or java where doing anything requires going through hundreds of classes and packages. Please let's avoid bad comparisons :P We need to be very well aware that the concept of namespace in its simple, clear, understandable form, represents: 1) no globals, everything in the namespace is in the namespace, including vars, constants, functions, classes and nested namespaces. 2) to refer to a global namespace, there's no magical fallback to another namespace (the global one), you need to use it specify it in your call explicitly. The very idea of namespaces is, that other names don't leak into your namespace. 3) we'll likely see in a future edition of PHP (5.4? 5.5? 6.0?) that many currently global functions with pseudo namespaces like array_*(), string_*() etc will gain concurrent aliases in a namespace: \array\*() \string\*() since if we keep adding stuff in globals, then why introduce namespaces at all? 4) any fallback, fudge, name leak, partial implementation represents complication of the namespace concept, it's a compromise that makes namespaces harder to implement, understand and use, but easier in the short term for porting code and the global functions all over the place issue PHP is so often criticised for. So, while I remain flexible on the scale of the options, I really wish people don't just think in the short term, since short term solutions are what caused the necessity to use \ instead of :: in the first place. When you're cornered by your ill past decisions, you either break BC (which we don't want to do), or add more WTF-s to the language as it evolves. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha2 scheduled
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 the ultimate PHP configuration ... Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] array_key_exists BC break
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 traversable objects to our views, mixed with real arrays, is already common (I do it too). Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Clarifying the resolution rules
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 excessive autoload triggering, or alternatively allows internal classes to override unloaded but to-be-autoloaded namespaced classes. Then why is it still under consideration? 2) Making the backslash optional for internal functions means popular drop-in replacements for internal functions and extensions in global space, which work today, will break in a namespace, examples: libcurlemu. Also check any comments on PECL functions on php.net, and you'll see a myriad of drop-in replacements people use today. Also, for those who want to automatically convert their internal functions to backslash prefix for use in namespaces, you can use this quick snippet I wrote (works in 5.2.x too): http://pastebin.com/f13125acd I don't make guarantees it's perfect, but it can be improved and given to people as a porting aid. Opinions about how disruptive a mandatory backslash for global symbols *in namespaces* would be, are welcome. Keep in mind that making the backslash optional will lead to code breakage (such as for above drop-in replacements, class autoloading etc.) and slower performance (runtime resolution of function calls). Think of it as file paths. When you're inside a directory you need to prefix your path with / (eg \) to refer to the root, but you don't need to do that when you're in the root directory. Regards, Stan Vassilev
Re: [PHP-DEV] namespace separator and whining
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 resolved instantly from a hashmap lookup, i.e. my cache. I don't have ArrayObject in my cache, so if my autoloader is asked to find ArrayObject.class.php, it'll start crawling huge PHP libraries of code, *every single request*, only to fail in the end and fallback to internal class. Is this negligible performance hit? Actually (re)scanning my full library takes few seconds of heavy disk grinding. Make your own conclusions. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] /endnamespacediscussion
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 foo[tab]bar, I just wanted to throw it
out there, although I don't think it's a great idea. We have only few escape
combinations in string literals which can also be in a valid identifier:
\t \n \r
There are also some which aren't a problem since they can't be in a valid
identifier:
\x.. \0 \\ \$ \' \ \{..} etc.
So the problem is with exactly three combos: \t, \n and \r. In the few
places PHP takes class/function identifiers as strings, TAB, CR and LF could
be interpolated back into the two characters they express, since TAB, CR and
LF aren't valid on their own in identifiers, so ambiguity is not possible.
Those places of the top of my mind are: new $class(), $class::property,
call_user_*(), _autoload, and all other places accepting callbacks.
This would mean both of those will work correctly: foo\\tbar and
foo\tbar when used as an identifier.
Think of it as a plan B in case people cause a big fuss about it (which I
think they won't: think about escaping of windows file paths and escaping in
regex pattern, we're doing just fine there).
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Destructor Order
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, I have no idea, I haven't thought of a good syntax.
It
should be an integer for what level though.
Then when the script ends, the engine starts with the highest most level
of
destruction. It continues down until everything has been destructed.
With
the last most level being objects with unspecified levels.
Note: Each level can have more than one class.
Example destruction order:
3 = database records (ActiveRecord or such)
2 = database connection object
1 = framework objects
0 = objects with unspecified level
Hi,
This would likely (and possibly rightfully) be frowned upon, but according
to the current codebase, if the destructor creates a new reference outside
to the destroyed object while it runs, the object won't be garbage collected
(a safe call is used that checks for any remaining references after the
destructor is called).
This allows you to implement destruction priorities yourself easily by using
a central DestructManager:
function __destruct()
{
global $destructManager;
$this-addObject($this, $priority);
}
function __real_destruct()
{
}
Those will be collected in the destruction manager and when at shutdown, on
the manager's own destructor you just need to sort the collection by
priority and call the real destructor.
Now, this will work fine, but has this downside that all objects will be
held in the memory until script shutdown, so it's naturally not good for
long running processes.
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Destructor Order
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
Re: [PHP-DEV] [PATCH] Allow unsetting headers previously set usingheader()
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('*') or simply header_remove() /no param/ removes
all headers (including the one PHP sets by default), so we can start with a
clear state.
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace issues
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 expressions. Anyone complained
about the location of backslashes in there? No.
2) Where the backslash is, is also where the {} and [] are on those
kayboards, as some people already said.
3) Backslash is ugly -- are you honest? Which is uglier::::Foo()
::Foo() or \Foo(); The last one at least has intuitive meaning (like file
paths: absolute path). Face it that you'll be typing either one of the above
three a *lot*, and pick one that makes sense visually and for newcomers
alike. I think that's the backslash.
4) But we want the same operator. Well? I want a pony, the fact is
however, the other languages have the design to afford the same separator
for namespaces, static methods and members. Shoehorning this in PHP while
maintaing BC will create such nightmares in big projects with ambigous
identifiers, autoload performance issues, that you'd wish you go back and
change the damn namespace operator to just about *anything* but ::.
I wish the people who have a clear opinion of the above voice their opinion.
For those who aren't quite sure what the issues in point 4 are, please just
stay low and follow the list until you do.
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
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 namespace design. I believe internal classes should be explicitly disambiguated, even if it looks ugly, so the autoloader can occur at the right place in the chain. Anything else would make namespace+autoload an unusable combination. Greg, good work on the proposals but I think there's some confusion, even among core devs about the nitty gritty details on some of the proposals. I'd be nice if we can add allowed / proper and not allowed / wrong examples and such to the RFC-s so it's more obvious what impact each proposal has on code. As for ::: vs ::, those are virtually not distinguishable in a lot of code, so if that's to go, pick another syntax. : is fine, \ is fine, .. is fine. Regards, Stan Vassilev. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
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 starting using it and not another week of discussing separators on internals. And people can't start using it if it's not only not released but there are developers rooting for it to be removed. There is a way to make both: have people use them, and not commit to BC or changes in 5.4 or a future release. Introduce E_EXPERIMENTAL as part of E_ALL. Make it the counterpart of E_STRICT. E_STRICT is reserved for deprecated features, and E_EXPERIMENTAL would complete this idea by letting us push experimental features such as namespaces (and any other extensions marked as EXPERIMENTAL in the manual) and have people play with them, so the core devs can get the feedback they need and improve or remove the feature in a future release. Have namespace related features throw E_EXPERIMENTAL warnings to people so they are aware this feature may not be present in a future release, or present but in another form. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues betweenfunction/staticmethod class constant/ns constant
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 issues betweenfunction/staticmethod class constant/ns constant Maybe just use . as namespace separator. MyNameSpace.SomeClass::_getInstance()-SomeDBClass-Query(); That will eliminate all resolution problems, it isn't used for anything than string concatenation, and it's one symbol. It's 100% better than \ and I think it would be better than ::: or and so on. A point against \ is that it has special meaning in every programming language as escape character, so it is 100% bad to use it.
Re: [PHP-DEV] solving the namespace conflict issues betweenfunction/staticmethod class constant/ns constant
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 forgetting constants:
define('MyNameSpace', 'Hi ');
class SomeClass { function world() { return 'world'; }}
MyNameSpace.SomeClass::world(); // Hi world
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues betweenfunction/staticmethod class constant/ns constant
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 definition as in:
?php
namespace foo::bar;
?
and the things in the namespace, as in:
?php
class bar {}
?
Or how about :)?
Although I'm not a fan of the backslash, I think it's starting to look
better and better on the background of all discussed so far.
Here are reasons and examples:
1) It's one char, it's easy to type, it's visually distinct from - and ::,
for both the parser and humans alike.
2) We need to use [separatator][identifier] to refer to global classes and
possibly functions, from a namespace, and \Foo() is a lot more intuitive
than ::Foo() in this setup, because a backslash evokes the same semantics we
use with relative and absolute filepaths.
3) We'll have the chance of properly introducing namespaces that really wall
off libraries with all their identifiers, including variables, constants,
functions and classes, the way it's supposed to work (and I'm also one of
the people who'd like to be able to namespace my function-only libraries
too).
4) Examples of how this sits visually and works in practice (each line is a
separate example). Notice we use the exact same semantics as in filepaths
(with the addition of use aliases), which is intuitive and constistent for
both the implementers and the users of this feature:
namespace Foo\Bar\Baz;
use \globalFunc(); globalFunc(); // aliased global function
namespace Abc; \globalFunc(); // direct use without alias
globalFunc(); // no need for prefix in global space
use \GlobalClass; GlobalClass::method();
$\globalVar; $localVar; $\Foo\Far\namespacedVar;
\Foo\Bar\NamespacedClass::method(); // absolute identifier
namespace Foo; Bar\NamespacedClass::method(); // relative reference to the
same class;
use Foo\Bar; Bar\NamespacedClass::method(); // aliased reference to the same
class
\Foo\Bar\NamespacedFunc(); // absolute namespace path
namespace Foo; Bar\NamespacedFunc(); // relative reference to the same
function
use \Foo\Bar; Bar\NamespacedFunc(); // aliased reference to the same
function
Regards, SV
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace issues
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 the use ::foo or ::foo() when in a namespace, and leave namespaced functions in. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Suspendable requests for Apache
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. The API would be extremely simple, for example: suspend(string request_id, int timeout); - this would end the current request but keep the client connection open up to timeout seconds. resume(string request_id); - this would resume a suspended request by starting a new PHP request but reusing the same client connection that was previously suspended Two ideas: First is, for a rough approach that works today: you can emulate this by polling from the suspended process by sleeping for, say, 400ms and checking a shared value for a flag whether to resume. Second and most important though, Apache isn't architected to handle long running processes inside a request, as it typically uses a limited pool of threads/processes to serve requests, if enough requests in the pool are held up suspended, it would prove heavily detrimental to the server performance (this is why push technologies like Comet are not recommended on Apache). I would possibly suggest the requests communicating with (for example), long running background processes running from shell from that purpose, using standard interprocess communication like unix sockets. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Scoping of use statements and a strategy for 5.3/6.0 release of namespace
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 {} will possibly be confusing. But, it'll work fine enough.
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] allow T_INLINE_HTML before T_NAMESPACE
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) is perfectly natural in that setup.
In fact, I'd argue that we need a way to break out to global namespace
*after* a namespace too.
Something that would be naturally solved by {} but since this is
discarded... (but you see how it's not purely phylosophical issues either).
Regards,
Stan Vassilev
Hi,
This is a simple patch that allows files like this:
main.php:
html
head
titletemplate example/title
/head
/html
body
?php
namespace my::template;
// stuff
?
/body
to work without parse error.
Greg
P.S. this is the last outstanding namespace issue that I'm aware of
aside from the bracket wars, which is 100% philosophical, all the issues
fixed by my patches are functional problems in namespaces.
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.647.2.27.2.41.2.85
diff -u -u -r1.647.2.27.2.41.2.85 zend_compile.c
--- Zend/zend_compile.c 29 Aug 2008 10:17:08 - 1.647.2.27.2.41.2.85
+++ Zend/zend_compile.c 12 Sep 2008 19:07:42 -
@@ -504,13 +504,17 @@
}
-void zend_do_echo(const znode *arg TSRMLS_DC)
+void zend_do_echo(const znode *arg, int is_html TSRMLS_DC)
{
zend_op *opline = get_next_op(CG(active_op_array) TSRMLS_CC);
opline-opcode = ZEND_ECHO;
opline-op1 = *arg;
- SET_UNUSED(opline-op2);
+ if (is_html) {
+ opline-op2.op_type = IS_CONST; /* tell zend_do_namespace that
INLINE_HTML is OK */
+ } else {
+ SET_UNUSED(opline-op2);
+ }
}
void zend_do_abstract_method(const znode *function_name, znode *modifiers,
const znode *body TSRMLS_DC)
@@ -5040,10 +5044,11 @@
char *lcname;
if (CG(active_op_array)-last 0) {
- /* ignore ZEND_EXT_STMT and ZEND_TICKS */
+ /* ignore ZEND_EXT_STMT and ZEND_TICKS and T_INLINE_HTML */
int num = CG(active_op_array)-last;
while (num 0
(CG(active_op_array)-opcodes[num-1].opcode == ZEND_EXT_STMT ||
+ (CG(active_op_array)-opcodes[num-1].opcode == ZEND_ECHO
CG(active_op_array)-opcodes[num-1].op2.op_type == IS_CONST) ||
CG(active_op_array)-opcodes[num-1].opcode == ZEND_TICKS)) {
--num;
}
Index: Zend/zend_compile.h
===
RCS file: /repository/ZendEngine2/zend_compile.h,v
retrieving revision 1.316.2.8.2.12.2.33
diff -u -u -r1.316.2.8.2.12.2.33 zend_compile.h
--- Zend/zend_compile.h 29 Aug 2008 18:12:47 - 1.316.2.8.2.12.2.33
+++ Zend/zend_compile.h 12 Sep 2008 19:07:42 -
@@ -385,7 +385,7 @@
void fetch_string_offset(znode *result, const znode *parent, const znode
*offset TSRMLS_DC);
void zend_do_fetch_static_member(znode *result, znode *class_znode
TSRMLS_DC);
void zend_do_print(znode *result, const znode *arg TSRMLS_DC);
-void zend_do_echo(const znode *arg TSRMLS_DC);
+void zend_do_echo(const znode *arg, int is_html TSRMLS_DC);
typedef int (*unary_op_type)(zval *, zval * TSRMLS_DC);
typedef int (*binary_op_type)(zval *, zval *, zval * TSRMLS_DC);
ZEND_API unary_op_type get_unary_op(int opcode);
Index: Zend/zend_language_parser.y
===
RCS file: /repository/ZendEngine2/zend_language_parser.y,v
retrieving revision 1.160.2.4.2.8.2.26
diff -u -u -r1.160.2.4.2.8.2.26 zend_language_parser.y
--- Zend/zend_language_parser.y 29 Aug 2008 17:54:29 -
1.160.2.4.2.8.2.26
+++ Zend/zend_language_parser.y 12 Sep 2008 19:07:42 -
@@ -236,7 +236,7 @@
| T_GLOBAL global_var_list ';'
| T_STATIC static_var_list ';'
| T_ECHO echo_expr_list ';'
- | T_INLINE_HTML { zend_do_echo($1 TSRMLS_CC); }
+ | T_INLINE_HTML { zend_do_echo($1, 1 TSRMLS_CC); }
| expr ';' { zend_do_free($1 TSRMLS_CC); }
| T_UNSET '(' unset_variables ')' ';'
| T_FOREACH '(' variable T_AS
@@ -556,8 +556,8 @@
;
echo_expr_list:
- echo_expr_list ',' expr { zend_do_echo($3 TSRMLS_CC); }
- | expr { zend_do_echo($1 TSRMLS_CC); }
+ echo_expr_list ',' expr { zend_do_echo($3, 0 TSRMLS_CC); }
+ | expr { zend_do_echo($1, 0 TSRMLS_CC); }
;
Index: Zend/tests/ns_076.phpt
===
RCS file: Zend/tests/ns_076.phpt
diff -N Zend/tests/ns_076.phpt
--- /dev/null 1 Jan 1970 00:00:00 -
+++ Zend/tests/ns_076.phpt 12 Sep 2008 19:07:42 -
@@ -0,0 +1,26 @@
+--TEST--
+076: T_INLINE_HTML prior to namespace declaration
+--FILE--
+hi there
+?php
+
+namespace foo;
+
+class Test {
+ static function f() {
+var_dump((binary)__NAMESPACE__);
+include __DIR__ . '/ns_069.inc';
+var_dump((binary)__NAMESPACE__);
+ }
+}
+
+Test::f();
+
+?
+===DONE===
+--EXPECT--
+hi there
+string(3) foo
+string(0)
+string
Re: [PHP-DEV] [PATCH] allow T_INLINE_HTML before T_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 with namespaces in them.
Regards,
Stan Vassilev
Hi,
This is a simple patch that allows files like this:
main.php:
html
head
titletemplate example/title
/head
/html
body
?php
namespace my::template;
// stuff
?
/body
to work without parse error.
Greg
P.S. this is the last outstanding namespace issue that I'm aware of
aside from the bracket wars, which is 100% philosophical, all the issues
fixed by my patches are functional problems in namespaces.
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.647.2.27.2.41.2.85
diff -u -u -r1.647.2.27.2.41.2.85 zend_compile.c
--- Zend/zend_compile.c 29 Aug 2008 10:17:08 - 1.647.2.27.2.41.2.85
+++ Zend/zend_compile.c 12 Sep 2008 19:07:42 -
@@ -504,13 +504,17 @@
}
-void zend_do_echo(const znode *arg TSRMLS_DC)
+void zend_do_echo(const znode *arg, int is_html TSRMLS_DC)
{
zend_op *opline = get_next_op(CG(active_op_array) TSRMLS_CC);
opline-opcode = ZEND_ECHO;
opline-op1 = *arg;
- SET_UNUSED(opline-op2);
+ if (is_html) {
+ opline-op2.op_type = IS_CONST; /* tell zend_do_namespace that
INLINE_HTML is OK */
+ } else {
+ SET_UNUSED(opline-op2);
+ }
}
void zend_do_abstract_method(const znode *function_name, znode *modifiers,
const znode *body TSRMLS_DC)
@@ -5040,10 +5044,11 @@
char *lcname;
if (CG(active_op_array)-last 0) {
- /* ignore ZEND_EXT_STMT and ZEND_TICKS */
+ /* ignore ZEND_EXT_STMT and ZEND_TICKS and T_INLINE_HTML */
int num = CG(active_op_array)-last;
while (num 0
(CG(active_op_array)-opcodes[num-1].opcode == ZEND_EXT_STMT ||
+ (CG(active_op_array)-opcodes[num-1].opcode == ZEND_ECHO
CG(active_op_array)-opcodes[num-1].op2.op_type == IS_CONST) ||
CG(active_op_array)-opcodes[num-1].opcode == ZEND_TICKS)) {
--num;
}
Index: Zend/zend_compile.h
===
RCS file: /repository/ZendEngine2/zend_compile.h,v
retrieving revision 1.316.2.8.2.12.2.33
diff -u -u -r1.316.2.8.2.12.2.33 zend_compile.h
--- Zend/zend_compile.h 29 Aug 2008 18:12:47 - 1.316.2.8.2.12.2.33
+++ Zend/zend_compile.h 12 Sep 2008 19:07:42 -
@@ -385,7 +385,7 @@
void fetch_string_offset(znode *result, const znode *parent, const znode
*offset TSRMLS_DC);
void zend_do_fetch_static_member(znode *result, znode *class_znode
TSRMLS_DC);
void zend_do_print(znode *result, const znode *arg TSRMLS_DC);
-void zend_do_echo(const znode *arg TSRMLS_DC);
+void zend_do_echo(const znode *arg, int is_html TSRMLS_DC);
typedef int (*unary_op_type)(zval *, zval * TSRMLS_DC);
typedef int (*binary_op_type)(zval *, zval *, zval * TSRMLS_DC);
ZEND_API unary_op_type get_unary_op(int opcode);
Index: Zend/zend_language_parser.y
===
RCS file: /repository/ZendEngine2/zend_language_parser.y,v
retrieving revision 1.160.2.4.2.8.2.26
diff -u -u -r1.160.2.4.2.8.2.26 zend_language_parser.y
--- Zend/zend_language_parser.y 29 Aug 2008 17:54:29 -
1.160.2.4.2.8.2.26
+++ Zend/zend_language_parser.y 12 Sep 2008 19:07:42 -
@@ -236,7 +236,7 @@
| T_GLOBAL global_var_list ';'
| T_STATIC static_var_list ';'
| T_ECHO echo_expr_list ';'
- | T_INLINE_HTML { zend_do_echo($1 TSRMLS_CC); }
+ | T_INLINE_HTML { zend_do_echo($1, 1 TSRMLS_CC); }
| expr ';' { zend_do_free($1 TSRMLS_CC); }
| T_UNSET '(' unset_variables ')' ';'
| T_FOREACH '(' variable T_AS
@@ -556,8 +556,8 @@
;
echo_expr_list:
- echo_expr_list ',' expr { zend_do_echo($3 TSRMLS_CC); }
- | expr { zend_do_echo($1 TSRMLS_CC); }
+ echo_expr_list ',' expr { zend_do_echo($3, 0 TSRMLS_CC); }
+ | expr { zend_do_echo($1, 0 TSRMLS_CC); }
;
Index: Zend/tests/ns_076.phpt
===
RCS file: Zend/tests/ns_076.phpt
diff -N Zend/tests/ns_076.phpt
--- /dev/null 1 Jan 1970 00:00:00 -
+++ Zend/tests/ns_076.phpt 12 Sep 2008 19:07:42 -
@@ -0,0 +1,26 @@
+--TEST--
+076: T_INLINE_HTML prior to namespace declaration
+--FILE--
+hi there
+?php
+
+namespace foo;
+
+class Test {
+ static function f() {
+var_dump((binary)__NAMESPACE__);
+include __DIR__ . '/ns_069.inc';
+var_dump((binary)__NAMESPACE__);
+ }
+}
+
+Test::f();
+
+?
+===DONE===
+--EXPECT--
+hi there
+string(3) foo
+string(0)
+string(3) foo
+===DONE===
Index: Zend/tests/ns_077.phpt
===
RCS file: Zend/tests/ns_077.phpt
diff -N Zend/tests/ns_077.phpt
--- /dev/null 1 Jan 1970 00:00:00 -
+++ Zend/tests/ns_077.phpt 12 Sep 2008 19:07
[PHP-DEV] Scoping of use statements and a strategy for 5.3/6.0 release of namespace
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 statements, so now those merged
files share their use imports, thus breaking all the code where collisions
occur.
Also we have the problems with name resolution of internal vs user classes and
autoloaders, discussed here.
And we also have the non-intuitive differentiation between resolving
functions/classes/constant which will most likely lead people to believe
functions/constants aren't supported in any way in namespaces (if they try, and
it doesn't work, they won't try second time).
Which leads me to the following proposal:
For PHP 5.3 we introduce namespaces with a very limited safe set of barebones
features, that we won't regret later for releasing and having to modify in a
non-BC way. It'll let people start porting their code and be ready for the full
featureset later on, which will be a proper superset of the 5.3 release:
1) We disable support for multiple namespaces per file as it is, as it can't be
used without ability to scope use statements as well.
2) We remove the statement use (regarding namespaces, not regarding
closures), until we get more feedback from the community on the exact preferred
resolution algorithms, and more thought is put to this.
For PHP 5.4 or 6:
1) Introduce file-level use statements with same syntax as now, but modified
resolution rules based on further discussion and feedback. And if someone is
about to say we had plenty of discussion, well it's apparent we didn't have
enough given all the problems facing namespaces right now, or maybe not enough
of the constructive type of discussion.
2) Introduce ability to scope use and namespace statements with curly
brackets, so that multiple files can be safely merged without changing intent
(all file-level namespace can be converted with curly brackets, and the
existing curly bracket ones don't need to be converted), example:
namespace X {
use Y as Z {
...
}
}
namespace Y {
use X as Z {
...
}
}
Waiting for your feedback...
Regards,
Stan Vassilev
Re: [PHP-DEV] Re: Scoping of use statements and a strategy for 5.3/6.0 release of namespace
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 thought of scoping use statements, so now those merged files share their use imports, thus breaking all the code where collisions occur. Hi, Stan, did you actually try this out? According to my checkout of CVS, you're wrong. Try this script: What's the logic behind namespace declaration affecting file-level import statements. Looks like such a hack to me. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: towards a 5.3 release
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 they are right now would cause more troubles
than they solve.
Automating name resolution at runtime is bound to have problems as PHP was
never intended to go up in scopes and resolve variables, this is why we
have use in closures, and why we have global in methods and functions.
One of the things I suggested few months ago was that runtime resolution is
simply not included at all, and that we have a syntax for explicitly
specifying the global namespace, when the code is inside a namespace. I
heard lots of objections how ugly it is to prepend everything with :: (not
that this is the only possibly syntax), but it increasingly is becoming
apparent that the automatic resolution is bound to have either bug-prone or
performance issues, so why introduce a trap in the language that people
will continuosly fall into?
Running the autoloader before every internal class would be just amazing for
those of us with caching crawlers (directory crawls for classes and stores
location in cache). I'll be having cache miss every time I use an internal
class, which with larger class libraries can run into 2-3 seconds at a time
to look for, say, class ArrayObject.
The other solution to put autoload last is equally bad as it means an
internal class would override one of mine, which I autoload, making the
autoloader useless.
So I'd say, make it explicit and remove the vague moment.
Regards,
Stan Vassilev
1) those that tend to always spice up their API's by wrapping pretty much
all internal functionality (be if that the internal functionality has a
procedural or an OO API). These are also the people that will have the
more complex OO structures (deep inheritance). They also seem like the
most heavy users of namespaces
2) those that keep their structures flat, use native API's directly and
live in a mixed world of OO and procedural code
So while we are assessing the impact its important to keep in mind which
user type is going to be affected in what way. Furthermore I hope that
some of the people that have build up a code base that uses namespaces
will do this benchmarking, because otherwise we will hardly get any
useful data. Even then of course the benchmarks must be taken with a
grain of salt (as always).
I am including the email from Greg at the bottom here, along with a reply
from Stas (again read the archive to get the full story). Maybe if we
think hard about this one (now that we know that its an important real
world need), we can discover a solution that we did not see at first.
On 05.07.2008, at 18:48, Greg Beaver wrote:
1) namespaces
Here we need to make sure that the current state is now in a coherent
state. I think Derick still has some issues [3] with the recent change
by Greg [4], but even his criticism did not sound all to loud. So I
think we are in a good state here?
My recent changes aside, there are still some fubar issues with name
resolution, and there has been some offlist discussion of ways to fix
this that have not led to concrete onlist proposals yet.
For those who don't know what I'm talking about, the question is how to
resolve an unqualified classname inside a namespace. i.e. this code:
a.php:
?php
namespace Foo;
throw new Exception('is this Foo::Exception or ::Exception?');
?
Currently, the above code would throw ::Exception, because if a
namespaced class does not exist, internal classes are checked before
autoloading for performance reasons. However, if we execute this code
instead:
b.php:
?php
namespace Foo;
class Exception {}
include 'a.php';
?
then a.php would throw Foo::Exception. In other words, depending on
file inclusion order, classnames can change with current PHP accepted
practices. The solution to this is to use each namespaced class
explicitly:
a2.php:
?php
namespace Foo;
use Foo::Exception;
throw new Exception('this is Foo::Exception always');
?
However, all it takes is one forgotten use statement, and a very
subtle bug could be introduced later.
Taking a step back, let's examine why autoload is not called before
checking internal classes - it is for performance reasons. However,
this performance enhancement causes unpredictable behavior *by default*
without explicit action.
There is a simple solution, however. If one changes the name resolution
to this pseudo-code:
1) check Foo::Exception for existence
2) if not found, try to autoload Foo::Exception
3) if not found, check for ::Exception existence, userspace *or*
internal (addition of userspace check also fixes other problems raised
on-list)
4) if not found, fail.
This fixes the logic problem, and re-introduces the performance
Re: [PHP-DEV] Re: towards a 5.3 release
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 syntax), but it increasingly is becoming apparent that the automatic resolution is bound to have either bug-prone or performance issues, so why introduce a trap in the language that people will continuosly fall into? In other words: everyone is saying that for those of us who need performance or avoid resolution problems, can use ::, and the rest... -- who are those the rest, which don't care about performance and resolution problems? What is YOUR suggestion? Just tell us how hilarious it is to type :: and introduce all the other problems anyway. Furthermore, the :: (or rather I'd make it php::) would only be required in a namespace. For the procedural folks which don't put code in a namespace, they're already implicitly in php:: so they can continue writing things exactly like thay do now. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: towards a 5.3 release
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 of taste - then, well, tastes differ. Saying my taste requires every name not to have :: is not the same as saying namespaced functions are useless. So essentially this is your argument for making functions a special case: your taste. I don't see any other arguments coming from you. I'd really appreciate if you start discussing the actual issues we name and not spin rhetoric about how everything is just great once we adjust to *your* taste. Also, if namespaces are great, I think it's time for Zend to drink the cool aid and show us where their alpha/beta of ZF with namespaces is. I think witnessing the problems with namespaces first-hand in a team with large codebase will explain things to you better than we (apparently) can here, as our experience is not taken seriously. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
