On 2011-08-12, Lester Caine wrote:
> Johannes Schlüter wrote:
> > > > Actually the real question here is WHY create a fork on github
> > > > at all? The copy you are working on LOCALLY is the fork that you
> > > > are developing on? Much of the stuff on github and the other
> > > > DVCS server sit
On 2011-08-12, Lester Caine wrote:
> Ferenc Kovacs wrote:
> > > But you can't call it PHP anymore due to the license, where as with a
> > > > DCVS with people having forks on publically accessible repositories,
> > > > everybody is basically violating the license.
> > > >
> > you can rename your
Hello Stas,
On Mon, Aug 15, 2011 at 1:26 AM, Stas Malyshev wrote:
> Hi!
> It's not a shortcoming, it was designed that way, and for very serious
> reasons. If you want to know the reasons, there were discussed extensively
> when namespaces were discussed. Please re-read that discussion. And all
>
Hello,
On Mon, Aug 15, 2011 at 2:30 PM, Matthew Weier O'Phinney
wrote:
> On 2011-08-14, Derick Rethans wrote:
>> On Sat, 6 Aug 2011, Ferenc Kovacs wrote:
>> > I would like to introduce this RFC which would provide function
>> > autoloading through the spl_autoload facility without userland BC
>>
On 2011-08-14, Derick Rethans wrote:
> On Sat, 6 Aug 2011, Ferenc Kovacs wrote:
> > I would like to introduce this RFC which would provide function
> > autoloading through the spl_autoload facility without userland BC
> > breakage.
> >
> > https://wiki.php.net/rfc/autofunc
>
> I understand the pr
On 8/14/2011 3:42 PM, Lester Caine wrote:
Gwynne Raskind wrote:
The only real disadvantage to hg is having to handle python code to
maintain
> it, people might start converting from PHP;) Although phphgadmin is
a start
> to improving the php interface support and could be a good start at
a fully
I'm not talking about the __call() magic method, I'm proposing a global
and/or namespaced call to a flat __call() *function *- you could use it to
implement autoloading like so:
*
*
closure) and loading scripts that return an anonymous
function.
Similarly, we could use a namespace-specific __call
On Mon, Aug 15, 2011 at 10:20 AM, Lester Caine wrote:
> Perhaps it should be linked in the SeeAlso from strncmp and the rest?
I added substr_compare to the See Also sections of strcmp, strcasecmp,
strncmp and strncasecmp.
Apart from that: Now that we know that a function for doing such
comparison
Laruence wrote:
> I think we are not talking about how to accomplish a function, we
> are talking about how to do it better
>
> and, in fact, I think strrev is need more cpu time and alloc space,
> although they are very tiny :)
I very much doubt it's ever going to be a bottleneck (and I thi
Hi Rasmus:
could we well docuemnt this(changelog) to avoding such bad thing happen?
and sure, I agree and know what you are worried, also I am very
respect you .
so here is the thing, if I can't get your support, I think I
should darw back the proposal.
thanks
2011/8/15 Rasmus Lerd
On Mon, Aug 15, 2011 at 10:26 AM, Stas Malyshev wrote:
> Hi!
>
> On 8/15/11 12:54 AM, Ferenc Kovacs wrote:
>>
>> I know that the bad decisions in the past won't count in this
>> argument, but the current "namespace resolution falls back to the
>> global namespace" is the one to blame for this shor
Laruence wrote:
I totally agree with you about bc break things,
but actully I don't think this proposal will bring a big bc break,
it's a new approach , but not a big change,
I am meaning that the old codes can work fine because rarely codes
depends on a negative length.
do you
On 08/15/2011 01:51 AM, Laruence wrote:
> Hi Lester:
>I totally agree with you about bc break things,
>
>but actully I don't think this proposal will bring a big bc break,
> it's a new approach , but not a big change,
>
>I am meaning that the old codes can work fine because rarely cod
Hi Lester:
I totally agree with you about bc break things,
but actully I don't think this proposal will bring a big bc break,
it's a new approach , but not a big change,
I am meaning that the old codes can work fine because rarely codes
depends on a negative length.
do you agree?
th
Hi!
On 8/15/11 1:20 AM, Lester Caine wrote:
probably part of unicode compatibility, and in that vane, would it be possible
to create a 'namespace' version of string functions which could be a little more
consistent, and also offer the chance to switch to full unicode comparison if
required? sb::
Hi!
On 8/15/11 12:54 AM, Ferenc Kovacs wrote:
I know that the bad decisions in the past won't count in this
argument, but the current "namespace resolution falls back to the
global namespace" is the one to blame for this shortcoming.
It's not a shortcoming, it was designed that way, and for ve
Laruence wrote:
yes, substr_compare can do it, and it also supports negative
length argument too.
I am with Rasmus ... while the BC problem he is pointing out is probably very
rare, those are the worse ones to fix when they pop up intermittently, and
usually when 10 year old code has bee
On Mon, Aug 15, 2011 at 9:15 AM, Sebastian Krebs
wrote:
> 2011/8/15 Stas Malyshev
>
>> Hi!
>>
>>
>> On 8/14/11 11:21 PM, Sebastian Krebs wrote:
>>
>>> I already made an suggestion [1], that bypass this.
>>>
>>
>> That suggestion means you can not autoload namespaced function that
>> overrides glo
2011/8/15 Stas Malyshev
> Hi!
>
>
> On 8/14/11 11:21 PM, Sebastian Krebs wrote:
>
>> I already made an suggestion [1], that bypass this.
>>
>
> That suggestion means you can not autoload namespaced function that
> overrides global function. Major WTF.
Imo overriding built-in functions is a WTF.
Hi!
On 8/15/11 12:15 AM, Sebastian Krebs wrote:
Imo overriding built-in functions is a WTF... Confusing others by changing
the behaviour of well-known functions just sounds scary.
So you want also to change namespace semantics...
However, when you really want to do this, than you can load yo
>> I already made an suggestion [1], that bypass this.
>
> That suggestion means you can not autoload namespaced function that
> overrides global function. Major WTF. Also leads to two autoload calls (one
> most probably resulting in exhaustive include path search) when autoloading
> a non-namespac
Hi:
I think we are not talking about how to accomplish a function, we
are talking about how to do it better
and, in fact, I think strrev is need more cpu time and alloc space,
although they are very tiny :)
thanks
2011/8/15 Sebastian Krebs :
>
>
> Am 14.08.2011 23:52, schrieb Rasmus Lerdor
22 matches
Mail list logo
