Re: [PHP-DEV] any blogs?
There is a Planet PHP which aggregates many blogs articles written by contributors: http://planet-php.net/ Peter On Thu, Mar 8, 2012 at 09:58, adit adit wrote: > Hi, > > Can you tell me which one of you guys has any blogs on which i can read > about the php internals? > I've already subscribed to laruence's , problem is google translate is > pretty bad at translating chinese > > Thanks, >
Re: [PHP-DEV] Make try/catch brackets optinal
On Thu, Jul 19, 2012 at 11:06 AM, Rafael Dohms wrote: > On Thu, Jul 19, 2012 at 12:03 PM, Charlie Somerville < > char...@charliesomerville.com> wrote: > > > This has code readability problem written all over it. When maintaining > it > > also has problems, like with the bracket-less if's. > > You would need to add brackets if you add an extra line here, as well as > > you might get unexpected behaviour of you forget to > > add brackets in that case. > > > > I've often heard people make this argument, but I've never found it to be > > a real concern in practise. > > > > Is this really such a common problem? > > > > I have seen this problem happen, people losing time trying to figure out > what is wrong only to find > its a missing bracket. > As Paul said, this is bug-prone. > Other bracket-less blocks allow authors to shoot themselves in the foot equally so, yet PHP supports these as well. The actual problem here is an inconsistency in the parser, which I'd consider to be a bug. Peter > -- > Rafael Dohms > PHP Evangelist and Community Leader > http://www.rafaeldohms.com.br > http://www.phpsp.org.br >
[PHP-DEV] Re: Type hinting revisited for PHP 5.3
Hello,
For what it's worth, a large +1 from me.
One concern I do have, however, is that the addition of scalar type hints
will put more attention to the lack of method overloading. Right now methods
can accept multiple values due to the type-lessness, and while it will
remain a possibility, code with type-hints usually is a lot clearner. To
demonstrate:
class Example {
public function setValue (int $value) {}
public function setValue (string $value) {}
}
While there are two obvious solutions for this (not using type-hinted
parameters and using setIntValue/setStringValue) I think inclusion of a
patch like this would be a good moment to overthink overloading like this.
Peter
"Ilia Alshanetsky" wrote in message
news:fc14fafe-6785-4067-9b49-9fc14f159...@prohost.org...
I've taken a few hours this morning to port my 5.2 type hinting patch to
5.3. In recognition of a need for a more 'flexible' numeric type I've
introduced (numeric) type hint that would allow bool/int/float data types
as well as a string containing a numeric entity as identified by
is_numeric_string(). For completion i've also added (scalar) data type
that will allow any scalar data element.
The patch is available here: http://ia.gd/patch/type_hint_53.txt
It should be noted that this patch is fully compatible with opcode caches
and and requires no changes on the part of an opcode cache such as APC to
work.
My hope is that the latest changes will allow this to become a standard
part of PHP.
Ilia Alshanetsky
P.S.
It should be noted that this is not the first idea for type hints, that
credit goes to Hannes Magnusson who had posted a similar patch on the
internals list back in 2006. Also, back in 2008 Felipe Pena wrote a type
hinting patch for PHP that is available on wiki.php.net.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ereg deprecation?
2010/5/31 Felipe Pena > > 2010/5/31 Johannes Schlüter > > > On Mon, 2010-05-31 at 14:09 -0300, Felipe Pena wrote: > > > Hi, > > > > > > 2010/4/28 Michael Maclean > > > > > > > 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? > > > > > > > > > > > I think make no sense to keep it deprecated. > > > > > > Here's a patch for undeprecate ext/ereg in 5_3 and trunk: > > > http://felipe.ath.cx/diff/undeprecate-ereg.diff > > > > > > Any objection? If no, I'll commit it in soon. > > > > I still won't recommend using ereg - the missing binary-safety causes > > quite some broken checks ... is there anything that can be done which > > can't be done using pcre? If not: Less code to maintain -> less > > trouble :-) > > > > > I also won't recommend using ereg, I just thought the unique reason to > deprecate it was the unicode stuff, hence wouldn't make sense to keep it > deprecated... But as there are others motivations, I prefer leave as is too. > > -- > Regards, > Felipe Pena Undeprecating the ereg extension now will not only cause confusion, because it has been deprecated for quite a while already, but it might also become a liability if Unicode or any similar non-compatible system might ever be included in the future. PCRE simply is faster under most conditions, more consistent and since a significant part of PHP Developers will also use Javascript, likely to be more appropriate for the web. Companies and individuals have been adjusting their scripts in favor of PCRE[1][2][3], undeprecating the extension seems senseless at this point. I do think Philip Olson's proposal of adding a compile-time flag for disabling ereg altogether is a good idea, as it would be the next step in moving ereg away from PHP's core. Regards, Peter Beverloo [1] https://drupal.org/node/530940 [2] http://bugs.typo3.org/view.php?id=9994 [3] http://www.mantisbt.org/bugs/view.php?id=10974 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
2010/11/27 Johannes Schlüter
>
> Hi,
>
> every now and then while writing classes I forget to add the "function"
> keyword between my visibility modifier and the method name in a class
> declaration. I don't think it is required for readability and it is not
> needed by the parser to prevent conflicts, I therefore propose the
> following RFC incl. patch to allow writing
>
> class Foo {
> public bar() {
> echo "Hello World";
> }
> }
>
> Without T_FUNCTION token. In my opinion an access modifier /public,
> private protected, static, final) should still be required for keeping
> readability.
>
> RFC: http://wiki.php.net/rfc/optional-t-function
> Patch: http://schlueters.de/~johannes/php/zend_optional_t_function.diff
>
> johannes
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
Considering variables are prefixed and constants don't have visibility
modifiers, functions in classes would still be easily recognizable.
Syntax analyzing IDEs generally don't rely on single keywords and will
be able to adapt a change like this without too much hassle.
On top of that, seeing that functions in classes are generally
referred to as methods, I believe removing the requirement would
improve consistency.
+1 from me.
Kind regards,
Peter Beverloo
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On Thu, Dec 2, 2010 at 14:06, Patrick ALLAERT wrote: > 2010/12/2 André Rømcke : >> On Thu, Dec 2, 2010 at 10:34 AM, Patrick ALLAERT >> wrote: >>> Shouldn't we get rid of that kind of pre-PHP5 stuff _before_ >>> introducing the possible omission of T_FUNCTION? >> >> Why? >> This will break lots of code, does it improve anything while at it? Is 'var' >> hindering anything? Is it taking up a lot of code? >> If it is removed then that should be in trunk aka "6.0" the 2nd , and not in >> 5.x. > > It should of course not appear in a 5.x release! But sounds like > current trunk can't be anyway. > > +1 for removing T_VAR and making T_FUNCTION optional in a major release. > -1 otherwise. > > -- > Patrick Allaert > --- > http://code.google.com/p/peclapm/ - Alternative PHP Monitor > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > An entire major version relied on the usage of T_VAR within classes. Many people still use it today. I therefore am strongly against removing T_VAR, considering it would break huge amounts of userland code. In either case, it should be deprecated with an E_DEPRECATED warning during at least another major before it gets removed. Regards, Peter Beverloo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Making T_FUNCTION optional in method declarations
On Thu, Dec 2, 2010 at 17:07, la...@garfieldtech.com wrote: > On 12/2/10 7:51 AM, Patrick ALLAERT wrote: > >>>> +1 for removing T_VAR and making T_FUNCTION optional in a major release. >>>> -1 otherwise. > > I am still firmly -1 on removing T_FUNCTION for methods. > >>>> -- >>>> Patrick Allaert >>>> --- >>>> http://code.google.com/p/peclapm/ - Alternative PHP Monitor >>>> >>>> -- >>>> PHP Internals - PHP Runtime Development Mailing List >>>> To unsubscribe, visit: http://www.php.net/unsub.php >>>> >>> >>> An entire major version relied on the usage of T_VAR within classes. >>> Many people still use it today. >>> I therefore am strongly against removing T_VAR, considering it would >>> break huge amounts of userland code. >> >> If people migrate to a major version of PHP> 5 they should at least >> stop relying on PHP 4 features still valid thanks to BC consideration. >> >>> In either case, it should be >>> deprecated with an E_DEPRECATED warning during at least another major >>> before it gets removed. >> >> This makes much sense! > > Correct me if I'm wrong, but isn't T_VAR on class members already an > E_STRICT warning? I thought it was... > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > No, the warning was removed in PHP 5.1.3. Regards, Peter Beverloo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] patch review
2011/4/3 Tomas Brastavičius : > Hi, > > can somebody review the following patch: > http://bugs.php.net/bug.php?id=54369 > > I am willing the bug is fixed in the next PHP release and ready to do a > job if something is wrong with the patch. > > Thank you > > Regards, > Tomas > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > The parsing change you are proposing is invalid per RFC 1738. The destination (hostname and port) and the url-path are to be divided by a slash, whereas the query string and the fragment are part of the latter. See sections 3.3 and 5 of the RFC[1] for more information. Web browsers and other user-facing software may accept this, but will immediately update the displayed URL to a valid variant by inserting the slash. Regards, Peter Beverloo [1] http://tools.ietf.org/html/rfc1738.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
