On Thu, Feb 12, 2015 at 10:55 AM, Thomas Punt wrote:
> Hello PHP Internals!
> I'd like to propose to make empty() a variadic, where if any arguments
> passed in are considered empty, then false is returned - otherwise return
> true.
> My reasoning for wanting this feature is as follows:1)It's a c
On Thu, Feb 12, 2015 at 8:53 AM, Rowan Collins
wrote:
> François Laupretre wrote on 12/02/2015 14:56:
>
>> Sorry to get off-topic but could we raise the 'undefined variable' error
>> to E_WARNING, at least ? E_NOTICE seems very low for such an error.
>>
>
> I think the division between E_NOTICE a
On Sun, Feb 15, 2015 at 4:15 PM, Netroby wrote:
> I am not the core developer of PHP, but I am keeping watch the develop
> list for long times.
> Andrea Faulds, actively contributes the PHP core. but it's hard to
> implement your dream here.
> So sad I feel.
> Say no is easier, but do things is h
> create the static instance
Isn't that essentially a contradiction in terms? I can't help but feel
that blurring the line between static and non-static classes/methods would
cause more harm than good.
I've never really done any work with Redis before so I'm also having
trouble understanding the
On Mon, Feb 16, 2015 at 7:48 PM, Larry Garfield
wrote:
> On 02/16/2015 10:31 AM, François Laupretre wrote:
>
>>
>> - The leadership of the language is left to consensus, so that when
>>> consensus cannot be reached, someone has to take on the role of mediator
>>> / chairman / leader for the feat
On Tue, Mar 17, 2015 at 4:24 PM, Stanislav Malyshev
wrote:
> Hi!
>
> > I think having clearer rules about what lobbying is permitted, and
> > introducing some rules on who can vote on what would be a better way
> > of limiting the effect of lobbying.
>
> And pretty soon we'll have 100-page law co
On Fri, Mar 20, 2015 at 11:35 AM, Ferenc Kovacs wrote:
> On Fri, Mar 20, 2015 at 7:14 PM, Philip Sturgeon
> wrote:
>
> > On Mon, Mar 16, 2015 at 2:59 PM, Stanislav Malyshev >
> > wrote:
> > > Hi!
> > >
> > >> when we are fixing the low hanging fruits, please directly put in the
> > >> wiki that
On Fri, Mar 20, 2015 at 7:30 PM, Pierre Joye wrote:
> hi,
>
> On Tue, Mar 17, 2015 at 5:01 AM, Philip Sturgeon
> wrote:
> > While you can easily question the value or motives of Anthony's post
> > about voting irregularities, some simple improvements can be made
> > which are uncontroversial. I
On Thu, Mar 26, 2015 at 3:40 PM, Alain Williams wrote:
> On Thu, Mar 26, 2015 at 10:31:00PM +, Rowan Collins wrote:
>
> > What I've always been annoyed by is the *precedence* of the operator -
> having to add brackets to mix it with string concatenation, etc - which it
> turns out to is the s
On Tue, Apr 14, 2015 at 7:21 PM, Pierre Joye wrote:
> hi,
>
> We tried that many times but we fail to handle the version of bundled
> extensions.
>
> Along with some installer work and other integration (projects
> dependencies management, composer or other), we need to find a way to
> get rid of
On Fri, Jul 10, 2015 at 2:39 PM, Larry Garfield
wrote:
> On 7/10/15 3:27 PM, Dean Eigenmann wrote:
>
>> Hello,
>>
>> I have a proposal for PHP. The proposed interface would allow developers
>> to decode json into a custom object directly. If given the approval I would
>> possibly be able to imple
On Fri, Jul 10, 2015 at 7:07 PM, Larry Garfield
wrote:
> On 07/10/2015 07:37 PM, Kris Craig wrote:
>
>> On Fri, Jul 10, 2015 at 2:39 PM, Larry Garfield
>> wrote:
>>
>> On 7/10/15 3:27 PM, Dean Eigenmann wrote:
>>>
>>> Hello,
>>>>
On Fri, Aug 16, 2024 at 8:11 AM Derick Rethans wrote:
> Hi,
>
> In the last months, you have had numerous suggestions to keep it civil
> on the mailing list, in the "C++ Enhancements" thread [1,2,3,4,5,6], and
> multiple other threads [7,8,9], and by many individuals. Despite that,
> you did cont
On Fri, Aug 16, 2024 at 3:37 PM Rob Landers wrote:
>
>
> On Fri, Aug 16, 2024, at 22:16, Kris Craig wrote:
>
>
>
> On Fri, Aug 16, 2024 at 8:11 AM Derick Rethans wrote:
>
> Hi,
>
> In the last months, you have had numerous suggestions to keep it civil
Opening discussion on RFC pertaining to adding a new option to the
configure script with regard to how/whether APXS touches the httpd.conf
file.
This is my first RFC post so please go easy on me if I screwed-up on
procedure in any way. =)
Here it is: https://wiki.php.net/rfc/apxs-loadmodule
T
s are a bit vague on this.
Either way, I think so long as our documentation is clear and the existing
behavior is default then it shouldn't pose a problem.
--Kris
2012/2/20 Johannes Schlüter
> Hi,
>
> On Mon, 2012-02-20 at 17:02 -0800, Kris Craig wrote:
> > Opening disc
While I'm a huge fan of Github, why did you decide to host your RFC there
instead of on the PHP wiki? I realize there's an older proposal there
right now, but that's from 2010 and seems to be dead in the water. Even if
yours is just a draft, the wiki is designed to be able to accommodate
progress
Hmm I think Stas makes a good point. One of the allures of PHP,
particularly for web developers without any programming experience, is its
flexibility. Strict typing would certainly negate that.
If I may be so bold, should we perhaps expand the scope of this discussion
to address the larger ques
anything about enums,
> but strict vs. dynamic typing is a hot topic that probably won't get any
> agreement here. The previous discussions are just too recent, and it's not
> likely anyone has changed their mind.
>
> On Thu, Feb 23, 2012 at 12:21 PM, Kris Craig wro
interpreter which is which.
--Kris
2012/2/23 Ángel González
> On 23/02/12 22:59, Kris Craig wrote:
> > Could you elaborate on this? So long as that setting cannot be changed
> > midway through a script or its includes (i.e. the stack must be "all
> > strict&qu
his head-on, despite the
obvious discomfort that it would bring in the short-term; though I think
much of that could be mitigated if we simply targetted this for PHP 6.
--Kris
2012/2/23 Ángel González
> On 23/02/12 23:49, Kris Craig wrote:
> > Yeah I agree, that was one of the things I l
Err typo correction: In my "what if" scenario, I meant to say, "what if
dynamic function A makes a call to *static* function B".
--Kris
2012/2/23 Kris Craig
> Hmm that's a fascinating idea! So, and please correct me if I'm wrong,
> you're say
Agreed. Just to clarify in case my post confused anyone, we are not (at
least to the best of my knowledge) in the process of developing the 6.0
release right now, nor am I suggesting that the ideas I floated should be
in 5.x. I apologize if I made anyone scratch their heads needlessly lol.
So ye
Could you elaborate on that a little? I.e. "as an interface for the
call". I'm not sure what you mean by that. If you could provide a quick
example, that would be awesome! =)
--Kris
2012/2/24 Ángel González
> On 24/02/12 00:36, Kris Craig wrote:
> > Hmm that's
Yeah I agree with Stas. I definitely think this is a good idea and should
be included, but since we're already in the RC phase for 5.4.0 and Apache
2.4 is only a few days old, I don't think it's necessary to rush it into
5.4.0 (which has already been delayed far too many times already).
Definitel
As far as Windows is concerned, it is worth noting that the Apache mod_php
(i.e. ZTS) build is supported. Also, though my information is a bit
outdated, last I heard work was being done to support thread-safe PHP as an
ISAPI module on IIS, though I don't know what the status of that is.
--Kris
These things often tend to move slowly. I'm bewildered that most Linux
repos still use PHP 5.1.
The problem is, this patch has not yet gone through the QA wash cycle.
That takes time. The only way to get it into 5.4.0, therefore, would be to
delay it even further. I needn't remind anybody here
These things often tend to move slowly. I'm bewildered that most Linux
repos still use PHP 5.1.
The problem is, this patch has not yet gone through the QA wash cycle.
That takes time. The only way to get it into 5.4.0, therefore, would be to
delay it even further. I needn't remind anybody here
Regardless, I think this part of the conversation is pointless. I
personally couldn't care less whether anybody thinks we're supporting new
Apache builds quickly enough or whose fault it is if the newest one doesn't
make it into the current build. The finger pointing is just a petty
distraction t
Any further thoughts on this?
--Kris
On Mon, Feb 20, 2012 at 5:36 PM, Kris Craig wrote:
> @Johannes Agreed. That was one of the reasons I decided to make the
> existing behavior (i.e. "-a") the default.
>
> I haven't independently confirmed that issue in APXS but
th me. =)
--Kris
On Fri, Feb 24, 2012 at 2:11 PM, Richard Lynch wrote:
> On Thu, February 23, 2012 1:21 pm, Kris Craig wrote:
> >1. Is strict typing something that we should seriously consider
> >implementing at some point in the foreseeable future?
>
> No.
>
> If y
Thanks for the input! You're right, I'll go ahead and clarify that in the
RFC.
I'll probably initiate voting on Monday unless something changes between
now and then.
--Kris
On Fri, Feb 24, 2012 at 2:24 PM, Richard Lynch wrote:
> On Mon, February 20, 2012 7:02 pm
Jones <
christopher.jo...@oracle.com> wrote:
>
>
> On 02/24/2012 02:38 PM, Kris Craig wrote:
>
>> Thanks for the input! You're right, I'll go ahead and clarify that in the
>> RFC.
>>
>> I'll probably initiate voting on Monday unless some
t on the RFC).
Those steps should enable you to reproduce this. =)
--Kris
On Fri, Feb 24, 2012 at 4:02 PM, Christopher Jones <
christopher.jo...@oracle.com> wrote:
>
> On 02/24/2012 03:54 PM, Kris Craig wrote:
>
>> LoadModule clashes still happen in the current releases.
cation. It's a very common issue as many people (myself included)
prefer to keep their PHP configurations separate.
--Kris
On Fri, Feb 24, 2012 at 4:42 PM, Christopher Jones <
christopher.jo...@oracle.com> wrote:
>
>
> On 02/24/2012 04:14 PM, Kris Craig wrote:
>
&
There are advantages to strict typing other than speed and safety. The
biggest compliant I hear from people asking for this is that weak hinting
often leads to bulkier code that is much more difficult to read,
particularly for someone who frequently switches between PHP and compiled
languages like
I'm well aware that this has been discussed before, Stas. However, you're
mischaracterizing those previous conversations. It has never been proven
that optional strict typing doesn't work. You've made the same arguments
against it, but those arguments have counter-arguments that are also viable.
Inline, we go
--Kris
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 optional strict typing doesn't work. You'v
as this debate goes. Both sides have
valid points that need to be addressed with thought and care. But
dismissing it out of hand or simply ignoring it hasn't worked because
people are still asking for it, so I will be pushing back against that this
time and advocate for a continued, ongoing dia
just keep talking about it here. I honestly don't care either way. So
long as this important discussion isn't just "tabled" yet again I'm good.
--Kris
2012/2/26 Ángel González
> On 26/02/12 05:11, Arvids Godjuks wrote:
> > Kris Craig
> >
> > I usual
I like it, at least from a raw conceptual standpoint. I think you might be
on to something here, though I'd need to take some time to deliberate on it
in more detail. But my initial gut reaction is that this would at very
least be a step in the right direction. =)
--Kris
On Sun, Feb 26, 2012
I actually agree as well. Looking back in the thread, I think my overly
broad use of the word "strict" might have led to some confusion over what
I'm advocating. So to clarify, I'm referring to optional non-dynamic
typing vs purely dynamic typing as we have now. Strict typing would
require some
, if you're a library
> or framework developer who has to cope with what's turned on wherever
> their code may wind up.
>
> On Sun, Feb 26, 2012 at 7:30 PM, Kris Craig wrote:
> > I actually agree as well. Looking back in the thread, I think my overly
> > broad
So long as that release note clarifies that this patch has NOT yet gone
through the QA cycle and that, therefore, you use it at your own risk; then
I have no objection to that approach.
--Kris
On Sun, Feb 26, 2012 at 5:12 PM, Adam Harvey wrote:
> On 25 February 2012 04:02, Gustavo Lopes wrote
ave any bearing on the
upcoming 5.4.0 release. If I don't hear any new objections, I plan to
initiate the vote sometime early this week.
https://wiki.php.net/rfc/apxs-loadmodule
--Kris
On Fri, Feb 24, 2012 at 4:44 PM, Kris Craig wrote:
> Oh ok, I think I see where you're gettin
Well said, John! I think that's a terrific idea!
--Kris
On Sun, Feb 26, 2012 at 5:44 PM, John Crenshaw wrote:
> > From: Kris Craig [mailto:kris.cr...@gmail.com]
> >
> > I actually agree as well. Looking back in the thread, I think my overly
> > broad use of the
I'll try to find some time tonight to create that for ya.
Once this discussion comes together a little bit more and we have at least
a vague-ish idea what direction we're moving in, I'll also go ahead and
create an RFC as well so we have a conceptual product to build on.
--Kris
On Sun, Feb 26,
+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
.
Whether this should be done at the function level, the variable level, or
both is an open-ended question.
Some possible examples of how this would look:
weak int $i = "aaa"; // Converts to 1 and throws a warning.
strong int $ii = "aaa"; // Throws a fatal error.
weak int
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 &
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
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
vantage of the latest features. In these
cases, being able to isolate the PHP configuration tends to make the most
sense, hence why this new option switch is necessary IMHO.
--Kris
On Mon, Feb 27, 2012 at 8:59 AM, Richard Lynch wrote:
> On Fri, February 24, 2012 6:14 pm, Kris Craig wrote:
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
them of being
ill-informed, disloyal, or just plain dumb; then you're not contributing
anything constructive to this discussion.
There, I just saved you the trouble. =)
--Kris
On Mon, Feb 27, 2012 at 1:13 PM, Ferenc Kovacs wrote:
>
>
> On Mon, Feb 27, 2012 at 7:53 PM,
ctionality that Arvids had suggested. I'm fine with just going with the
stronger approach and calling that weak if that's what everyone wants.
--Kris
On Mon, Feb 27, 2012 at 1:24 PM, Ferenc Kovacs wrote:
>
>
> On Mon, Feb 27, 2012 at 8:15 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 where it's pulling
the newer build. But even then, the latest one
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"
> p
a "require" statement. One is recoverable, the other is not. I think the
same principle applies here.
--Kris
On Mon, Feb 27, 2012 at 2:31 PM, John Crenshaw wrote:
> Inline
>
> > -Original Message-
> > From: Richard Lynch [mailto:c...@l-i-e.com]
> >
&g
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 unclear.
>
> That, a
Mon, Feb 27, 2012 at 2:46 PM, Ferenc Kovacs wrote:
>
>
> 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&#
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
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?
>
, 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 2
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 co
Google Docs + Donedesk(our own product, but free) + Skype. This works
> well and strikes a nice balance between persistent and realtime
> collaboration. I'm open to other ideas, but if I had to choose how to
> coordinate a group to design a single feature, that's what I would use.
&
I'll go ahead and create an RFC for this if nobody has any objections.
Then we could link to that instead of a bug ticket.
--Kris
On Tue, Feb 28, 2012 at 10:09 AM, Kiall Mac Innes wrote:
> On Tue, Feb 28, 2012 at 5:36 PM, Stas Malyshev >wrote:
>
> > Last time we looked into it we couldn't make
There are indeed valid arguments for and against hinting. It seems to me
that having it optional as people have suggested would be the "best of both
worlds" approach, since it would allow the developer to choose for
themselves. I guess that means I'm on the "pro-choice" side of this debate
lol (s
@Michael Would you be willing to delay that? Rather than create a bunch of
new RFC's, I was thinking it might be better if all interested parties came
together on some other communication medium and worked on a single,
collaborative RFC instead.
--Kris
On Tue, Feb 28, 2012 at 12:00 PM, Michael
Hi all,
It looks like we've reached a consensus on this, so absent any objections,
I went ahead and moved this to the voting phase.
If you're eligible to vote on RFC's, please navigate to the RFC and cast
your vote now:
https://wiki.php.net/rfc/apxs-loadmodule
In case you weren't following the
+1 what Anthony said.
I think it would be prudent, as some have already suggested, for those of
us who are interested in this topic to move it to a more discreet location
so as to reduce some of the noise all around. I'll take a look at Google
docs and see if that will suit our purposes. If anyo
--Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Tuesday, February 28, 2012 3:15 PM
> To: Kris Craig
> Cc: internals@lists.php.net; Arvids Godjuks; Michael Morris; Lazare
> Inepologlou
> Subject: Re: [PHP-DEV] Scalar type hinting
>
> Can I mak
@Richard That's fairly close to what I'm thinking, yes. But there seems to
be a diverse range of ideas bouncing around right now, so at present it's
all in flux.
--Kris
On Tue, Feb 28, 2012 at 1:44 PM, Richard Lynch wrote:
> On Mon, February 27, 2012 4:34 pm, Kris Craig
I'm not sure I'd take it quite that far. I've done benchmarking of NTS and
ZTS builds and the difference really isn't anything I would consider worth
worrying about in most cases. It's fairly minor.
--Kris
On Tue, Feb 28, 2012 at 1:41 PM, Sebastian Bergmann wrote:
> On 02/28/2012 02:44 PM, Ch
2 PM, John Crenshaw wrote:
> No, In the example given there's an error on int $a = "1". There should be
> no error because this juggles fine.
>
> John Crenshaw
> Priacta, inc.
>
> -Original Message-
> From: Kris Craig [mailto:kris.cr...@gmail.com]
I think that's a bit of a stretch, to say the least. The same argument
could be made that PHP 5's introduction of stronger OO implementation would
have scared this person away. The fact is, we don't know that either of
them would have. For one thing, I doubt he monitored the PHP Internals
list;
to declare a degree of strength to the typing is severe
> overkill. I recognize that I suggested this in my first proposal, but
> at this point I'm opposed to it.
>
> On Tue, Feb 28, 2012 at 5:39 PM, Kris Craig wrote:
> > I think that's a bit of a stretch, to say the least.
One thing I've been noticing, and I think we should be careful of in this
discussion, is making broad "and this is what most people want"
statements. I've heard a number of people make some variation of that
claim now to support at-times radically different approaches. So, unless
most people
;m officially no longer on the
fence with that. =)
--Kris
On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer wrote:
> On 2/28/2012 2:58 PM, Kris Craig wrote:
>
> strong int $a = "1"; // Converts to 1. May or may not throw an error (I'm
>> still on the fence).
>>
>
uot; so who cares?
> int $a = 'House'; // error 0 != 'House', so this is a problem.
>
> Again, errors should only raise if the final value != source value.
>
> On Tue, Feb 28, 2012 at 6:03 PM, Rick WIdmer
> wrote:
> > On 2/28/2012 2:58 PM, Kris Craig wrote
l of two. Your proposal creates 3, which is 1
> too many.
>
> On Tue, Feb 28, 2012 at 6:36 PM, Kris Craig wrote:
> > But again, that same argument could be used to eliminate the require()
> > function, which is something that I and many other developers use quite
> > freque
I think this is +1 for moving the conversation to a less crowded location.
Sorry guys I know I keep promising to take care of it but I've been swamped
all day. I'll try to find some time though.
--Kris
On Tue, Feb 28, 2012 at 4:28 PM, Anthony Ferrara wrote:
> Richard,
>
> This is not overloadi
able to get this through. Though
it's possible I might be overestimating that factor.
--Kris
On Tue, Feb 28, 2012 at 5:17 PM, John Crenshaw wrote:
> > On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer >wrote:
> >
> > > On 2/28/2012 2:58 PM, Kris Craig wrote:
> > >
Agreed. Discussion about type hinting/etc should remain on the other
topics.
Regarding this proposal, I need to look over it in more detail as I've only
just skimmed it. But on a conceptual level at least, I think it definitely
has merit.
--Kris
On Tue, Feb 28, 2012 at 6:40 PM, Anthony Ferrar
; arrays)
> > >>or bind a variable to a strict type?
> > >> - should it then also be possible bind variables to a specific
> > >> class or interface?
> > >>- should we go for weak or strong types?
> > >> - the type-hin
February 28, 2012 5:17 pm, Kris Craig wrote:
>
> Some cases I would find interesting to be explained:
>
> (using 'streak' for strong and/or weak, feel free to separate the two)
>
> streak int $i = 123.456; //Common idiom for floor()
> streak int $i = "123.456&quo
into an int, the developer might decide that going with a weak type
would make it more flexible (though if it was me, I'd just do a round or
leave it a mixed type lol).
--Kris
On Wed, Feb 29, 2012 at 11:09 AM, Kris Craig wrote:
> @Richard I think you made a very good point. Should we
unction __castTo(string $type) {
> if ($type === "integer")
> return 5;
> }
> }
>
> function foo(integer $i) {
> // do something
> }
>
> foo(new MyInteger()); // Even if this is an object - it's cast-able to an
> integer and therefore
dure on this (at least none that I'm
aware of), what are your thoughts on this? I do believe the two should be
in the same vote since they're pretty integral to one another, but I'm not
sure how best to do that while maintaining accurate results without making
it too complicated.
--
discussion, I suggest you take a look
> at that RFC - confine yourselves to only work on stuff that stands a chance
> to get accepted (no strict typing) - and try to come up with good answers
> to the open questions. No point in redoing the whole discussion from
> scratch.
>
&g
return type-hinting.
>
> So .. here's quite a lot of work to do to gather the people who wrote
> these RFCs and let their ideas float into one specific definition with
> several options how to implement them.
>
>
> Bye
> Simon
>
> 2012/2/29 Kris Craig
>
>>
having this in their
inboxes. Plus it would give those of us who are actually interested in
this a place to brainstorm without old fear tactics periodically being
reintroduced in an effort to derail the conversation. I'll investigate
such options as soon as I have some spare moments. It's been a busy we
I would challenge the preconceived notion that it's likely to be rejected.
It winds up being a form of circular logic. For example, you argued that
previous tries failed to be approved because nobody wanted to do the work.
But then you said that nobody wants to do the work because it has failed to
ore it if it ever comes to a vote, nor will the others.***
> *
>
> ** **
>
> Troll away.****
>
> ** **
>
> Zeev
>
> ** **
>
> ** **
>
> *From:* Kris Craig [mailto:kris.cr...@gmail.com]
> *Sent:* Thursday, March 01, 2012 12:16 AM
>
> *To:* Zeev Suraski
I agree. I'm against strict type hinting as well. Of course, nobody here
is suggesting that we should go with strict typing, so it's a moot question
anyway.
--Kris
On Wed, Feb 29, 2012 at 2:35 PM, Arvids Godjuks wrote:
> Please.read my emails carefuly. What i said is last time the work has be
If you think it's a good idea, then why vote against it? Seems kinda
strange to me.
This issue isn't going to go away. If you really want it to stop coming up
every 6 months because people are *constantly* requesting it, maybe we
should find a way to implement something that would appease this c
r)) and if that's not
> bastardizing a concept...
>
> I think the community has spoken. And when the core devs put their foot
> down, I think it's best to listen. If it's so important to you, then by all
> means, fork. Or simply write a patch. Put it to a vote. But
I respectfully disagree. We've already covered this actually. The same
argument could have been (and probably was) made that stricter adherence to
OO standards in PHP 5 would break the PHP paradigm. Instead, it made PHP
considerably better and opened it up to a much wider audience. People are
s
h forward (not right now at least) but they fit in
> our discussion and were written in an RFC that was related to what I wanted.
>
> @Kris:
>
> > I prefer the latter, which is why I am now pushing this.
> What I am very thankful for ;)
>
> Bye
> Simon
>
>
>
second vote-level. The first level could be
> "Like / Dislike this feature" and the second one could be "Like Solution1 /
> Like Solution2 / Like Solution3"
>
> Bye
> Simon
>
>
> 2012/3/1 Kris Craig
>
>> @Simon Well said! For some reason, the iss
1 - 100 of 528 matches
Mail list logo
