> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Tuesday, January 29, 2013 3:37 PM
> To: Rasmus Lerdorf
> Cc: PHP internals
> Subject: Re: [PHP-DEV] ZTS - why are you using it?
>
> On Tue, Jan 29, 2013 at 2:33 PM, Rasmus Lerdorf
> wrote:
>
> > Those ISPs are p
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Tuesday, January 29, 2013 3:19 PM
> To: Zeev Suraski
> Cc: Johannes Schlüter; PHP internals
> Subject: Re: [PHP-DEV] ZTS - why are you using it?
>
> On Tue, Jan 29, 2013 at 1:52
> -Original Message-
> From: kalle@gmail.com [mailto:kalle@gmail.com] On Behalf Of
Kalle
> Sommer Nielsen
> Sent: Tuesday, January 29, 2013 3:45 PM
> To: Zeev Suraski
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Integrating Zend Op
> -Original Message-
> From: Clint Priest [mailto:cpri...@zerocue.com]
> Sent: Tuesday, January 29, 2013 3:30 PM
> To: Anthony Ferrara
> Cc: Tyler Sommer; Zeev Suraski; internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP
>
> -Original Message-
> From: kalle@gmail.com [mailto:kalle@gmail.com] On Behalf Of
Kalle
> Sommer Nielsen
> Sent: Tuesday, January 29, 2013 3:28 PM
> To: Zeev Suraski
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Integrating Zend Op
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Tuesday, January 29, 2013 2:19 PM
> To: Zeev Suraski
> Cc: Johannes Schlüter; PHP internals
> Subject: Re: [PHP-DEV] ZTS - why are you using it?
>
> On Tue, Jan 29, 2013 at 1:06
On Tue, Jan 29, 2013 at 1:15 PM, Pierre Joye wrote:
>
>
> On Jan 29, 2013 12:10 PM, "Zeev Suraski" wrote:
> >
> > > The other main reason from my side to keep ZTS is Windows. Windows
> > cannot
> > > perform well using process based SAPI.
>
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Tuesday, January 29, 2013 1:49 PM
> To: Johannes Schlüter
> Cc: Zeev Suraski; PHP internals
> Subject: Re: [PHP-DEV] ZTS - why are you using it?
>
> On Tue, Jan 29, 2013 at 12:45 PM, Jo
> The other main reason from my side to keep ZTS is Windows. Windows
cannot
> perform well using process based SAPI.
Windows actually works quite well with FastCGI. So well Microsoft even
created their own version for IIS. It's outperforming the ISAPI module by
a wide margin.
Other than Apache/
> Hey:
>
> It's not we choose ZTS, it is there are many users run with them (IIS,
> Apache+workers, and pthreads extension require it)
For pthreads I can understand it, but why would users be using it on
IIS/Apache instead of using FastCGI? FastCGI is both faster and more
robust. Is it a matter
I didn’t want to hijack the Optimizer+ thread so I’m creating a new one,
based on the apparent level of interest in ZTS. This isn’t an RFC to
remove ZTS by any stretch, but I **am** a bit confused about why people are
still using ZTS.
A bit of background. I started the ZTS project (based on in
> -Original Message-
> From: Ryan McCue [mailto:li...@rotorised.com]
> Sent: Tuesday, January 29, 2013 10:13 AM
> To: Zeev Suraski
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP
> distribution
>
> Zeev Suras
> One important part missing is the actual compatibility/support of thread
safe
> PHP. I know that Zend mostly care about NTS since quite some time and
that
> worries me a lot to bundle something that is not working well in thread
safe
> mode. I would consider that as a stopping point. I mean, not
All,
Following the discussion at the end of last week, I prepared a draft RFC
for the inclusion of Optimizer+ in PHP.
In parallel we’re in the process of prepping the source code for
independent public consumption, which I hope we can be done with by the end
of next week, hopefully sooner.
h
> -Original Message-
> From: Levi Morrison [mailto:morrison.l...@gmail.com]
> Sent: Monday, January 28, 2013 10:04 PM
> To: Zeev Suraski
> Cc: Anthony Ferrara; internals@lists.php.net
> Subject: Re: [PHP-DEV] Purpose of voting
>
> On Mon, Jan 28, 2013 at 12:53
> What should we be voting on when voting on an RFC: on the RFC proposed
> feature, or on the patch itself?
I think it should be exclusively on the concept. We never vote about code
changes anywhere - including when we refactor existing parts. Why would
we vote about the implementation here?
Th
> Can we stop calling things "new shiny features" as if that means
anything? It's
> empty rhetoric. When you treat your users like unintelligent noobies who
are
> just going to hang themselves when you give them a rope, then that's the
type
> of users you will end up with.
If it doesn't mean anyth
I agree, but we’re in opposite camps on this feature. What does that mean?
J
I think many of us are purely and simply totally out of sync with our
users. I have no immediate solution but this is something we must solve,
now.
> -Original Message-
> From: Clint Priest [mailto:cpri...@zerocue.com]
> Sent: Monday, January 28, 2013 3:15 PM
> To: Peter Cowburn
> Cc: Zeev Suraski; Pierre Joye; PHP internals
> Subject: Re: [PHP-DEV] Voting periods
>
>
> On 1/28/2013 6:12 AM, Peter Cowburn wr
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Monday, January 28, 2013 5:46 PM
> To: Zeev Suraski
> Cc: Alan Knowles; Gustavo Lopes; PHP Internals
> Subject: Re: [PHP-DEV] [VOTE] Deprecate and remove calls from
incompatible
> context
&g
> -Original Message-
> From: Alan Knowles [mailto:a...@roojs.com]
> Sent: Monday, January 28, 2013 4:49 PM
> To: Gustavo Lopes; PHP Internals; Alan Knowles
> Subject: Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible
> context
>
> I was trying to vote against, for what it's
> I mean more "no matter if it is or not", but the result is not tie
anyway, accepted
> or not.
>
> I find the way things are being done right now as a bad thing. There is
a time for
> discussions and argumentations, and there is a time for votes. Coming in
with
> things like that does not give me
> -Original Message-
> From: Zeev Suraski [mailto:z...@zend.com]
> Sent: Monday, January 28, 2013 3:00 PM
> To: 'Pierre Joye'; 'Clint Priest'
> Cc: 'PHP internals'
> Subject: RE: [PHP-DEV] Voting periods
>
> > Zeev, for o
> Zeev, for one, was one of them asking to have a 2/3 majority for any
language
> related RFC. That's what applies to this RFC, and it is, as of now,
accepted. I don't
> see how the vote is remotely close to a tie.
Are you talking about https://wiki.php.net/rfc/propertygetsetsyntax-v1.2?
There ar
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Monday, January 28, 2013 1:07 PM
> To: Zeev Suraski
> Cc: PHP internals
> Subject: Re: [PHP-DEV] Voting periods
>
> hi,
>
> On Mon, Jan 28, 2013 at 11:57 AM, Zeev Suraski wrot
> > My suggestion is for voting periods to be limited to one week,
> > regardless of the topic. It should be more than enough. Regardless,
an 'open
> ended'
> > voting period is unacceptable IMHO.
>
> You were one of the person who requested to have at least two weeks, so
> nobody can miss a vote
Hi,
There’s something that I’m not quite following regarding open votes.
Why are we saying that ‘votes will end no sooner than X’, instead of
actually saying when they *will* end?
If there’s no clear end date for a vote, when do we declare than a vote is
over? Is it in a specific point in t
> -Original Message-
> From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
> Sent: Friday, January 25, 2013 8:45 PM
> To: Zeev Suraski
> Cc: Rasmus Lerdorf; Ralf Lang; internals@lists.php.net
> Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
>
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Friday, January 25, 2013 8:42 PM
> To: Zeev Suraski
> Cc: Rasmus Lerdorf; Ralf Lang; PHP internals
> Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
>
> hi Zeev,
> @Zeev, is anyone writing up an RFC for this?
Not yet, I'll write one.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> -Original Message-
> From: Rasmus Lerdorf [mailto:ras...@lerdorf.com]
> Sent: Friday, January 25, 2013 7:16 PM
> To: Zeev Suraski
> Cc: Ralf Lang; internals@lists.php.net
> Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0
>
> On 01/25/201
> -Original Message-
> From: Will Fitch [mailto:wfi...@meetme.com] On Behalf Of Will Fitch
> Sent: Friday, January 25, 2013 6:48 PM
> To: Zeev Suraski; Rasmus Lerdorf
> Cc: Ralf Lang; internals@lists.php.net
> Subject: Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for
> Either by a number of people stepping up to help with the existing APC
code, or
> perhaps more realistically making it a priority in PHP 5.6 to streamline
the
> engine and the executor for opcode caching and either including a
heavily
> simplified version of APC or writing a new one.
>
> One thin
On 16 בינו 2013, at 22:00, Pascal Mathis wrote:
> Hi internals!
>
> I am currently developing a Zend extension. Because the Zend MM leak reports
> are not really useful sometimes, I switched the memory manager off with the
> environment variable USE_ZEND_ALLOC=0, so that I can use valgrind.
>
>
gmail.com]
Sent: Thursday, March 01, 2012 12:16 AM
To: Zeev Suraski
Cc: John Crenshaw; Richard Lynch; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
Responses inline.
--Kris
On Wed, Feb 29, 2012 at 1:49 PM, Zeev Suraski
mailto:z...@zend.com>> wrote:
Kris,
If we've
tantial' changes, they should
be material enough so that they'll significantly effect the outcome of another
vote.
... then it's worth discussing. Nothing I saw in this thread falls under that
category, as far as I can tell.
Let's put it to rest.
Zeev
From: Kris Craig [mailto:
Guys,
I've followed this thread silently so far, and I'm wondering what changed over
the last ~1.5years that warrants a new discussion into that matter.
I think the previous discussion ended with a pretty clear directive that strict
typing has no place in PHP. Rasmus said about the proposal bac
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Thursday, August 25, 2011 11:31 AM
> To: a...@akbkhome.com
> Cc: Stas Malyshev; internals@lists.php.net
> Subject: Re: [PHP-DEV] PHP 5.3.8 Released!
>
> On Thu, Aug 25, 2011 at 3:51 AM, a...@akbkhome.com
> wrot
Well, I have to admit this is mighty convincing :) Wasn't aware of this
use-case. Falls under the category of mass breakage I guess.
Zeev
> -Original Message-
> From: a...@akbkhome.com [mailto:a...@akbkhome.com]
> Sent: Wednesday, August 24, 2011 3:39 PM
> To: Zeev S
> by case basis. It is now very well known that when a fix requires a test
> change,
> then it often leads to bc breaks or similar issues.
>
> I do not think we have to argue about the semantics or general cases but how
> to avoid such things and be sure that we break as less code as possible in
> > This wholesale statement doesn't get us anywhere.
>
> It does, we underestimate the situation and this fix/improvement/consistency
> change breaks apps and codes out there.
> And I do not consider it as acceptable at this stage in 5.3.x. Let do it only
> in
> 5.4.
How is it different from a
> No matter what it is or how it is defined by us, it breaks existing code and
> that
> should be avoided in bug fixes releases like 5.3.7/8.
Pierre,
This wholesale statement doesn't get us anywhere. Every bug fix can result in
breaking existing code. If due to a logic error, under some circu
it does not break anything else. (nobody would have used it that
> way yet..).
>
> Regards
> Alan
>
> On Wednesday, August 24, 2011 06:43 PM, Zeev Suraski wrote:
> > I think there are two ways to look at it:
> >
> > - As a new feature. If I understand yo
I think there are two ways to look at it:
- As a new feature. If I understand you correctly, the fact that beforehand
is_a() was documented to only return TRUE in case the first argument was an
instance of the second argument, means that if we do anything beyond that -
e.g. support strings as
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Monday, June 06, 2011 1:46 AM
> To: Zeev Suraski
> Cc: PHP Internals
> Subject: Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on
> the wiki! (Was: [PHP-DEV] 5.4 moving f
[resending as the list appears to reject bit.ly URLs]
> As I agree on everything you wrote here, I don't feel like we need to redo it.
> The votes result is pretty clear, despite 2-3 people not willing to
> vote for whatever reasons:
>
> https://wiki.php.net/rfc/shortsyntaxforarrays/vote
Take a
> Currently the "Feature selection and development" basically says "we'd have
> a public vote on features". It doesn't specify how exactly is the process for
> a
> vote, and while again I think your proposal is good, I don't see why it has
> to be
> part of this RFC - e.g., if we agree that we ha
> -Original Message-
> From: dukeofgaming [mailto:dukeofgam...@gmail.com]
> Sent: Monday, June 06, 2011 12:18 AM
> To: Chris Stockton
> Cc: Jordi Boggiano; Sean Coates; PHP internals
> Subject: Re: [PHP-DEV] Object and Array Literals
>
> I like the idea of supporting both "=>" and ":". Wou
e-
> From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
> Sent: Sunday, June 05, 2011 11:17 PM
> To: Zeev Suraski
> Cc: Pierre Joye; PHP Internals
> Subject: Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on
> the wiki! (Was: [PHP-DEV] 5.4 moving forward))
>
For those of you who lost these proposals in the flood of RFC related emails of
recent days, here they are again:
---
First, we need to make sure that the RFC is properly evaluated by the members
of internals@, and that there's enough time for the RFC to be discussed here on
the list. As Phil
Ok, that makes much more sense. Given how everyone loved it I was beginning to
wonder whether I’ve become too old to understand simple pieces of code ☺
Zeev
From: Felipe Pena [mailto:felipe...@gmail.com]
Sent: Sunday, June 05, 2011 11:02 PM
To: Zeev Suraski
Cc: internals
Subject: Re: [PHP-DEV
Pierre,
I'm happy that we agree pretty much completely about the clarifications &
updates needed for the RFC.
I do however want to point out that the problematic way the short array syntax
RFC was executed was the key reason that made me feel these updates were in
fact necessary - I don't thin
> -Original Message-
> class Hello {
>public function world($x) {
> echo "Hello, $x\n"; return $this;
>}
> }
>
> $f = array(new Hello, 'foo');
> $f();
Am I the only one who doesn't understand what this one is supposed to do..?
Zeev
> On Jun 4, 2011, at 3:07 AM, Pierre Joye wrote:
>
> > On Sat, Jun 4, 2011 at 5:46 AM, Stas Malyshev
> wrote:
> >
> >> [VOTE] is a good idea, let's make it [VOTE].
> >>
> >>> There is no plugin used for it yet, and that's my problem with it.
> >>
> >> Well, votes aren't announced yet either :)
> However, what you refer to is about internals API. We can (and did a
> lot) break ABI between x.y and x.y+1 and should really avoid breaking API
> (read: signatures, source compatibility) if possible.
I think we need to clear it up in the RFC. My take:
- Switch from talking about 'ABI' to 'ext
There's something between the user level API and the ABI - which is source
level compatibility.
What Dmitry's pointing out that if we commit to source level compatibility,
it'll be quite limiting (based on past experience). If we don't commit to
source-level compatibility then we're fine. I g
+1 with Andi's improvement.
Gustavo - I realize it's not about changing the token's name, but nobody (=very
few) looks at the token names. The point is to keep the tradition of also
exposing this specific token name to the user, but still making it clear that
what was expected was :: - without
On May 10, 2011, at 18:57, "Matthew Weier O'Phinney"
wrote:
> With annotations, my main issue, which I voiced early (and others did as
> well), is that we can already do much of what the RFC proposes by
> parsing annotations in docblocks. In fact, adding the support
> potentially creates more w
> that's the crowd I referenced to. The users I discuss too, in locale
> conference,
> UG, enterprises, etc. never heard or only vaguely about php6. Or they heard
> about it while seeing a book called "PHP 6 and mysql 6" or something stupid
> like that ;).
I've yet to meet someone in the last few
> Only that it has no technical or features-
> wise reasons to do so
Substantial engine level improvements and a couple of new language level
features (it's pushing it a bit, I agree, but not that much)
> but brings its lots of risks with it.
I fail to see how changing a version number brings a
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Friday, November 26, 2010 7:21 PM
> To: Zeev Suraski
> Cc: Ilia Alshanetsky; Johannes Schlüter; Andi Gutmans; Jani Taskinen;
> da...@php.net; PHP Internals
> Subject: Re: [PHP-DEV] Re: Hol
> -Original Message-
> From: Derick Rethans [mailto:der...@php.net]
> Sent: Friday, November 26, 2010 12:00 PM
> To: Kalle Sommer Nielsen
> Cc: Zeev Suraski; Johannes Schlüter; Andi Gutmans; Jani Taskinen;
> da...@php.net; PHP Internals
> Subject: Re: [PHP-DEV] Re: Hol
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Friday, November 26, 2010 3:03 AM
> To: Ilia Alshanetsky
> Cc: Zeev Suraski; Johannes Schlüter; Andi Gutmans; Jani Taskinen;
> da...@php.net; PHP Internals
> Subject: Re: [PHP-DEV] Re: Hold
I think that skipping to a major version is a good idea.
Two key reasons I think that:
1. It'll help us break the evil spell of the 6 version number. Honestly, I'm
not so certain we'll have major engine rewrites the size of what we've seen in
PHP 3/4/5 going forward. Sure, I have a track rec
> If it doesn't check for the hints, then your application will still work. I
> will say
> this once more: this is a *debugging* aid.
If your app *relies* on it, then it means it will probably not use other means
to ensure that the data is of the correct type, which may result in all sorts
of i
> I find it interesting that apparently so many people don't want a new PHP
> version out, but forget to say what they think needs fixing. Instead of
> opposing, can we not do just some work?
Specifically the issue I'm most concerned about is the type hinting syntax.
Zeev
--
PHP Internals - PHP
> > For the record, I'm still very uncomfortable with this new language
> > syntax - even if it's a no-op right now.
>
> I know you are; but from what I understood, there were no more comments
> to the latest mail (with patch and RFC) that I've made towards this.
I know, I took some time off af
> -Original Message-
> From: Derick Rethans [mailto:der...@php.net]
> Sent: Tuesday, November 23, 2010 11:58 AM
> To: Felipe Pena
> Cc: internals
> Subject: Re: [PHP-DEV] Hold off 5.4
>
> On Mon, 22 Nov 2010, Felipe Pena wrote:
>
> > Given the current state of trunk, I think 5.4 release
> -Original Message-
> From: Larry Garfield [mailto:la...@garfieldtech.com]
> Sent: Thursday, November 18, 2010 7:41 AM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Magic quotes in trunk
>
> On Wednesday, November 17, 2010 11:19:05 pm Philip Olson wrote:
> > > What are your inp
I’m not the only one in this thread repeating himself to make a point :)
What I opposed is the notion that ‘everyone wants some sort of meta attribute
support’. Maybe I read too much into it but I read it as implying we need
something substantial that’s new.
Either way, I’m fine with going in
On Nov 17, 2010, at 4:29, "guilhermebla...@gmail.com"
wrote:
> Hi Stas,
>
> Ok, so you think I should just consider everyone want some sort of
> meta attribute support and start discussing the topics?
Of course not. Assuming meta support requires substantial additions of syntax
then it's ve
If past experience is any indicator then you’re hardly correct regarding your
first statement – being able to do something in PHP was no insurance against
proposals suggesting new ways of doing the same thing – often in an improved
way.
Re: the 2nd part, extending phpdoc would be way less obscu
cial rules or structures
for voting features into PHP, PHP being a meritocracy, that should be enough to
put this RFC to bed.
Zeev
> -Original Message-
> From: guilhermebla...@gmail.com [mailto:guilhermebla...@gmail.com]
> Sent: Tuesday, November 16, 2010 4:28 AM
> To:
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Tuesday, November 16, 2010 1:45 AM
> To: Zeev Suraski
> Cc: guilhermebla...@gmail.com; PHP internals
> Subject: Re: [PHP-DEV] PHP 5.4 - Meta attribute (aka. Annotations) support
> discussio
Suggesting phpdoc is used for the purposes mentioned does not mean we don't
understand what we're talking about.
Zeev
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Tuesday, November 16, 2010 12:43 AM
> To: Zeev Suraski
> Cc:
I don't see a point in repeating the discussion we've already had on that topic
several weeks ago. There needs to be an overwhelmingly good reason to add a
brand new syntax to the language, a whole branch of it in the case of
annotations - and there simply isn't.
Zeev
> -Original Message-
On Nov 2, 2010, at 10:43, "Ilia Alshanetsky" wrote:
> We should probably stick with the bison parser for now, at least until
> the lemon matches the speed of the existing solution.
>
+1, and there should also be some clear advantages for making the switch and
introducing risk even once it's fas
On Nov 2, 2010, at 9:13, "André Rømcke" wrote:
> On Tue, Nov 2, 2010 at 9:57 AM, Lester Caine wrote:
>
>> Derick Rethans wrote:
>>
>>> Actually, Kalle just pointed out that it compiles just fine. In that
>>> case, I think we should put it in trunk and in the 5.4 alpha.
>>>
>>
>> As long as i
At 16:34 16/09/2010, Guilherme Blanco wrote:
So the question to be answered is: Should PHP support Annotations?
-1 for introducing a new Annotations concept and associated syntax
+1 for adding APIs to parse doc blocks
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, vi
At 09:37 15/09/2010, Christian Kaps wrote:
On Tue, 14 Sep 2010 23:09:02 -0700, Stas Malyshev
wrote:
> Whatever syntax it is, it is definitely new.
Yes, but this should not be an argument against it. So every new
feature can have new syntax or should PHP freeze on the current state!?
I can't ho
At 08:09 15/09/2010, Stas Malyshev wrote:
Phpdocs aren't "user documentation" only, not for a long time (I
mean the concept, not the particular application called
phpDocumentor, of course). They are being used as metadata in many
places. You could argue that's misguided but you can't ignore the
At 19:25 13/09/2010, Gustavo Lopes wrote:
On Mon, 13 Sep 2010 17:46:42 +0100, Zeev Suraski wrote:
I wasn't talking about the patch, I was talking about the need of end
users to understand yet another new concept and syntax. PHP used to be
a language one could pick up over a weekend.
At 17:51 13/09/2010, Gustavo Lopes wrote:
On Mon, 13 Sep 2010 16:28:47 +0100, Zeev Suraski wrote:
The fact that PHP is not C# or Java doesn't mean we shouldn't look for
useful features in those languages,
Right.
so it's not an argument.
I think it is very much an argume
At 17:51 13/09/2010, Gustavo Lopes wrote:
On Mon, 13 Sep 2010 16:28:47 +0100, Zeev Suraski wrote:
At 16:39 13/09/2010, Pierre Joye wrote:
You are not serioulsy suggesting to use phpdoc for runtime annotation
support? Are you?
I actually am (either that or get what you want done in some
At 17:47 13/09/2010, Benjamin Eberlei wrote:
This only applies to the weird suggestions of % or ! for the operator and
new syntax constructs for arrays and such. Are there any objections to
implementing them to actually look like PHP code?
Yep. It's a whole new branch of syntax even w/o the we
min
On Mon, 13 Sep 2010 15:05:57 +0200, Zeev Suraski wrote:
> At 20:24 11/09/2010, Pierre Joye wrote:
>>On Sat, Sep 11, 2010 at 8:19 PM, Stas Malyshev
>>wrote:
>> > Hi!
>> >
>> >> The separator never was a problem... but I definately don't want to
At 16:39 13/09/2010, Pierre Joye wrote:
You are not serioulsy suggesting to use phpdoc for runtime annotation
support? Are you?
I actually am (either that or get what you want done in some other
way). It's a rare enough use case that I think it's a very
reasonable compromise. The disadvanta
At 20:24 11/09/2010, Pierre Joye wrote:
On Sat, Sep 11, 2010 at 8:19 PM, Stas Malyshev wrote:
> Hi!
>
>> The separator never was a problem... but I definately don't want to
>> see another 6 months just to define what would the separator be.
>> If we need to drop [] in favor of array support, I v
At 17:04 19/08/2010, Ionut G. Stan wrote:
class Parent
{
public function foo(Foo $foo)
{}
}
class Child
{
public function foo(Bar $bar)
{}
}
class Foo
{}
class Bar extends Foo
{}
All fine until here, but what if...
class Taz extends Foo.
{}
I can't call Child::foo() wit
At 10:51 19/08/2010, Stas Malyshev wrote:
Hi!
I recently noticed this code:
produces a E_STRICT warning. I don't really see a point in it -
there's no problem whatsoever with child function ignoring some
arguments from parent call. Anybody could explain why this check is there?
As others no
At 10:57 12/08/2010, Daniel Egeberg wrote:
> Everyone who opposes strict typing on grounds that it's an alien
> feature to PHP(*) doesn't see any advantages in this suggestion
Perhaps if you stopped pretending to know everybody's opinion
Suggest you re-read what I said, you didn't seem to unde
At 04:02 12/08/2010, Josh Davis wrote:
What would be interesting to see is what people think of Derick's
latest proposal allowing both the strict typechecking and the more
sensible "weak typing"
There's nothing new about it, it's been on the table for around half
a year now. Everyone who oppo
there's
only a small group of people who oppose it. Recommended reading are
this list and Johannes's blog.
Zeev
At 01:05 12/08/2010, Daniel Egeberg wrote:
On Wed, Aug 11, 2010 at 23:26, Zeev Suraski wrote:
> Now that strict typing is pretty clearly off the table [...]
Did I m
At 00:58 12/08/2010, Josh Davis wrote:
> Now that strict typing is pretty clearly off the table - how would those
Wait, what? Clearly off the table?
Yes, clearly off the table.
I'm not sure how long you've been on internals, but I'm not sure
there's any precedence to such strong and diverse
At 00:26 12/08/2010, Zeev Suraski wrote:
Moving forward with both is certainly not the only option, I'd say
(given the paragraph above) that it's not an option at all. At the
very least, there's one other option which is doing nothing. And
that's assuming we can't r
At 23:59 11/08/2010, Josh Davis wrote:
Not sure what kind of impact we're talking about here. Currently,
there's no scalar type hinting and there will never be a consensus
around strict XOR weak. Having an implementation that allows both
while reusing a familiar syntax (parentheses as a way typec
You're absolutely right, sorry about that!
Zeev
At 23:11 11/08/2010, Alexey Zakhlestin wrote:
You misunderstood my comment.
Lester asked if he can still have his APIs without type-hinting and I
told him that he can.
That's all
We're not talking about complexities of understanding
--
Alexey Z
At 22:50 11/08/2010, Alexey Zakhlestin wrote:
On Wed, Aug 11, 2010 at 11:41 PM, Lester Caine wrote:
> Ilia Alshanetsky wrote:
>>
>> +1, I think that's the most sensible solution for now that would allow
>> us to proceed with 5.4, something we all seem to be in agreement on.
>
> A slight aside he
At 22:54 11/08/2010, Josh Davis wrote:
On 11 August 2010 20:40, Zeev Suraski wrote:
> Josh,
>
> This too (having both options) was debated many times. Read the archives.
I have already read the archives thank you very much. I'm sure you
have too and you remember that there&
At 21:30 11/08/2010, Stas Malyshev wrote:
Hi!
I think by now, whatever you think on strict typing/typehints, it is
clear to everybody that there's no consensus about this feature, and
with Rasmus, Zeev & Andi, along with many others, being against it,
as of now it can not be a part of an offi
701 - 800 of 1400 matches
Mail list logo
