Ok, I've made a proof-of-concept patch here: https://gist.github.com/1929587
Note that there are still a few memory leaks in there that would need
to be cleaned up, but I just wanted to make a really quick POC before
cleaning anything up to make it worthy of addition...
Another patch would need t
Lol you're making me feel like an old fogey! I've always just used
email/listservs (or carrier pigeon if I'm getting a busy signal dialing in
to AOL).
Either way, I think we should give serious thought to how we move forward
on this, as it could wind up being a blueprint for future PHP feature
co
I don't think we need yet another list. That said, I think that some features
(such as weak typing) would benefit greatly from having a small body of people
get together and flesh out a proposal together before presenting it for
sacrifice on the altar of public discussion. Part of the value in t
On Tue, Feb 28, 2012 at 10:38 AM, Xinchen Hui wrote:
> On Tue, Feb 28, 2012 at 1:10 AM, Anthony Ferrara wrote:
>> I initially looked at the final fix when I discovered the issue.
>> Follow me out on this. This is the current code as-implemented in
>> r323563:
>>
>> 265 zval *o
On Tue, Feb 28, 2012 at 1:10 AM, Anthony Ferrara wrote:
> I initially looked at the final fix when I discovered the issue.
> Follow me out on this. This is the current code as-implemented in
> r323563:
>
> 265 zval *obj;
> 266 MAKE_STD_ZVAL(obj);
> 267
On 02/27/2012 01:12 PM, William A. Rowe Jr. wrote:
On 2/27/2012 6:58 AM, jpauli wrote:
Recently we had a bug with the new Apache 2.4 API where apxs doesn't answer
about the MPM configuration anymore, leading to a ZTS build by default.
This bug has now been fixed, was https://bugs.php.net/bug
Are there any final thoughts, objections, last-minute change requests,
etc? Looks like we're all pretty much in agreement so I'll initiate the
vote if I don't hear anything.
--Kris
On Mon, Feb 27, 2012 at 4:06 PM, Kris Craig wrote:
> Hmm didn't know that. I stand corrected!
>
> That being sa
Hmm didn't know that. I stand corrected!
That being said, unless we're talking about dropping the configure script
altogether in favor of reliance on RPM's and repos, this RFC is still a
no-brainer. =)
--Kris
On Mon, Feb 27, 2012 at 3:56 PM, Gergo Erdosi wrote:
> No, you don't. Since CentOS
No, you don't. Since CentOS 5.6, PHP 5.3 is part of the base
repository. You are right, "yum install php" installs 5.1, but you
don't have to download anything to install 5.3, just type "yum install
php53".
Gergo Erdosi
On Tue, Feb 28, 2012 at 12:06 AM, Kris Craig wrote:
> Yes but you have to d
Lol I'm not worried. Gribblefritz may be a psychopatic serial killer, but
he's also my personal bodyguard. What could possibly go wrong?
--Kris
2012/2/27 Ángel González
> Kris, go out for a walk. We don't need fake
> stress after the real one :)
>
> Yes, it's midnight here, but who cares?
>
Kris, go out for a walk. We don't need fake
stress after the real one :)
Yes, it's midnight here, but who cares?
That you are afraid of going out at night? Because
you had a bad experience with a serial killer?
Oh, well...
PS: This is what I called 'sane weak typing' in the other
thread before y
I agree. What does everyone think about the idea of creating a new list
specifically discussion of new feature ideas? The idea could be announced
on the Internals list with a link to the discussion on the other list.
That way, the noise ratio would be reduced and only those who are
interested in
On 27/02/12 22:52, Anthony Ferrara wrote:
> Ferenc,
>
> Thanks for the comments!
Thanks from me, too.
And thanks to you, Anthony if you get to summarise that.
>> There were ideas, but they didn't have enough traction.
>> IMO we can't have a proper solution without changing the existing behavior
On 27/02/12 19:22, Richard Lynch wrote:
>>> I'm not so sure about that. In a well-written web application, you
>>> would
>>> typically convert them on the first layer, when receiving from the
>>> web.
>>> On next usages, your int variables are usually ints already.
> Afraid not.
>
> It turns out th
Yes but you have to download those RPM's manually. If you just use the
default repo (i.e. "yum install php") as most sysadmins do, you're gonna
get something MUCH older than that. Plus there are still occasions where a
manual build is preferable to using an RPM.
--Kris
On Mon, Feb 27, 2012 at
No that's like a million times worse, Larry!! Gaylord T. Gribblefritz III
was a serial killer who terrorized the midwest for over 40 years! That
monster murdered me and my entire family! He would sell milk laced with
sleeping pills to school children then take them back to his secluded
ranch, wh
On 27/02/12 20:05, Richard Lynch wrote:
> You are correct.
>
> I'd have to come up with some OTHER scenario not involving fatal
> error, such as:
>
> strict $db = new DB();
>
> and your database being down, unavailable, or connection parameters
> being wrong.
>
> The principle remains.
>
> You prob
On Mon, Feb 27, 2012 at 11:16 PM, Kris Craig wrote:
> I've got a CentOS 5.7 VM running at work and the PHP package returned by
> yum is 5.1.6. Don't have my Ubuntu box with me at the moment but I'm
> pretty sure it's 5.1.x as well.
>
> You probably have rpmforge or CentALT enabled and that's whe
That's going to get turned into the "real" name if used. I suggest instead:
Gribblefritz.
Gribble typing: the type handling that PHP does today in 5.3/5.4 for
scalar values.
Fritz typing: Some as-yet-undefined type handling that is pickier than
Gribble typing, but how much pickier is unclea
> Would "firm" work better?
>
> --Kris
As a working name that would be fine. Of course, if this discussion moves to a
sub-group that becomes less critical since it would be less likely for people
to jump in the middle and misunderstand the terms.
John Crenshaw
Priacta, Inc.
--
PHP Internals
I think this is the main reason for differentiating between "strong" (or
whatever word is appropriate) and "weak." The developer may very well want
their script to blow-up in such a case.
I would liken this to the fact that we have both an "include" statement and
a "require" statement. One is re
Would "firm" work better?
--Kris
On Mon, Feb 27, 2012 at 2:27 PM, John Crenshaw wrote:
> > -Original Message-
> > From: Kris Craig [mailto:kris.cr...@gmail.com]
> >
> > Now, to rewind a bit past the latest chunk of "I hate this idea"
> posts
> >
> > I'd like to suggest a new term:
Inline
> -Original Message-
> From: Richard Lynch [mailto:c...@l-i-e.com]
>
> On Mon, February 27, 2012 1:15 pm, Kris Craig wrote:
> > Now, to rewind a bit past the latest chunk of "I hate this idea"
> > posts
> >
> > I'd like to suggest a new term: "strong".
> >
> > This term would
> -Original Message-
> From: John LeSueur [mailto:john.lesu...@gmail.com]
>
> Maybe this discussion should start from the end of the last discussion on
> non-strict type hints, where really smart people came up with some options to
> handle the conversion:
>
> https://wiki.php.net/rfc/
> -Original Message-
> From: Kris Craig [mailto:kris.cr...@gmail.com]
>
> Now, to rewind a bit past the latest chunk of "I hate this idea" posts
>
> I'd like to suggest a new term: "strong".
>
> This term would be similar to "weak", except with a few key differences:
>
> ...
>
> So
I've got a CentOS 5.7 VM running at work and the PHP package returned by
yum is 5.1.6. Don't have my Ubuntu box with me at the moment but I'm
pretty sure it's 5.1.x as well.
You probably have rpmforge or CentALT enabled and that's where it's pulling
the newer build. But even then, the latest one
>
>
> @Lester Generally, this is a problem that surfaces in manual PHP builds.
> You're correct in that the packaged repos tend to handle all that stuff for
> you anyway. However, these repos are rarely updated (I think CentOS and
> Ubuntu are both still stuck on 5.1), so it's often necessary to b
On Mon, Feb 27, 2012 at 5:10 PM, Richard Lynch wrote:
> On Mon, February 27, 2012 9:37 am, Simon Schick wrote:
> > The development of the unicode-as-default-charset should really be
> > done
> > within the next release coming after 5.4
> > I heared somewhere that it's nearly done ...
> > I would
Ferenc,
Thanks for the comments!
On Mon, Feb 27, 2012 at 4:09 PM, Ferenc Kovacs wrote:
>
>
> On Mon, Feb 27, 2012 at 6:38 PM, Anthony Ferrara
> wrote:
>>
>> > no, it is: "come back after you did your homework, and you can provide
>> > new
>> > arguments to the discussion"
>>
>>
>> To be complet
John Crenshaw wrote:
Wait, is the default going to be "Unicode" (wide, always 2 bytes per char, I.E. more
memory consumption) or "UTF-8" (1 byte for the first 127, more bytes for wider text,
mostly unchanged memory consumption)? I thought it was originally a conversion to Unicode, but that
was
Yeah again sorry about the 1. Another dyslexic moment on this end lol.
I don't care about the specific terminology we use, just so long as it
makes sense and people aren't confusing it with something else. I
differentiated between strong and weak in order to accommodate the looser
functionality
Kris Craig wrote:
@Lester Generally, this is a problem that surfaces in manual PHP builds.
You're correct in that the packaged repos tend to handle all that stuff for
you anyway. However, these repos are rarely updated (I think CentOS and
Ubuntu are both still stuck on 5.1), so it's often necess
On Mon, Feb 27, 2012 at 8:15 PM, Kris Craig wrote:
> Now, to rewind a bit past the latest chunk of "I hate this idea" posts
>
> I'd like to suggest a new term: "strong".
>
I think it would be better if we could not introduce terms for new
definition if that term is already used in the vocab
Lol be my guest. You won't have much success though because I have not
relied upon hyperbole and logical fallacies to substantiate my arguments.
On the contrary, my argument thus far can be summarized thusly:
- The issue of type hinting isn't going to go away, otherwise it would
have by no
On Mon, Feb 27, 2012 at 7:53 PM, Kris Craig wrote:
> +1 what Anthony said.
>
> Guys, seriously. Some of these responses have been downright rude and
> inappropriate for a constructive dialogue. Please do not pollute this
> thread with cliche, "Just find another language and get out!" posts. It
On 2/27/2012 6:58 AM, jpauli wrote:
> PHP through mod_php on Linux should compile without ZTS.
>
> configure script searches for apxs binary and tries to invoque "apxs -q
> MPM" to figure out what MPM has been compiled in Apache for the TS flag to
> be defined or not (thus, activating PHP ZTS, or
On Mon, Feb 27, 2012 at 6:38 PM, Anthony Ferrara wrote:
> > no, it is: "come back after you did your homework, and you can provide
> new
> > arguments to the discussion"
>
>
> To be completely fair, I did homework on this. I went back to 2000 on
> marc.info's archives and read almost all of the 4
Wait, is the default going to be "Unicode" (wide, always 2 bytes per char, I.E.
more memory consumption) or "UTF-8" (1 byte for the first 127, more bytes for
wider text, mostly unchanged memory consumption)? I thought it was originally a
conversion to Unicode, but that was scrapped? Can someone
I'm not sure what the precedent is for creating a separate list fork for a
specific topic. Can one of you who knows the answer to that respond to
Richard's suggestion?
As for an RFC, I completely agree. However, it's still a bit too vague to
create an RFC that would be of any value. We at least
Rich,
I appreciate the candid and honest nature of your reply, while
maintaining civility. This list needs more of that. Further replies
inline:
On Mon, Feb 27, 2012 at 1:54 PM, Richard Lynch wrote:
> On Mon, February 27, 2012 9:20 am, Anthony Ferrara wrote:
>>> I have to say that no matter how
Hei, Richard
I've looked into the php.ini.* files of PHP 5.4 for windows and saw the
following line in *production*:
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors = On
log_errors = On
and the following line in *development*:
error_reporting = E_ALL
display_errors = Off
log_er
Hi Richard,
I'm a little confused. Showing E_NOTICE errors is already the default
with both php.ini-* files. What does this RFC change? Are you proposing
that the PHP default value (without a php.ini) be modified?
; error_reporting
; Default Value: E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATE
On Mon, 2012-02-27 at 21:05 +0100, Gustavo Lopes wrote:
> On Mon, 27 Feb 2012 20:09:08 +0100, Johannes Schlüter
> wrote:
>
> > On Mon, 2012-02-27 at 13:05 -0600, Richard Lynch wrote:
> >>
> >> I'd have to come up with some OTHER scenario not involving fatal
> >> error, such as:
> >>
> >> strict
On Mon, 27 Feb 2012 20:09:08 +0100, Johannes Schlüter
wrote:
On Mon, 2012-02-27 at 13:05 -0600, Richard Lynch wrote:
I'd have to come up with some OTHER scenario not involving fatal
error, such as:
strict $db = new DB();
The example is wrong. The new operator will always return an instan
On Mon, 27 Feb 2012 20:09:08 +0100, Johannes Schlüter
wrote:
On Mon, 2012-02-27 at 13:05 -0600, Richard Lynch wrote:
I'd have to come up with some OTHER scenario not involving fatal
error, such as:
strict $db = new DB();
The example is wrong. The new operator will always return an instan
On Mon, February 27, 2012 1:33 pm, Kris Craig wrote:
> I think it's a good idea, though I'm not sure it should be done in the
> production one as well. I'm not sure, but I think these errors are
> generally suppressed in production because of potential security
> concerns
> involved in making thos
On Mon, February 27, 2012 1:22 pm, Kris Craig wrote:
> Now that you've voiced your opposition, can we please dedicate this
> topic
> to discussing how this can be done? If you think we're wasting our
> time,
> then ok; it's our time to waste. I'd be happy to take you up on your
> challenge to try
@Richard I think, briefly, something like that was implemented. However,
it was reverted soon after because it changed the default behavior of
configure. This was discovered to be a problem after people realized that,
if -a is not specified, APXS will not only skip writing the LoadModule
line, bu
On Mon, February 27, 2012 1:15 pm, Kris Craig wrote:
> Now, to rewind a bit past the latest chunk of "I hate this idea"
> posts
>
> I'd like to suggest a new term: "strong".
>
> This term would be similar to "weak", except with a few key
> differences:
>
>- Weak would behave very much like
On Mon, Feb 27, 2012 at 12:15 PM, Kris Craig wrote:
> Now, to rewind a bit past the latest chunk of "I hate this idea" posts
>
> I'd like to suggest a new term: "strong".
>
> This term would be similar to "weak", except with a few key differences:
>
> - Weak would behave very much like Arv
I think it's a good idea, though I'm not sure it should be done in the
production one as well. I'm not sure, but I think these errors are
generally suppressed in production because of potential security concerns
involved in making those errors public.
I would suggest amending the RFC so that it o
Ok, fine. We get it. You don't think this can be done. Duly noted.
Now that you've voiced your opposition, can we please dedicate this topic
to discussing how this can be done? If you think we're wasting our time,
then ok; it's our time to waste. I'd be happy to take you up on your
challenge
On Mon, 2012-02-27 at 13:05 -0600, Richard Lynch wrote:
>
> I'd have to come up with some OTHER scenario not involving fatal
> error, such as:
>
> strict $db = new DB();
The example is wrong. The new operator will always return an instance of
the given class (or there will be an exception). Use
Err typo correction: "Strong, on the other hand, would throw a fatal error
if you attempted to pass an incompatible value to *a variable." (not "an
array")
--Kris
On Mon, Feb 27, 2012 at 11:15 AM, Kris Craig wrote:
> Now, to rewind a bit past the latest chunk of "I hate this idea" posts
>
On Mon, February 27, 2012 11:38 am, Anthony Ferrara wrote:
> Discussed to death. Yet only one time before (discussing a specific
> patch)...
Did you go back to the old, old, old PHP list (and was it PHP-dev back
then?), before it split into php-general and php-internals and php-*,
back when there
Now, to rewind a bit past the latest chunk of "I hate this idea" posts
I'd like to suggest a new term: "strong".
This term would be similar to "weak", except with a few key differences:
- Weak would behave very much like Arvids suggested in his earlier post;
i.e. if the variable is an
On 2012-02-27, "Richard Lynch" wrote:
> On Mon, February 27, 2012 9:20 am, Anthony Ferrara wrote:
> > > I have to say that no matter how much a luv my OOP, turning every
> > > built-in type into an Object is just a Bad Idea...
> > >
> > > It's a form of bloat on RAM and CPU with minimal added valu
On Mon, February 27, 2012 10:45 am, Ángel González wrote:
> On 27/02/12 17:19, Richard Lynch wrote:
>> PRESUMPTION:
>>
>> *ANY* strict datatype could also be NULL, to represent a failure
>> condition...
>>
>> Otherwise, when you are out of RAM:
>> strict $o = new Object(); //violates strict, becaus
On Mon, February 27, 2012 9:20 am, Anthony Ferrara wrote:
>> I have to say that no matter how much a luv my OOP, turning every
>> built-in type into an Object is just a Bad Idea...
>>
>> It's a form of bloat on RAM and CPU with minimal added value, imho.
> Re-read what I had written. I never said
+1 what Anthony said.
Guys, seriously. Some of these responses have been downright rude and
inappropriate for a constructive dialogue. Please do not pollute this
thread with cliche, "Just find another language and get out!" posts. It
doesn't add anything to the conversation and instead just cre
Anthony,
Remember you're dealing with the internals list. :)
I kind of like the idea of having long proper discussions on a
particular topic. But let's face it, that's an utopic view (at best)!
Even if optional, and even if backwards compatible, there are a number
of things that will be quite har
On Fri, February 24, 2012 5:15 pm, Larry Garfield wrote:
> On 2/24/12 4:55 PM, Jeremiah Dodds wrote:
>
>>> Except that per HTTP, GET and POST are completely different
>>> operations. One
>>> is idempotent and cacheable, the other is not idempotent and not
>>> cacheable.
>>> I very much care whic
>> I'm not so sure about that. In a well-written web application, you
>> would
>> typically convert them on the first layer, when receiving from the
>> web.
>> On next usages, your int variables are usually ints already.
Afraid not.
It turns out that PHP, on 32-bit hardware, converting large BIGI
On Mon, 2012-02-27 at 10:43 -0600, Richard Lynch wrote:
> I believe core PHP is all in C.
Correct.
> Extensions, however, could be in C++
Correct.
> And if one extension has forgotten to edit the Makefiles to do
> -lstdc++ I presume that it could be the cause.
Nobody should directly link -lstd
On Sat, February 25, 2012 7:58 pm, Kris Craig wrote:
> On Sat, Feb 25, 2012 at 4:54 PM, Stas Malyshev
> wrote:
>
>> Hi!
>>
>>
>> I'm well aware that this has been discussed before, Stas. However,
>>> you're mischaracterizing those previous conversations. It has
>>> never
>>> been proven that opt
> no, it is: "come back after you did your homework, and you can provide new
> arguments to the discussion"
To be completely fair, I did homework on this. I went back to 2000 on
marc.info's archives and read almost all of the 400 posts matching the
search http://marc.info/?l=php-internals&w=2&r=
On Mon, Feb 27, 2012 at 6:17 PM, Richard Lynch wrote:
> On Fri, February 24, 2012 4:48 pm, Ronald Chmara wrote:
> > On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield
> > wrote:
> >>> To me, it's just a request for some content, and in a REST API
> >>> that's
> >>> read-only, I just don't care if t
On Fri, February 24, 2012 4:33 pm, Kris Craig wrote:
> I hear that a lot; i.e. "If you want static typing, use Java."
>
> Unfortunately, that dismissive answer has not worked too well over the
> years, has it? People are still clamoring for this, and I think
> making
> some very valid arguments th
On Fri, February 24, 2012 4:48 pm, Ronald Chmara wrote:
> On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield
> wrote:
>>> To me, it's just a request for some content, and in a REST API
>>> that's
>>> read-only, I just don't care if the consumer sends their request as
>>> GET or POST. I'll cheerfully
On Fri, February 24, 2012 4:40 pm, Larry Garfield wrote:
> On 2/24/12 4:34 PM, Richard Lynch wrote:
>> On Fri, February 24, 2012 4:16 pm, Larry Garfield wrote:
>>> On 2/24/12 3:28 PM, Richard Lynch wrote:
> Except that per HTTP, GET and POST are completely different
> operations.
> One is idempo
I initially looked at the final fix when I discovered the issue.
Follow me out on this. This is the current code as-implemented in
r323563:
265 zval *obj;
266 MAKE_STD_ZVAL(obj);
267 if (Z_OBJ_HANDLER_P(*arg, cast_object)(*arg, obj, type
>
>
> Now strings. There are two different kinds of strings.
> The first one $age = $_POST['age'] is the kind of string that you want to
> treat as a number. And that's fine.
>
> But you also have $name = $_POST['name'] // 'John Doe' which is wrong
> to treat as a the same as $age.
>
>
php doesn't
On Fri, February 24, 2012 6:14 pm, Kris Craig wrote:
> No, it happens and it's even clearly documented in APXS.
>
> Basically, if you specify the "-a" option in APXS, it overwrites your
> httpd.conf (or apache.conf or whatever it is on your system) and adds
> the
> LoadModule line to it. In PHP's
On Mon, Feb 27, 2012 at 5:16 PM, Michael Morris wrote:
> So the official response is "get lost"?
>
>
no, it is: "come back after you did your homework, and you can provide new
arguments to the discussion"
> I don't know about the internals implications. But from an external
> API standpoint I
On 27/02/12 16:47, Paul Dragoonis wrote:
> 2012/2/27 Johannes Schlüter
>> Hi,
>>
>> PHP is no strickt-typed language. Changing this is a massive change, if
>> you want to go there: There are plenty of other languages.
>>
>> If you want this to be an optional feature:
>> a) It's not optional (one h
On Mon, Feb 27, 2012 at 17:43, Richard Lynch wrote:
> On Sun, February 26, 2012 1:19 pm, Tom Boutell wrote:
>> Bump - this is still a live issue on Ubuntu 11.10, for instance.
>>
>> I just hacked my Ubuntu PHP-from-source installer to touch up the
>> Makefile by prepending -lstdc++ to EXTRA_LIBS.
On Sun, February 26, 2012 1:19 pm, Tom Boutell wrote:
> Bump - this is still a live issue on Ubuntu 11.10, for instance.
>
> I just hacked my Ubuntu PHP-from-source installer to touch up the
> Makefile by prepending -lstdc++ to EXTRA_LIBS. That does the job.
>
> Which I knew more about autoconf, I'
On 27/02/12 17:19, Richard Lynch wrote:
> PRESUMPTION:
>
> *ANY* strict datatype could also be NULL, to represent a failure
> condition...
>
> Otherwise, when you are out of RAM:
> strict $o = new Object(); //violates strict, because Object HAS to be
> NULL, as there is no RAM left for it to be an
Sent from my iPad
在 2012-2-28，0:10，Anthony Ferrara 写道：
> Out of curiosity, why are you changing it to copy the object for the
> result of the cast operation? cast_object should init the result
> zval, so why go through the step of copying the starting object to
plz look at the final fix： r32356
On 27/02/12 02:44, John Crenshaw wrote:
> If we can agree on some basic terminology I think it would move things
> forward considerably. I propose these terms:
> - "Strict Typing" means the super strict old C style typing that has been
> proven to be ridiculous in this environment because of the
On Mon, February 27, 2012 8:29 am, Michael Morris wrote:
> Both of these must be
> declared formally (otherwise PHP assumes scalar)
I believe you mean "dynamic" or "loose" datatyping.
Scalar would imply that you couldn't do this:
array $a = array(); //force $a to always be array, and never anyth
So the official response is "get lost"?
I don't know about the internals implications. But from an external
API standpoint I see no problem in allowing programmers who want to
strictly enforce a variable's datatype to do so. Legacy code would
not be affected unless it was trying to use the new r
On Mon, February 27, 2012 9:37 am, Simon Schick wrote:
> The development of the unicode-as-default-charset should really be
> done
> within the next release coming after 5.4
> I heared somewhere that it's nearly done ...
> I would have happily seen it in 5.4 but as this release is late right
> now
Out of curiosity, why are you changing it to copy the object for the
result of the cast operation? cast_object should init the result
zval, so why go through the step of copying the starting object to it?
Wouldn't it be easier just to do:
if (Z_OBJ_HANDLER_PP(arg, cast_object)) {
On 27/02/12 01:33, Kris Craig wrote:
> Exactly, hence why I'm still on the fence with that. I was hoping for some
> further discussion though to see if anyone can think of a way around that,
> though admittedly nothing comes to my mind.
>
> --Kris
That's why I mentioned the possibility of having s
As promised in another thread, I have created a formal RFC on the
topic of including E_NOTICE in the default php.ini.* files.
Please note that I am specifically not proposing E_STRICT nor
E_DEPRECATED in this RFC, as I believe the each need to be considered
on their own merits, and not lumped into
But what about optional weak (auto-convert) type hints? They should
make life if not easier, definitively a little richer when writing
API's and internal stuff, where some additional strictness and
warnings generated make sense.
And it definitively makes IDE's more happy and easier to generate
PHPD
On 27/02/12 16:12, Richard Lynch wrote:
> Oh, and string is a reserved word, so this won't work as-is, though
> that's obviously picuyane.
It's not, you can perfectly define your own class called 'string'. I'd
be much easier if it were, though.
--
PHP Internals - PHP Runtime Development Mailin
2012/2/27 Johannes Schlüter
> Hi,
>
> PHP is no strickt-typed language. Changing this is a massive change, if
> you want to go there: There are plenty of other languages.
>
> If you want this to be an optional feature:
> a) It's not optional (one has to maintain code written by others, uses
> lib
Hi,
PHP is no strickt-typed language. Changing this is a massive change, if
you want to go there: There are plenty of other languages.
If you want this to be an optional feature:
a) It's not optional (one has to maintain code written by others, uses
libraries, frameworks, ...)
b) It causes a hell
Hi, Richard
The development of the unicode-as-default-charset should really be done
within the next release coming after 5.4
I heared somewhere that it's nearly done ...
I would have happily seen it in 5.4 but as this release is late right now
we have to wait ;)
Bye
Simon
p.s. *
http://www.php.n
Michael Morris,
Type hinting means that we have hints when declaring function/method
signatures, example:
functiion do(int $someVal) {}
function doOther(string $str, mixed $pos = null) {}
As I remember, there was never a discussion about adding type hints
when declaring vars. The original discus
On Mon, February 27, 2012 2:31 am, Laruence wrote:
> On Mon, Feb 27, 2012 at 4:00 PM, Dmitry Stogov
> wrote:
>> Hi Laruence,
>>
>> The attached patch looks wired. The patch on top of it (r323563)
>> makes it
>> better. However, in my opinion it fixes a common problem just in a
>> single
>> place.
> I have to say that no matter how much a luv my OOP, turning every
> built-in type into an Object is just a Bad Idea...
>
> It's a form of bloat on RAM and CPU with minimal added value, imho.
>
> No matter which way you twist this pretzel:
>
> -1
Re-read what I had written. I never said to turn
On Sun, February 26, 2012 2:03 am, Stas Malyshev wrote:
> Just discovered that our stock "php 4 support discontinued" message in
> bugs looks like:
>
> We are sorry, but we can not support PHP 4 related problems anymore.
> Momentum is gathering for PHP 6, and we think supporting PHP 4 will
> lead t
On Sun, February 26, 2012 8:45 pm, Anthony Ferrara wrote:
>> Or operator-overlading to the rescue? :-)
>
> Not quite. Especially because with operator overloading done at this
> level (how it would be implemented in PHP) it's almost impossible to
> make it consistent:
>
> class string {
> publ
On Sun, February 26, 2012 9:48 am, Anthony Ferrara wrote:
I have to say that no matter how much a luv my OOP, turning every
built-in type into an Object is just a Bad Idea...
It's a form of bloat on RAM and CPU with minimal added value, imho.
No matter which way you twist this pretzel:
-1
--
What I've wanted for awhile, but don't know what the implementation
problems would be, is to allow for two new variable types to solve
this problem - Strict and tolerant variables. Both of these must be
declared formally (otherwise PHP assumes scalar) and the datatype must
be included. The syntax
On Mon, Feb 27, 2012 at 2:27 AM, Kris Craig wrote:
> Ok, I've updated the RFC based on input received here. I also made a
> decision on the APXS vs. APXS2 question; please refer to the RFC for
> details. If anybody has any objections to this decision, now would be the
> time to say something!
>
PHP through mod_php on Linux should compile without ZTS.
configure script searches for apxs binary and tries to invoque "apxs -q
MPM" to figure out what MPM has been compiled in Apache for the TS flag to
be defined or not (thus, activating PHP ZTS, or not).
Mainly on Linux, Apache should have bee
1 - 100 of 113 matches
Mail list logo
