On 12/1/05, Jared White <[EMAIL PROTECTED]> wrote:
> I still say its main selling point is
> that the calling code is its own API documentation.
why don't you just write something like
cycle(/* name: */ "myCycle", /* values: */ "#ee;#d0d0d0", /*
print: */ false,
/* reset: */ true, /* delimite
On 11/30/05, Ron Korving <[EMAIL PROTECTED]> wrote:
> Same for our company. We still use http://www.php.net/unsub.php
On 11/30/05, Ron Korving <[EMAIL PROTECTED]> wrote:
> I loved Joao Cruz Morais idea of using the 'as' keyword in this:
>
> while (true) as outer_cycle {
> $i = 0;
> while (true)
> if($i++ == 10) break outer_cycle;
> }
Me too - it's so stunningly obvious to understand at first sight,
compar
On 11/26/05, Jani Taskinen <[EMAIL PROTECTED]> wrote:
>
> So you're also for letting PEAR dictate what PHP has and not the other
> way around? Somehow this doesn't sound right.
This is not about PEAR dictating, and the PEAR developers are not
those who would suffer from this PHP date cla
Hello Marcus,
On 11/26/05, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> A lexer splits on tokens while white space is optional. If present it
> allows separation of tokens. Forcing this would make whitespace a token
> which would be very bad. The parser then works on the tokens and doesn't
> see an
On 11/26/05, Marcus Boerger <[EMAIL PROTECTED]> wrote:
> The only thing that matters is whether i can write a correct
> lexer/parser for this without breaking stuff.
Im no parser expert at all, so just to be sure that I understand the
problem correctly: I guess you can't distinguish at the parser/
On 11/25/05, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> Does this include anytime a new function/class is added we need to make
> a prominent notice about since it reserves some name space?
Yes of course, especially if it's such an obvious name like "date".
As opposed to some statements on thi
> This rename would also give us a migration path where you could have a
> simple: class date extends date_ex { ... } wrapper which could then be
> removed when we have the final internal date class implementation.
IMVHO this is a good idea. At least I greatly appreciate that it
wouldn't break app
> > So why
> > don't you just patch your own PHP for that purpose? Because you're a
> > core developer?
>
> No, because that was a bug fix which people still don't get.
At least I got it and we swallowed that bitter pill in 4.4.0 that lots
of our OO PHP client projects broke unadvertedly with the
> Yes, and that will break code again as I just explained to Sebastian
> Kettler. And it will break *my* code ;-)
Why does it have to be in core php in order for *your* code to run smoothly?
I'd like to remind you that if was *you* who proposed some weeks ago
that people should patch and maintain
Derick,
> you will break code that is out there.
do you have an idea how much code is "out there" that has classes named "Date"?
> But you can
> definitely not change code in a released version.
Above all, you can definitely not introduce new classes in RC6!
And this date class doesn't even se
11 matches
Mail list logo
