Re: [PHP-DEV] native php annotations
Hi Guilherme. On 14.03.11 19:02, guilhermebla...@gmail.com wrote: @Etienne: That RFC is outdated. Since the last feedback form internals list, a lot of changes have been made to that RFC. Maybe I should update it ASAP so you can clearly understand what have changed to be compatible with current PHP syntax. I think having the RFC up-to-date is a must to get this rolling (again). So, please, do it! :) I'd like to see what people think about it and make something IN on next PHP major version. I honestly think I can speak for the whole FLOW3[1] developer and user base in this regard. With that said, I would love to see native annotation support in PHP! If you need support and/or testing targets, get in touch! Regards, Karsten [1] http://flow3.typo3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About optimization
Hi. On 13.01.10 16:48, Rasmus Lerdorf wrote: Alain Williams wrote: Unfortunately: APC does not work with PHP 5.3 -- I have a site where I would love to use it but I cannot. I use APC to great effect elsewhere. Hm. I have 5.3.1 with APC 3.1.3p1 and it runs fine. This is not a production environment, but I have not yet had the impression APC was broken. What is it that doesn't work yor you? The svn version works ok with 5.3. Turn off gc though. Why is that advisable? Any pointers to background information welcome. Regards, Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PDO Bug introduced in revision 290786 and released in 5.2.12 and5.3.1
Hi. On 16.01.10 02:54, Matt Read wrote: We are developers from the Habari Project, an open source PHP blogging application; We would like to raise concern with a recent change to the logic of PDO. I fully support what Matt writes. Although we don't use that behaviour in our codebase, the way this change was done raises concerns on our side as well. Especially the timeframe and the handling of the existing tests make me worry in that context. @Matt: What entry in the bug tracker is related to this new issue? Regards, Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance question about create_function
Hi. On 26.10.09 15:25, Mathieu Suen wrote: I am more asking about performance. I would have been ready to sacrifice performance if it saved money. But according to my quick tests, it does not. See http://tr.im/DrsH for details... oh, this is on PHP 5.3. Any other insights on this welcome! Regards, Karsten PS: This is off-topic for php-internals, probably... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
Hi. On 08.07.2009 12:11 Uhr, Steven Van Poeck wrote: Derick Rethans wrote: With this logic, we got a PHP 5.3 as well, and with the same logic there will be a PHP 5.4, 5.5, 5.6 and we never get to 6. Instead of putting stuff in PHP 5.4 (which at the moment is *not* planned), why not focus all effort on 6 to make sure it comes out faster? And although this feature is useful, it's not something that I would *really-need-right-now*. regards, Derick Agree 100% +1 for parameter type enforcement in PHP 6 +1 to that. Regards, Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Notes from the PDM in Chicago
Hi Lukas. On 04.06.2009 8:40 Uhr, Lukas Kahwe Smith wrote: To me its absolutely critical that we do not give the impression that the next bigger update after 5.3 will be 5.4. The next big thing is 6.0. Thumbs up, and good luck with this ambitious plan! ;) We'd be happy to switch to PHP 6... Regards, Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Extending SplObjectStorage impossible due to type hints!?
Hi. I am trying to extend SplObjectStorage and override the attach() method. This gives me: Strict Standards: Declaration of B::attach() should be compatible with that of SplObjectStorage::attach() in test.php on line 5 Seems am am hitting the object type hint wall again. Any ways around this, aside from disabling strict standard notices? Regards, Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Extending SplObjectStorage impossible due to type hints!?
Hi Alexey. On 03.04.2009 12:33 Uhr, Alexey Zakhlestin wrote: well, and what is the reason why you can't make your attach() compatible with SplObjectStorage's? the following signature works for me (both in 5.2 and 5.3): public function attach($obj, $inf = null) Doh, well. Even better, so it's not some object type hint, but simply me not knowing the full attach() signature. Yay! Thanks a bunch! Karsten PS: Some updated docs for SPL would be really cool... ;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC - XDebug profiling web front-end
Hi. On 31.03.2009 18:08 Uhr, David Coallier wrote: I'm sorry to tell you that but xdebug web profiling was a project for last year. Please read http://wiki.php.net/gsoc/2009 for this years GSoC ideas. Well, was it done last year? If yes: great, where is it? If no: yeah, do it this year! Regards, Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Vote: allow_call_time_pass_reference value in production INI
Hi. On 19.02.2009 6:34 Uhr, Eric Stewart wrote: allow_call_time_pass_reference = Off (Issue Warnings) +1 Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: New INIs, Round Two.
Hi Eric. On 17.02.2009 8:02 Uhr, Eric Stewart wrote: extension_dir = ./ Should be commented out as has been pointed out already by Johannes Schlüter. enable_dl = On enable_dl should be off(). Well, that has been said a few time already... :) By now I also think that allow_call_time_pass_reference should be off in both files. Regards, Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC for new INI's
Hi. On 11.02.2009 15:26 Uhr, Christian Schneider wrote: session.bug_compat_42 = Off ; Why should devel/production differ? Because in dev a warning should be shown, but the warning setting only has an effect if this setting is on (at least that way it is documented in php.ini). Regards, Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC for new INI's
Hi Eric. On 10.02.2009 3:27 Uhr, Eric Stewart wrote: A new RFC for PHP's proposed INI files have been added to the wiki. Below is a direct link to the page. http://wiki.php.net/rfc/newinis I love the settings for production, but I think you reversed the meaning of allow_call_time_pass_reference - if it is allowed no warning will be issued. So, to make your intention of ; Default Value: On (Issue warnings) ; Development Value: On (Issue warnings) ; Production Value: Off (Suppress warnings) work, you need to write that the other way around - 'Off' means 'issue warnings'... It is: Development Value: Off (Issue warnings) Production Value: On (Suppress warnings) In production session.bug_compat_42 is off, but according to the summary you want it to be on for development (so that warnings about it are shown, I assume). In the development php.ini the actual values for both settings are off, though. And I am not sure about register_argc_argv having different values in both files. I understand ot being off in production for speed reasons, but if it just works in development and suddenly stops working in production... But that's a minor issues. All in all like the proposed settings! Regards, Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Quick question about closing PHP tags
Hi. On 03.02.2009 10:51 Uhr, Richard Quadling wrote: PS: Let the idea grow for another eight years! :) When PHP6 becomes the norm with its lovely unicode handling, BOM's may become more prevalent. If the editor of choice supplies them, having PHP strip them from include/require would be helpful. Ok, point taken. Although I never saw a BOM in my life as of now. :) Regards, Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Quick question about closing PHP tags
Hi. On 02.02.2009 9:28 Uhr, mike wrote: There's some discussion going on -discuss about whether or not to close PHP tags. ... Obviously the bonus is no stupid human error/whitespace type issues with output buffering and such. But I wanted to know if there's any opinion either way for any other reasons? If I expect human errors with whitespace, I better not trust the code. Honestly, how hard is it to simply start and end your files with ?php and ? and never write HTML and PHP mixed? MVC was mentioned, and templating is already some years old as well. I don't get it, why would I want this? If the tags never had been needed, fine, but now... Regards, Karsten PS: Let the idea grow for another eight years! :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New function proposal: spl_class_vars / params / contents
Hi. On 21.01.2009 11:44 Uhr, Kenan R Sulayman wrote: I did propose the function because the construction in user-land is quite expensive; Reflection is expensive, indeed. The way we solved it for FLOW3 is to create a ReflectionService that caches such information as long as the source doesn't change. Regards, Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Path length for files on NTFS
Hi everyone. I posted this on php.windows a two days ago without a response. Maybe someone here can help me. Recently someone using our software told us about problems with generated filenames being too long. I did some research on the net and some quick tests on Vista Business, and it seems there is indeed still a problem. While NTFS supports path lengths of up to 32k characters, most software still supports only 255 (or 260 on Vista) character filenames. Since that includes the full path, we run into this problem with file based caching filenames. Since there are ways to use long(er) filenames, does anyone know if this planned for PHP? Should it work? Is this a problem others also see? Kind regards, Karsten PS: Those questions may sound stupid, but coming from a Linux/Mac background this is simply a completely new problem to me. :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Path length for files on NTFS
Hi Pierre. On 16.01.2009 14:33 Uhr, Pierre Joye wrote: While NTFS supports path lengths of up to 32k characters, By the way, this limit is approximative. In what way? There is no plan yet to increase this value. The main problem is that the maximum length of a path is volume dependent, not system dependent. Right. One FAT volume could wreck it all. To support longer path, it would mean to check the volume information for each file operation (once per volume, cache it and reuse it) as well as using dymamic allocation for for the filename itself, in many places. I'm not sure it is worth the effort. Sounds bad. I just cannot believe it is still easily possible to break a machine by simply using FAT32 under Vista. Phew. You can use a hash as filename, as a temporary workaround. Well, not really. Our names include some information, so hashing isn't really an option. For now we'll probably just skip supporting Windows. Regards, Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Path length for files on NTFS
Hi. On 16.01.2009 17:12 Uhr, Pierre Joye wrote: The problem is exactly the same on any OS, only the size varies. The limit is not higher either. What do you use as naming for your entries? Oe example with 229 characters: /Users/karsten/Sites/typo3v5/Data/Temporary/6e7991cd3e3f10e110df4a26825c1f8c/_www/Cache/Testing/Tags/%CLASS%F3_Widget_Persistence_MessageQueuePersistenceAspect/FLOW3_Reflection-F3_Widget_Persistence_MessageQueuePersistenceAspect For deeper nested namespaces this will get longer, add some deeper directory structure at the start and - bang. Now, I never ran into problems with paths being too long for anything I tried on Linux or Mac, so what limits exist? Admittedly I never thought about that much. Given we live in a world of terabytes I'd expect names to be virtually as long as I want. :) Btw, what do you do when the path len of the path where the cache is stored is closed from MAXPATHLEN (PHP_MAXPATHLEN in userland)? Given than MAXPATHLEN can be between 260 and 2048 (~), that' can happen easily. Never heard of that constant, thanks for pointing it out. The documentation doesn't explain it, is there some background information available somewhere? So, in the best case we hit the roof at ~2k? Good to know... Thanks, Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: json_encode()
Hi. On 15.12.2008 18:50 Uhr, Rasmus Lerdorf wrote: Ok, so as promised I ran some of the options we have that came up last week by Douglas Crockford. 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 Karsten Dambekalns -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Problem with (namespaced) code extending ReflectionProperty- possible bug?
Hi.
Stanislav Malyshev wrote:
According to the manual and the PHP source the signature is this:
public function getValue(stdclass $object)
...
Use public function getValue($object = null) {} instead.
Thanks, that works! I saw the [] in the C source, but failed to draw the
right conclusion...
Regards,
Karsten
PS: Having a way to type hint on any object would be cool!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Problem with (namespaced) code extending ReflectionProperty - possible bug?
Hi.
Running 5.3.0alpha3 now and converting our codebase to the new
namespaces syntax. Works fine so far, the new name resolution rules are
very usable and lead to cleaner code so far. :)
Now I ran into a problem. We have a class extending ReflectionProperty,
and I got a complaint about the signature of our getValue() not matching
that of the parent class. Ok, I added that stdclass type hint, fine. I
thought.
Later on it turned out that I need to make that type hint \stdclass as
our code is namespaced and I got an error because My\NS\stdclass could
not be found. Now I got that signature mismatch warning again. Bummer. I
decided to build a small test case, and now the fun starts.
According to the manual and the PHP source the signature is this:
public function getValue(stdclass $object)
This is my test code:
snip
?php
class PropertyReflection extends ReflectionProperty {
public function getValue(stdclass $object) {}
}
?
snip
and the result of running that is:
snip
Declaration of PropertyReflection::getValue() should be compatible with
that of ReflectionProperty::getValue()
snip
I get that result even when using
* no type hint
* stdClass
The result stays the same when adding a namespace declaration and
adjusting the typehint variations accordingly.
Can anybody shed some light on this? Or should I file a bug report right
away?
Thanks,
Karsten
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Upgrading to internal DateTime
Hi Derick. Derick Rethans wrote: This is not the correct thing to do, as you will lose timezone information. The W3C format only stores UTC offsets (in the form of +00:00). However, that same UTC offset can be used in different areas with different DST changes. Best thing is to store in Unix timestamps. And how does a unix timestamp preserve timezone information? Or am I completely off track? Regards, Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Fatal error: Call to a member function on a non-object
Hi. Christopher Vogt wrote: I fetch records a database. Sometime it happens that a record does not exist anymore. Let's assume it's a user, then $user will be NULL. echo $user['fullname']; // no error at all, $user['fullname'] === NULL Shouldn't this at least trigger a Notice? Check your error handling settings, probably warnings/notices are disabled. echo $user-get_fullname(); // Fatal error Well, is $user an object? If not, well, better not call a method on it. Regards, Karsten PS: I am not sure this is a topic for php.internals... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: quick polls for 5.3
Hi.
Lukas Kahwe Smith wrote:
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC
break will be that if (extension_loaded('mhash')) will need fixing if
mhash is removed (answer both)
I) enable ext/hash by default
II) remove ext/mhash
+1 for both
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since
ext/ereg is more or less redundant with ext/preg and is likely to not
get much unicode love for PHP 6, the question is if we should mark it
with a E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate STDIN
and friends)
b) Should we instead just throw an E_STRICT
c) Document as is
c
4) keep ext/phar enabled by default in 5.3?
+1
5) keep ext/sqlite3 enabled by default in 5.3?
+1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
II) also enable ext/mysql, mysqli und pdo_mysql by default since there
will be no external dependencies in this case
+0 for both
7) should Output buffering rewrite MFH? this one comes with some
baggage, we need enough people to actually have a look at how things are
in HEAD and make it clear that they will be available for bug fixing and
BC issues resolving. the risk here is obviously that any BC issues will
be hard to isolate for end users.
abstain
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
abstain
Regards,
Karsten
--
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. Steph Fox wrote: This thread really should be re-titled to allow reserved words as a classname or not. Then perhaps the only logical response to the question would be so obvious that there would be no thread... oo-er... Right, the subject indicates a different question that what seems to be discusssed here. The way I understood it was about allowing *methods* named clone in a class. That would come in handy for me, porting interfaces from Java to PHP. Currently I have to go back to klone to make it legal. Regards, Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Proposal for new construct: nameof
Hi. Stan Vassilev | FM wrote: 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; ... NOTE: As a side effect this means less direct writing of string function/class names, and less complaints about \ being the escape characters. Oh, that sounds very good. We do a lot of getComponent($classname) stuff, that would be awesome in that context. Regards, Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Clarifying the resolution rules
Hi. Stan Vassilev | FM wrote: A yet another compromise is possible as the lesser evil: ... 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. I like that way. Regards, Karsten -- 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
Hi.
Sorry for yet another OT post in this thread.
Josh Davis wrote:
I have a question about 3. Where in a script can you use the use
statement? Could it be used inside conditionals? For example,
if ($testing) {
use class testing::PDO;
} else {
use class ::PDO;
}
I hope this is a badly chosen example, as code should never behave
seperately when under test as compared to production. Use dependency
injection to feed a mock object, but don't do this.
Regards,
Karsten
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: my last attempt at sanity with namespaces
Hi Greg, everyone. Greg Beaver wrote: http://wiki.php.net/rfc/namespaceissues Read it and discuss. Let's be clear people: the technical problems in namespaces are limited and solvable. The problems in the political environment surrounding them may not be. Wouldn't politics be a stupid-ass reason to remove namespaces? Oh, yeah, absolutely! Conflict between namespaced functions and static class methods I would prefer #1, but am equally happy with #3. Note: Rewriting what we currently have to make it work with changes in namespaces would be something we happily attack as soon as we know the direction. Resolving access to internal classes Great. And the autoload-for-internal classes issue would be no issue if (like we currently do) one explicitly refers to them like ::Exception anyway. Regards, Karsten PS: We are still in Berlin at a TYPO3 core developer meeting, and I am happy to see this issue (almost) resolved. The same is true for the others here. Long live PHP! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
Hi. Steph Fox wrote: Not trying to undo it, just trying to prevent a horrible mistake being made under pressure. What happened to release when it is ready? Who puts up that pressure? And why is there more pressure for 5.3 to be released than to release things that people have been hoping and waiting for for years? Regards, Karsten -- Karsten Dambekalns FLOW3 TYPO3 Development TYPO3 Association -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
Hi. Steph Fox wrote: Surely everyone can see the very public ongoing discussions on internals@ over the course of this and last year? Sure. No? There's a very big difference between 'testing' and 'preparing to migrate a codebase'. Ok, but the broad testing needs a broad scope. We need more than 10-liners to check namespaces. No? And of course those same people don't mind a bit if the implementation has changed 8 times in the last 6 months, because they understand that they're testing a moving target. No? Moving targets that suddenly just evaporate into nothingness are somewhat different. No? Trying to be cynical, Karsten -- Karsten Dambekalns FLOW3 TYPO3 Development TYPO3 Association -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
Hi. Stanislav Malyshev wrote: This is what I've be fearing. First slated for 5.0. Then 5.3. Now 6.0. It appears there's consensus to rip it out which, in my prior post, I was all for if people felt it meant getting it right. If 5.3 is not going to have namespaces, we will remove it's use from FLOW3 again and will not use them with PHP6 as well. That is because we can either include it now, or at the next major rewrite of our codebase (which is years away). There's nothing that will change from now to 6.0 except that the people who worked a lot on this feature would be less ready to repeat the ordeal. I heartily second that. Regards, Karsten -- Karsten Dambekalns FLOW3 TYPO3 Development TYPO3 Association -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
Hi. Sorry, I just have to make some points now. Call it venting for a cause, if you think I overreact. But be sure that the consequences I lay out below for TYPO3v5 and FLOW3 are very real. Vesselin Kenashkov wrote: I see the point and objections against quick and dirty, but on the other hand the discussion about the namespaces started long time ago - two years already? If for two years there wasn't an agreement how they have to be implemented (or even whether to add them at all! because I see many comments in this sense) what are the reasons to think that in the next 5-6 months, when php6 will reach its release stage with the first alphas, this will be done? I see no reasons to believe in such a statement. We started using PHP6 snapshots for TYPO3v5 and what is now known as FLOW3 in late 2006 because (actually compiled first version during the PHP Conference in Frankfurt after listening to an encouraging talk by Derick) we wanted to be only-unicode-finally. We were happy with a 2 year timeline at that point, because we were just starting. A year later we listened/talked to Derick again, and decided to write a wrapper[1] that emulates the most needed things and drop on PHP6, because we learned that it might take another 2 to 10 years, and almost nobody was really caring. Now we decided a few weeks ago to make use of namespaces and adjusted the whole codebase[2] about a month ago - because it seemed clear that 5.3 and namespaces were around the corner. Honestly, saying that those using non-released code should not complain is ridiculous if those people did so because the PHP developers asked to use namespaces in larger projects to get feedback. That feedback already led to disucssions collecting what could become a best practices guide on namespace use. And, as I said in another post, pulling that again weakens trust in any further announcement. In March Ilia in Montreal presented 5.3 and namespaces was on the list then. Come on, *now*, months later, you notice (again) that maybe it should not be part of it? And how come I have the feeling that suddenly a number of people say let's pull it that did not add suggestions on solving potential issues in the last weeks? On behalf of at least three dozen TYPO3 core developers, Karsten [1] http://forge.typo3.org/repositories/show/package-php6 [2] http://forge.typo3.org/repositories/show/packages -- Karsten Dambekalns FLOW3 TYPO3 Development TYPO3 Association -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Adding pecl/http to core
Hi. Michael Wallner wrote: I wonder what the general opinion is on adding pecl/http to the main PHP distribution? Many people have poked me in the past, so I guessed it's time to ask me and you that question once for all. Not that I have a lot to say here, but +∞ from my side as well. Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] solving the namespace conflict issues between function/staticmethodclass constant/ns constant
Hi. Dmitry Stogov wrote: Yes. Changing :: into any other separator solves the functions/static methods and constants ambiguity, but it also breaks intuitive syntax. Well, I'd say those having problems to grok the syntax will have problems getting the whole concept of namespaces. :) That being said: rather learn some syntax than constantly wonder about name resolution and ambiguity. Regards, Karsten -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: namespace issues
Hi.
For what it's worth, my point of view:
Stanislav Malyshev wrote:
1. Allow braces for namespaces. So, the syntax for namespaces will be:
a) namespace foo;
should be first (non-comment) statement in the file, namespace extends
to the end of the file or next namespace declaration.
b) namespace foo {}
can appear anywhere on the top scope (can not be nested).
Full support for the braces, but please *do*not* allow both ways. Why?
Perl's more than one way to do it? If there's one way, it's clear what
to use. I see absolutely no point in this. Really. Please don't.
2. Simplify resolution order for classes in the namespace: unqualified
names are resolved this way:
a) check use list if the name was defined at use, follow that
resolution
b) if not, the name resolves to namespace::name
Consequence of this will be that for using internal class inside
namespace one would need to refer to it either as ::Foo or do use ::Foo
prior to its usage.
Fine with me. I'd use ::Foo for internal classes anyway to avoid speed
and ambiguity issues.
3. Functions will not be allowed inside namespaces. We arrived to
conclusion that they are much more trouble than they're worth, and
summarily we would be better off without them. Most of the functionality
could be easily achieved using static class methods, and the rest may be
emulated with variable function names, etc.
We roll everything in classes anyway, so fine with me.
Regards,
Karsten
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
