On Wed, Oct 17, 2012 at 2:49 AM, Pierre Joye wrote:
> Marcello likes to write a RFC
>
> On Wed, Oct 17, 2012 at 11:28 AM, Marcello Duarte
> wrote:
>> Hi,
>>
>> Can I please have a wiki account?
>>
People who cannot read do not get wiki karma:
https://wiki.php.net/start?do=register :(
-Hannes
-
I was really referring to another tool to collaborate on an RFC document,
something where comment threads can be started and replied to from within the
context/section of the RFC that the comment belongs to.
Ive looked at a few other wikis and some have this capability... Github could
be close
On Wed, Oct 17, 2012 at 3:07 PM, Maciek Sokolewicz
wrote:
>
> NNTP works great! The only pain in the ass is that it's hellishly slow and
> very very often times out, making the reading of longer threads (like this
> one) take... ages...
> Perhaps it could be mirrored / load distributed as well? Da
This request was given a +1 from Wez - does anyone else want to provide
feedback? If not, can we get it merged to trunk and queued for release?
On Wed, Oct 3, 2012 at 2:02 PM, Will Fitch wrote:
> Going to bump this thread.
>
> https://bugs.php.net/bug.php?id=62593
> https://github.com/php/php-sr
On 17-10-2012 20:42, Pierre Joye wrote:
On Wed, Oct 17, 2012 at 7:02 PM, Jeremiah Dodds
wrote:
That said, it's a little ridiculous to expect people to figure out a new
reader or whatever. Luckily, forums are jut a web version of
USENET. There are a few existing tools that take a mailing list a
Pierre Joye writes:
> On Wed, Oct 17, 2012 at 7:02 PM, Jeremiah Dodds
> wrote:
>
>> That said, it's a little ridiculous to expect people to figure out a new
>> reader or whatever. Luckily, forums are jut a web version of
>> USENET. There are a few existing tools that take a mailing list and
>> m
On Wed, Oct 17, 2012 at 7:02 PM, Jeremiah Dodds
wrote:
> That said, it's a little ridiculous to expect people to figure out a new
> reader or whatever. Luckily, forums are jut a web version of
> USENET. There are a few existing tools that take a mailing list and
> mirror it to a web-based forum a
On 17/10/12 11:43, Pierre Joye wrote:
> It is about hi jacking discussions with totally irrelevant topics,
> repetitive, nonconstructive posts in rows, in all possible ways.
The issue is that the proposed solution (a forum) does not solve
irrelevant topics being mixed into a discussion about a dif
(sorry if this is a double-post, I finger-fudged pretty hard)
Pierre Joye writes:
> hi,
>
> To all readers of this exact thread. No, we won't install a forum on
> php.net or nowhere else to discuss php.net issues. We have mailing
> lists, and it works well.
Just to throw in the opinion of some
Nuno - just a PS to the last note. It is (mainly) the task allocation
across processors which means that running tests in parallel on a 4-way
machine is not 4 times as fast as running them in sequence.
Here are some results from a run on my 2-way Mac -
http://static.inky.ws/image/3257/image.jp
I acquiesce to this issue, I agree that declaring a property in a class which
implements an interface which has designated an accessor does indeed satisfy
the accessor.
But I think it would be very poor programming practice to do it.
Anyone else have anything to say about this issue?
> -
2012/10/17 Stas Malyshev
> No, you don't get an error. You'd get an error in compiled language. In
> dynamic language, your client gets an error when his site is launched
> and instead of happy launch his users get white screens. To avoid that,
> you'd need to add checks - or just ship it as is a
I've been re-reading the last few days of posts to collect what is to be
changed about the RFC on what has seemed to come to a consensus and my
apologies Stas, I did not catch exactly what you meant by this statement:
> > Exactly my point. Your code (with != NULL) will return false while real
>
On Wed, Oct 17, 2012 at 1:51 PM, Clint Priest wrote:
>> > This isn't the way isset() works, isset() will return true for a
>> > variable with a value of 0
>>
>> Exactly my point. Your code (with != NULL) will return false while real
>> isset() will return true.
>
> Stas, please see this execution
> > This isn't the way isset() works, isset() will return true for a
> > variable with a value of 0
>
> Exactly my point. Your code (with != NULL) will return false while real
> isset() will return true.
Stas, please see this execution output, your arguments about isset()/unset()
are just plain
On Wed, Oct 17, 2012 at 1:24 PM, Stas Malyshev wrote:
> Hi!
>
>> You have already written seven mails all saying how much complexity
>> this would introduce. Could you maybe elaborate a bit on that? How
>> would it make anything more complex? I mean, the only really
>
> Any code that deals with me
Hi!
> You have already written seven mails all saying how much complexity
> this would introduce. Could you maybe elaborate a bit on that? How
> would it make anything more complex? I mean, the only really
Any code that deals with methods would now have to consider - is this
regular method or spe
On Wed, Oct 17, 2012 at 1:07 PM, Stas Malyshev wrote:
>> I see this argument crop up with every typehint discussion and just
>> don't understand it at all. Why would you want to check the variable
>> type everywhere? You just assign it and if it doesn't work, then you
>> get an error. Just like it
That would be a big help, when there are 14 topics brought up in a single
email, it generates 24 - 36 replies. I tried to separate the topics with new
email threads but that led to cross-topic issues as well.
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent:
On Wed, Oct 17, 2012 at 12:11 PM, Stas Malyshev wrote:
> Hi!
>
>> That makes some sense, still the issue Nikita brought up is that the
>> __getHours() should not be callable.
>
> I don't see any use case for this requirement. What *requires* that it
> won't be callable and why it is so necessary t
Hi!
> I see this argument crop up with every typehint discussion and just
> don't understand it at all. Why would you want to check the variable
> type everywhere? You just assign it and if it doesn't work, then you
> get an error. Just like it should be. I mean, do you seriously check
No, you do
On Tue, Oct 16, 2012 at 12:55 PM, Stas Malyshev wrote:
>> Last thing: I agree with Clint and you. If it was early checked, it
>> would be better. But the current type hinting is far better than nothing
>> at all. Yes, we can't "lint" it, but it was pretty useful a big number
>
> No, it's not bette
On Mon, Oct 15, 2012 at 2:11 PM, Clint Priest wrote:
> So the above would actually introduce an get/set accessor rather than a
> property, correct?
Preferably it would a faster C based implementation for the check, but
in principle it could also use accessors to achieve the goal.
> If we were to
On Tue, Oct 16, 2012 at 11:58 AM, Stas Malyshev wrote:
>> Type hinting in parameters is a really good thing, and it doesn't
>> transformed PHP in a strongly typed language.
>
> It however gave a permission to people to try sneak in strong-typedness
> through various backdoors arguing exactly that:
Hi!
> It is foolish to think that these two bits of code are behaviorally different:
>
> class Entity {
> DateTime $last_modified;
> }
The are different because this one looks like a strongly typed variable
which brings with it a lot of connotations which aren't immediately
obvious, and in f
Hi!
> That makes some sense, still the issue Nikita brought up is that the
> __getHours() should not be callable.
I don't see any use case for this requirement. What *requires* that it
won't be callable and why it is so necessary that we introduce
additional complexity into the engine just to do
Marcello likes to write a RFC
On Wed, Oct 17, 2012 at 11:28 AM, Marcello Duarte
wrote:
> Hi,
>
> Can I please have a wiki account?
>
> Regards,
> Marcello
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Pierre
@pierrejo
hi,
On Wed, Oct 17, 2012 at 11:21 AM, Lester Caine wrote:
> Clint Priest wrote:
>>
>> I was thinking more along the lines of a collaborative wiki with
>> inline-threaded comments...
>
> Actually just using the wiki better would work, but it tends to get even
> more messy without someone moderatin
Hi,
Can I please have a wiki account?
Regards,
Marcello
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Clint Priest wrote:
I was thinking more along the lines of a collaborative wiki with
inline-threaded comments...
Actually just using the wiki better would work, but it tends to get even more
messy without someone moderating everything.
I know people don't like my stance, but when one is suppo
hi,
To all readers of this exact thread. No, we won't install a forum on
php.net or nowhere else to discuss php.net issues. We have mailing
lists, and it works well.
We also do IRC discussions and post summaries here from time to time,
but that's somehow a personal matter.
Please keep focus on t
On Tue, Oct 16, 2012 at 8:34 PM, Clint Priest wrote:
> I was thinking more along the lines of a collaborative wiki with
> inline-threaded comments...
>
> > -Original Message-
> > From: Jan Ehrhardt [mailto:php...@ehrhardt.nl]
> > Sent: Tuesday, October 16, 2012 8:00 PM
> > To: internals@l
32 matches
Mail list logo
