> +1 from that, fortunately since it's an extension it won't be subject to a
> vote, you can use it or not. :) The core seems to be heavily protected by
> the core developers.
As an APC user, I would be also fine with an extension :-)
@pierre Would it be possible to get windows builds from nikit
On 1/28/2013 2:09 AM, Christian Stoller wrote:
In userland we can only do something like
$str = new String('my_string_class');
echo $str->length();
But that's useless.
It would be great if method calls on primitive types could be supported, like
in Nikic' proof of concept (https://github.com/n
hp.net; Rasmus Lerdorf
Subject: Re: [PHP-DEV] I think that "Function naming inconsistency" bug
deservers more attention
Hi!
> So function aliases, new open tag and deprecation are bad. What about
> the String class?
Design it, write it and we'll see how it works. It
Hi!
> So function aliases, new open tag and deprecation are bad. What about
> the String class?
Design it, write it and we'll see how it works. It's not like the
process should *start* with including it in PHP core. You can write
String class all by yourself, put it on github and once virtually
e
Hi!
> I agree all of that would suck, but would it suck less than the
> alternatives for the most people involved?
Definitely not. I don't think most people involved care if it's called
htmlentities or html_entities. Those are things that you learn once and
don't care about them anymore, and if
Thank you for the link
http://philsturgeon.co.uk/blog/2013/01/php-6-pissing-in-the-wind I
didn't know that... getters/setters were dumped to the garbage...
http://japfan.pl/uploads/media/dacffbe3073882e86057d04266675637.JPG I
will go get a drink... Is there any log of votes? Like reasons why
"no" p
Hi,
Everyone here forgets that there's a little certification
run by some guys named Zend that factor in some of
these things as well.
That's the point of not having consistency? Checking
if some have better memory that others?
Also, I suppose that everyone can afford to look up
things on the P
Hi
2013/1/25 Damian Tylczyński :
> I've seen discussion on reddit
> http://www.reddit.com/r/PHP/comments/174qng/lets_make_phps_function_names_consistent/
There is one really clean solution to this "problem" for the
consistency Guys that tend to complain about PHP endlessly; write the
aliases in P
sorry, I thought it is sth like session_set_save_handler() ...
Regards,
Thomas
On Sat, Jan 26, 2013 at 12:50 PM, Pierre Joye wrote:
> hi,
>
> On Sat, Jan 26, 2013 at 12:37 PM, Thomas Bley wrote:
>>> https://github.com/nikic/scalar_objects
>>
>> I think register_primitive_type_handler() is too e
hi,
On Sat, Jan 26, 2013 at 12:37 PM, Thomas Bley wrote:
>> https://github.com/nikic/scalar_objects
>
> I think register_primitive_type_handler() is too exclusive:
The point of this prototype is to define what is the best APIs we can
create to solve the "inconsistencies"/clean the current API. T
I think register_primitive_type_handler() is too exclusive:
Hi Thomas, as @nikic noted in the description, it's just a proof of
concept.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> https://github.com/nikic/scalar_objects
I think register_primitive_type_handler() is too exclusive:
When I use 2 frameworks in the same code base, one might do
register_primitive_type_handler('string', 'A\StringHandler') and the
other might do register_primitive_type_handler('string',
'B\StringH
I really like the idea
2013/1/26 Pierre Joye :
> hi,
>
> On Sat, Jan 26, 2013 at 10:18 AM, Thomas Bley wrote:
>> So function aliases, new open tag and deprecation are bad. What about
>> the String class?
>> I think there was some "Let's ... start exploring lighter and more
>> approachable ways to
hi,
On Sat, Jan 26, 2013 at 10:18 AM, Thomas Bley wrote:
> So function aliases, new open tag and deprecation are bad. What about
> the String class?
> I think there was some "Let's ... start exploring lighter and more
> approachable ways to attack Unicode" on internals ...
Unicode is a totally d
So function aliases, new open tag and deprecation are bad. What about
the String class?
I think there was some "Let's ... start exploring lighter and more
approachable ways to attack Unicode" on internals ...
Regards,
Thomas
On Sat, Jan 26, 2013 at 9:57 AM, Rasmus Lerdorf wrote:
> Please stop w
On Sat, Jan 26, 2013 at 3:57 AM, Rasmus Lerdorf wrote:
> Please stop with these. We can't keep explaining why function aliases,
> 20 years is a bad idea.
>
> There is a reason that REFERER is still around in HTTP. It is obviously
> not spelled correctly, but the pain of fixing it would far outwe
Please stop with these. We can't keep explaining why function aliases,
http://www.php.net/unsub.php
1) What about using a new open tag?
pos("lo")) {...
echo $s->htmlSpecialChars();
echo $s->convert("ISO-8859-1");
$a = new Array([1,2,3]);
if ($a->contains(1)) {...
Regards,
Thomas
On Sat, Jan 26, 2013 at 3:43 AM, Stas Malyshev wrote:
> Hi!
>
>> Realistically couldn't we just introduce a config
> Now if someone could come up with a third party tool that reads an
> application ... identifies all of the problems ... and at least offer
> pointers to fix them ...
I like that idea! Kinda surprised something like that doesn't already
exist, actually
--Kris
Clint Priest wrote:
So I think we should try to keep PHP behavior unified and avoid
behavior-modifying switches as much as possible.
I agree all of that would suck, but would it suck less than the alternatives for
the most people involved?
E_STRICT is bad enough and is one of the switches you
Here I am, ten years later, and the same issue is being rehashed just as it
was when it was brought up ten years ago.
Over those ten years, things have slowly gotten better, but the underlying
issue remains the same. PHP is glue. PHP has not taken the path of
re-naming everything to conform to a n
On 1/25/2013 8:43 PM, Stas Malyshev wrote:
Hi!
Realistically couldn't we just introduce a configuration parameter to
keep "the inconsistent parameter order," perhaps along with a script to
suggest the changes needed to bring some code up to speed?
People think that "introduce a configuration
Hi!
> Realistically couldn't we just introduce a configuration parameter to
> keep "the inconsistent parameter order," perhaps along with a script to
> suggest the changes needed to bring some code up to speed?
People think that "introduce a configuration parameter" is a solution to
almost any
On 1/25/2013 7:02 PM, Stas Malyshev wrote:
Hi!
Well, how about renaming the functions, create aliases for BC and throw
E_DEPRECATED or E_STRICT on their usage? And write a PEAR script bundled
with the distribution to migrate to the new convention?
Well, the problem with these things is this:
Hi!
> Well, how about renaming the functions, create aliases for BC and throw
> E_DEPRECATED or E_STRICT on their usage? And write a PEAR script bundled
> with the distribution to migrate to the new convention?
Well, the problem with these things is this: suppose you have testing
suite that verif
On Fri, Jan 25, 2013 at 2:04 PM, Rasmus Lerdorf wrote:
> On 01/25/2013 10:55 AM, Seva Lapsha wrote:
> > Well, how about renaming the functions, create aliases for BC and throw
> > E_DEPRECATED or E_STRICT on their usage? And write a PEAR script bundled
> > with the distribution to migrate to the
Yes, it's extremely useful, especially because most of the php developers
are developing under Linux and most of them are coming from C and many
other languages. Give ma a break... Second thing, we're afraid of throwing
deprecated errors. Let's see the case. On production machines there are
errors
On 01/25/2013 10:55 AM, Seva Lapsha wrote:
> Well, how about renaming the functions, create aliases for BC and throw
> E_DEPRECATED or E_STRICT on their usage? And write a PEAR script bundled
> with the distribution to migrate to the new convention?
Throwing warnings on perfectly working code is r
Well, how about renaming the functions, create aliases for BC and throw
E_DEPRECATED or E_STRICT on their usage? And write a PEAR script bundled
with the distribution to migrate to the new convention?
On Fri, Jan 25, 2013 at 1:41 PM, Stas Malyshev wrote:
> Hi!
>
> > I've seen discussion on reddi
Hi!
> I've seen discussion on reddit
> http://www.reddit.com/r/PHP/comments/174qng/lets_make_phps_function_names_consistent/
> where many people are surprised why PHP can't have this done. Why
> inconsistency is something that we want to keep because of backward
> compatibility. PHP already introd
2013/1/25 Pierre Joye
> hi,
>
> On Fri, Jan 25, 2013 at 3:37 PM, Martin Keckeis
> wrote:
> > Hello,
> >
> > you are right Damian.
> >
> > Also today on a german page:
> >
> http://it-republik.de/php/news/Machen-wir-das-Namensschema-der-PHP-Funktionen-einheitlich%21-066539.html
> >
> > Relating t
hi,
On Fri, Jan 25, 2013 at 3:37 PM, Martin Keckeis
wrote:
> Hello,
>
> you are right Damian.
>
> Also today on a german page:
> http://it-republik.de/php/news/Machen-wir-das-Namensschema-der-PHP-Funktionen-einheitlich%21-066539.html
>
> Relating to this bug report:
> https://bugs.php.net/bug.php
Hello,
you are right Damian.
Also today on a german page:
http://it-republik.de/php/news/Machen-wir-das-Namensschema-der-PHP-Funktionen-einheitlich%21-066539.html
Relating to this bug report:
https://bugs.php.net/bug.php?id=52424
Best regards
Martin
I've seen discussion on reddit
http://www.reddit.com/r/PHP/comments/174qng/lets_make_phps_function_names_consistent/
where many people are surprised why PHP can't have this done. Why
inconsistency is something that we want to keep because of backward
compatibility. PHP already introduced many backw
34 matches
Mail list logo
