Re: [PHP-DEV] Type hinting/casting request for vote
+1 from me On Tue, Jul 7, 2009 at 1:52 AM, Ilia Alshanetsky i...@prohost.org wrote: Last week or so there was a fairly detailed discussion on the internals list regarding type hinting based on my original patch. Since then the patch has been revised to address the major concerns that were identified (breakage of binary compatibility) as well extended with additional functionality (object hint, type casting, reflection support, etc...). The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. Ilia -- 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
If I understand correctly I vote. +1 for Issue 1 option 1 +1 for Issue 2 On Wed, Oct 15, 2008 at 9:35 PM, Greg Beaver [EMAIL PROTECTED] wrote: Hi, 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? Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
On Fri, Oct 10, 2008 at 5:56 PM, Geoffrey Sneddon [EMAIL PROTECTED] wrote: On 10 Oct 2008, at 06:03, Lukas Kahwe Smith wrote: 1) rip them out I'm +1 on this. We simply don't have consensus, and I don't see anyway we can have consensus by the time 5.3 has to be frozen. Once namespaces are in, we're gonna have to stick with whatever we choose, unless we totally break BC. -- Geoffrey Sneddon http://gsnedders.com/ I'd agree with this, leave something with such a big impact to version 6. At least it gives time to get it right.
Re: [PHP-DEV] namespaces and alpha3
On Tue, Oct 14, 2008 at 1:34 PM, Jean-philippe Serafin [EMAIL PROTECTED] wrote: Many people have starting working on top level application using namespaces, so there will a very bad buzz over the php community if namespaces are ripped out... There code should work fine in PHP 6 without any changes from what I understand. Taking it out of 5.3 gives extra time and puts any possible BC breakages to a major version of PHP.
Re: [PHP-DEV] [RFC] E_USER_DEPRECATED
+1 from me in PHP 5.3 deprecation notices have been split of from E_STRICT into E_DEPRECATED On Sun, Jul 20, 2008 at 6:45 AM, Nathan Nobbe [EMAIL PROTECTED] wrote: On Sat, Jul 19, 2008 at 4:55 AM, Lars Strojny [EMAIL PROTECTED] wrote: Hi everbody, regarding my mail from yesterday, I've also created an RFC for the new error level. http://wiki.php.net/rfc/e-user-deprecated-warning i definitely like the E_USER_DEPRECATED :D im curious though, about E_DEPRECATED. is this for deprecated functions at the C level, or just the php api? the reason i ask is because deprecation notices are already issued via the E_STRICT level, for example, when using is_a() today, w/ E_STRICT enabled, the following is generated Strict standards: is_a(): Deprecated. Please use the instanceof operator in ... would, perhaps, the deprecation level for is_a() move to E_DEPRECATED (i noticed its still there in 5.3)? -nathan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] simple solution to another namespace conundrum?
I would agree, they seem to cause more problems and pollution than it would solve. I like the idea behind namespaces but what I've seen of the current implementations I would rather do without. Unfortunately I don't have any ideas or solutions to the problems. /James Dempster On Thu, Jun 26, 2008 at 8:38 AM, Derick Rethans [EMAIL PROTECTED] wrote: On Tue, 24 Jun 2008, Rasmus Lerdorf wrote: Derick Rethans wrote: On Tue, 24 Jun 2008, Alexey Zakhlestin wrote: it won't be a serious 'wtf', as on the top of the file, there would be some kind of use MySuperLibrary::DateTime; I know, but 400 lines down in the code you can't really see that. This addition might fix the immediate issue - but it doesn't make life easier for the developers that have to maintain the code. Even less if they're not aware that stuff is namespaced. If we don't allow it to work this way, then I really don't see the point in namespaces at all, which I assume is the point you are trying to make. Actually, the point that I was trying to make is that we instead of encouraging this confusion, we should put somewhere in our userland nameing guidelines that you still would need to provide a prefix to your (aliased) classnames in order to prevent confusion. But that then seriously means I see no real good reason still why people want namespaces with confusing resolving rules (concerning static methods like Greg points out). regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] simple solution to another namespace conundrum?
I find it interesting that we could quite possibly get just as many clashes with namespaced code. Of course it comes down to how well the developer implements there code. It's almost like namespace is just a method of aliasing long class names. On Tue, Jun 24, 2008 at 4:38 PM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: On 24.06.2008, at 16:52, Derick Rethans wrote: On Tue, 24 Jun 2008, Alexey Zakhlestin wrote: On Tue, Jun 24, 2008 at 6:36 PM, Derick Rethans [EMAIL PROTECTED] wrote: On Fri, 20 Jun 2008, Gregory Beaver wrote: The user is obviously intentionally creating a DateTime class, and doesn't care about the internal classname in this script. The attached patch against PHP_5_3 would fix the issue by eliminating the check for conflict with CG(class_table) in the global namespace for internal classes. It however preserves this check for userspace classes so that (for instance) php-src/tests/Zend/ns_030.phpt does not fail. The basic idea is that we do have control over the userspace classes we include, but have no control over the internal classes. I am not so sure this is a good idea. I mean, for the developer that writes the code it's obvious that his version of DateTime is used. But for a second developer to come back later this could be a great WTF factor a few years down the road - wondering why the DateTime documentation on php.net doesn't match with what the class does. it won't be a serious 'wtf', as on the top of the file, there would be some kind of use MySuperLibrary::DateTime; I know, but 400 lines down in the code you can't really see that. This addition might fix the immediate issue - but it doesn't make life easier for the developers that have to maintain the code. Even less if they're not aware that stuff is namespaced. I think this is the name of the game. If you want namespace magic, then you have to live with it. I am sure that editors and IDE's can easily be extended the provide some assistance here. But it does of course means that when people share code, they can no longer rely that some namespace kung-fu will not break seemingly innocent code. As such I am +1 for Greg's change. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Alternative to multiple namespaces per file
what I find really annoying about all this namespace stuff, is how would
that be any different from
class Fully_Qualified_Class_Name_Declaration { }
/James
On Sat, May 31, 2008 at 1:10 PM, Stan Vassilev | FM [EMAIL PROTECTED]
wrote:
Hi,
I suppose this has been discussed before, so I'll not repeat reasons unless
requested, but I just want to offer a possible feature to mitigate the
impact of one namespace per file, which doesn't have controversial syntax
and hopefully less difficulties in the implementation:
class Fully::Qualified::Class::Name::Declaration { }
same as:
namespace Fully::Qualified::Class::Name;
class Declaration { }
... except of course this allows classes of different namespaces to be
declared in one file. Most namespace-enabled languages consider the above
declarations equivalent. Share your opinions.
Regards,
Stan Vassilev
Re: [PHP-DEV] Alternative to multiple namespaces per file
I would agree with you, I think namespaces should wait for a later version.
Maybe 6 or even later. I believe there are many problems that need to be
sorted be namespaces hit release.
Maybe we could do something like so.
namespace Fully::Qualified::Class::Name class Declaration extends Whatever
implents MyInterface { }
I have reservations in using :: as a resolution operator which can easily
clash with normal class space usage.
Is it too late to have these discussions?? It seems I missed the big
namespace discussions on the mailing list and things have already gone
ahead.
/James
On Sat, May 31, 2008 at 1:51 PM, Stan Vassilev | FM [EMAIL PROTECTED]
wrote:
Hi,
The community wanted namespaces. This is not exactly the namespaces it
wanted, but since they're going in, I think the best course of action is to
solve the big obvious problems so they are at least usable and extendable in
future versions of PHP.
If you have to ask *me* personally, I'd not put namespaces in 5.3 and have
a big discussion about the entire implementation. But alas.
I think those showstopper problems with namespaces are:
1) one namespace per file (look at frameworks like Symphony which compile
their classes together for performance, they will never be able to switch
to, or support namespaces).
2) silent collisions between namespaced function and static method in a
class with the same name (no errors or anything).
3) different resolution rules for userspace and internal functions.
4) subtly different resolution rules for functions/classes/constants
So I'm trying to to address 1) in this thread.
Regards,
Stan Vassilev
- Original Message -
*From:* James Dempster [EMAIL PROTECTED]
*To:* Stan Vassilev | FM [EMAIL PROTECTED]
*Cc:* internals@lists.php.net
*Sent:* Saturday, May 31, 2008 3:43 PM
*Subject:* Re: [PHP-DEV] Alternative to multiple namespaces per file
what I find really annoying about all this namespace stuff, is how would
that be any different from
class Fully_Qualified_Class_Name_Declaration { }
/James
On Sat, May 31, 2008 at 1:10 PM, Stan Vassilev | FM [EMAIL PROTECTED]
wrote:
Hi,
I suppose this has been discussed before, so I'll not repeat reasons
unless requested, but I just want to offer a possible feature to mitigate
the impact of one namespace per file, which doesn't have controversial
syntax and hopefully less difficulties in the implementation:
class Fully::Qualified::Class::Name::Declaration { }
same as:
namespace Fully::Qualified::Class::Name;
class Declaration { }
... except of course this allows classes of different namespaces to be
declared in one file. Most namespace-enabled languages consider the above
declarations equivalent. Share your opinions.
Regards,
Stan Vassilev
Re: [PHP-DEV] Alternative to multiple namespaces per file
On Sat, May 31, 2008 at 6:01 PM, Larry Garfield [EMAIL PROTECTED]
wrote:
On Saturday 31 May 2008, James Dempster wrote:
I would agree with you, I think namespaces should wait for a later
version.
Maybe 6 or even later. I believe there are many problems that need to be
sorted be namespaces hit release.
Maybe we could do something like so.
namespace Fully::Qualified::Class::Name class Declaration extends
Whatever
implents MyInterface { }
I have reservations in using :: as a resolution operator which can easily
clash with normal class space usage.
Is it too late to have these discussions?? It seems I missed the big
namespace discussions on the mailing list and things have already gone
ahead.
/James
Unfortunately it probably is. I recall someone did raise the
ClassName::staticMethod() vs. Namespace::function() collision problem
months
ago, and the response at the time was Pfft, like who uses classes and
functions in the same project, anyway?
(Of course, the answer is well I do but I've long since learned that such
answers don't carry much weight around here, so I mostly just read to see
where the language is going rather than to influence it. So I've just
resigned myself to not being able to use namespaces in PHP.)
It's things like this that make me worry about the future of PHP. The elite
few pushing out lots of developers. :(
If namespaces are going to be problematic then lets wait for version 6.
It would also give more time for namespaces to be thought out properly.
I feel that namespaces in it's current form is a half arsed attempt to force
something into the language.
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the
possession
of every one, and the receiver cannot dispossess himself of it. -- Thomas
Jefferson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
/James
Re: [PHP-DEV] Class Properties in Interfaces?
I would start by saying it's bad design. you should use getters and setters which you can define in you interface -- /James On Tue, Apr 29, 2008 at 11:07 AM, John Carter -X (johncart - PolicyApp Ltd at Cisco) [EMAIL PROTECTED] wrote: Marcus, I understand why Interfaces can't have bodies, but could you explain why Interfaces can't have properties? Thanks, John. -Original Message- From: Marcus Boerger [mailto:[EMAIL PROTECTED] Sent: 29 April 2008 10:46 To: Jeremy Privett Cc: PHP Developers Mailing List Subject: Re: [PHP-DEV] Class Properties in Interfaces? Hello Jeremy, interfaces cannot have properties, nor can they have method bodies - that is the whole purpose of interfafces. We are thinking of adding traits which would allow for both but would treat inheritance differently. Until we get that you would need to provide an abstract interface to access data in the same way. marcus Tuesday, April 29, 2008, 5:31:33 AM, you wrote: Hey list, I was curious what everyone thought of implementing the ability to specify class members in interfaces. I've run into a couple of circumstances where I would like to specify public member names inside of an interface to ensure that these members are accessed in a standard way and to ensure that they exist. Currently, trying to include them in an interface results in *Fatal error*: Interfaces may not include member variables in file/line number. Thoughts? Thanks. -- Jeremy Privett C.E.O. C.S.A. Omega Vortex Corporation http://www.omegavortex.net Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation. Best regards, Marcus -- 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
[PHP-DEV] iconv_mime_encode(), broken Q scheme
iconv_mime_encode seems a bit broken for Q scheme, see http://bugs.php.net/bug.php?id=43314 Could some one please apply the patch to CVS trunk. I've tested and it seems to work. Thanks -- /James
