At 23:06 07/06/2005, Andrey Hristov wrote:
Quoting Ondrej Ivani? <[EMAIL PROTECTED]>:
Zeev Suraski wrote:
damage than good. And the fact we may have made mistakes in the past
and have unnecessary constructs already, doesn't mean we should do it
again.
Yes, PHP is on the right way.
PHP is on
Submitting new functions to the PHP core.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, 2005-06-07 at 22:01, Andrei Zmievski wrote:
> Godwin's Law.
Quirk's exception.
Cheers,
Rob.
--
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An
Godwin's Law.
-Andrei
On Jun 7, 2005, at 5:00 PM, Adam Maccabee Trachtenberg wrote:
On Tue, 7 Jun 2005, Andrei Zmievski wrote:
This thread has exceeded the internal per-thread message limit of
ezmlm and has been officially closed. If you find that you have
further energy to contribute, ple
On Tue, 7 Jun 2005, Andrei Zmievski wrote:
> This thread has exceeded the internal per-thread message limit of
> ezmlm and has been officially closed. If you find that you have
> further energy to contribute, please direct your attention to http://
> bugs.php.net/. Have a nice day.
Nazi. :)
-ada
This thread has exceeded the internal per-thread message limit of
ezmlm and has been officially closed. If you find that you have
further energy to contribute, please direct your attention to http://
bugs.php.net/. Have a nice day.
On Jun 7, 2005, at 3:13 PM, Ondrej Ivanič wrote:
Andrey Hr
Member of the catalan translation.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Andrey Hristov wrote:
> WTF?!?
> If you need Java, then go use Java. If you want String object, do it
> yourself.
Some people need goto, some people need phpjava, it's life. It's was my
wishlist and I like php as is. I can't implement this features by
myself. It's to hard for me create php extensi
Member of the Catalan translation team.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
We are a group of people willing to start a catalan translation of the
documentation. I've contacted the phpdoc list and read the Documentation HOWTO
so I expect the work could start soon.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.ph
Hi,
[...]
> Any feature can and as experience proves it to be the case, will be
> abused. Plenty of people make horrid abuse of exceptions, but
> we still went ahead an added them anyway since they have many
> practical and useful applications. Same is true for goto, some
> people will surely
On 6/7/05, Jason Garber <[EMAIL PROTECTED]> wrote:
> That being said, we need carefully evaluate the plusses and minuses
> of adding a feature:
Thanks, Jason, that pretty much sums it up. Although we disagree, I
think you got a very reasonable view of the situation, and one that
helps solve th
Quoting Ondrej Ivani? <[EMAIL PROTECTED]>:
Zeev Suraski wrote:
damage than good. And the fact we may have made mistakes in the past
and have unnecessary constructs already, doesn't mean we should do it
again.
Yes, PHP is on the right way.
PHP is on the begin of moving from functional to full
Zeev Suraski wrote:
> damage than good. And the fact we may have made mistakes in the past
> and have unnecessary constructs already, doesn't mean we should do it
> again.
Yes, PHP is on the right way.
PHP is on the begin of moving from functional to full 00 code. IMHO in
00 code there isn't plac
On Tue, 2005-06-07 at 18:21 +0300, Stanislav Malyshev wrote:
> Here I see all kinds of spagetti code already brewing... Tree drawing with
> goto... Yuck.
I don't think this discussion should be about what you consider ugly or
not, but if there is a reasonable desire for the construct and the
tec
At 18:28 07/06/2005, Jason Garber wrote:
Hello,
I don't know if chiming in at this point has any merit, but here is
what I see.
We have many, many people in favor of goto and ifsetor. They see
much legit use for those constructs.
Then, we have others who say that it will result in s
On Mon, 6 Jun 2005, Derick Rethans wrote:
> If you have any issues that you really want to get fixed in PHP 4.4,
> please reply to this email (on the internals@ list).
If there is nothing, I'd like to start releasing RC1 on Monday.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | h
Yeah. I don't understand all those arguments anyway. Since when does it
matter what evil things you can do with a language feature? I'm seeing the
usual bs like
echo $foo[bar];
or
mysql_connect("$host", "$user", "$pass");
every second day.
Guys, you better whine about those people instead of acc
On Tuesday 07 June 2005 18:28, Jason Garber wrote:
> Hello,
>
> I don't know if chiming in at this point has any merit, but here is
> what I see.
>
> We have many, many people in favor of goto and ifsetor. They see
> much legit use for those constructs.
>
> Then, we have others who say t
> GS>>Well, point a) implied that it's a solvable problem, at least as much
as it
> GS>>is when doing any sort of premature exit from a block.
>
> It's worse problem since we are going to jump to random place and not just
> to the end of the block. At the end of the block we could have opcode that
Hello,
I don't know if chiming in at this point has any merit, but here is
what I see.
We have many, many people in favor of goto and ifsetor. They see
much legit use for those constructs.
Then, we have others who say that it will result in spaghetti code.
This is a completely inval
IA>>1) Any state machine parser, such as the one frequently found in templating
IA>>systems. Using goto "alternatives" makes code quite cumbersome and not to
IA>>mention slow.
IA>>
IA>>2) Code flow control for error handling.
IA>>
IA>>3) A faster & safer alternative to recursive loops in many situa
DR>>> to the end of the block. At the end of the block we could have opcode
that
DR>>> takes care of that. At random place, we can't have it.
DR>>
DR>>But we can have it when the function ends.
Function can end in a number of different places and in order of function
execution unlimited number
>
> > As for my own example, many state machines make extensive
> use of goto
> > to avoid recursive calls.
>
> Goto is not required for that. State machines such as the
> following
>
> state1:
> ...
>
> goto state99;
>
> state99:
>
> Nelson's 'tone' is not worth commenting.
I'm sorry if I offended anyone with my tone. I've followed the goto
'issue' from the security of the Zend weekly summaries, and I thought
I'd share my 2 cents: I do think that users' opinions should be
considered when designing major features, and that's
Stanislav Malyshev wrote:
GS>>Perl's goto specifically forbids jumping into control structures that
GS>>require intialization (for instance, foreach()). That seems like a
GS>>sensible limitation to me.
jumping out is no good either.
If jumping in/out of foreach is the only technical proble
On Tue, 7 Jun 2005, Stanislav Malyshev wrote:
> GS>>Well, point a) implied that it's a solvable problem, at least as much as
> it
> GS>>is when doing any sort of premature exit from a block.
>
> It's worse problem since we are going to jump to random place and not just
> to the end of the block
GS>>Well, point a) implied that it's a solvable problem, at least as much as it
GS>>is when doing any sort of premature exit from a block.
It's worse problem since we are going to jump to random place and not just
to the end of the block. At the end of the block we could have opcode that
takes c
On Jun 7, 2005, at 8:55 AM, Stanislav Malyshev wrote:
GS>> b) a problem that self-rectifies at the end of the request (as
per
GS>>Derick's discussion).
So you basically is saying "let's ignore memory leaks".
Well, point a) implied that it's a solvable problem, at least as much
as it is w
GS>> b) a problem that self-rectifies at the end of the request (as per
GS>>Derick's discussion).
So you basically is saying "let's ignore memory leaks".
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115
--
PHP Internals - PHP Runt
On Jun 7, 2005, at 8:46 AM, Sascha Schumann wrote:
As for my own example, many state machines make extensive use of
goto to avoid recursive calls.
Goto is not required for that. State machines such as the
following
You conveniently ignored the part of my mail where I noted that
On Jun 7, 2005, at 8:43 AM, Stanislav Malyshev wrote:
GS>>Perl's goto specifically forbids jumping into control
structures that
GS>>require intialization (for instance, foreach()). That seems
like a
GS>>sensible limitation to me.
jumping out is no good either.
Because of the memory issu
GS>>you were just in AUTOLOAD, but were in the overloaded function
GS>>instead. It's a standard (albeit advanced) Perl idiom.
Huh. That's has nothing to do with our current discussion, doesn't it?
It's just special kind of function call, for some reason named 'goto'.
GS>>primitives. PHP is f
As for my own example, many state machines make extensive use of goto to
avoid recursive calls.
Goto is not required for that. State machines such as the
following
state1:
...
goto state99;
state99:
...
goto state2;
On Monday 06 June 2005 14:37, Derick Rethans wrote:
> On Mon, 6 Jun 2005, Stanislav Malyshev wrote:
> > MR>>expose the ugliness of what would _appear_ to be a handy feature. I
> > MR>>don't pack any weight on this list so if someone with a -1 on this
> > MR>>feature would like to kick it up to -2 I
On Monday 06 June 2005 14:37, Derick Rethans wrote:
> On Mon, 6 Jun 2005, Stanislav Malyshev wrote:
> > MR>>expose the ugliness of what would _appear_ to be a handy feature. I
> > MR>>don't pack any weight on this list so if someone with a -1 on this
> > MR>>feature would like to kick it up to -2 I
On Tuesday 07 June 2005 13:42, Derick Rethans wrote:
> On Tue, 7 Jun 2005, Nelson Menezes wrote:
> > > Uh? EVERY parser generater that I know of uses goto, and it's
> > > definitely not a problem if the generate 'spagetticode' - as nobody
> > > ever has to even look at that code.
> >
> > If you wan
GS>>Perl's goto specifically forbids jumping into control structures that
GS>>require intialization (for instance, foreach()). That seems like a
GS>>sensible limitation to me.
jumping out is no good either.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.co
On Jun 7, 2005, at 8:25 AM, Stanislav Malyshev wrote:
GB>>control structures are not useful. This is not the case in PHP. A
GB>>simple example in the manual showing proper usage of break/
continue
GB>>and warning to only use goto as a last resort would be
sufficient for
GB>>discouraging ne
On Jun 7, 2005, at 8:12 AM, Stanislav Malyshev wrote:
GS>>And yet it exists and people use it productively - so you've
GS>>successfully undermined your own argument (and Perl's goto is
far more
GS>>flexible|evil than the one proposed for PHP).
Care to give example where it is really needed a
GB>>control structures are not useful. This is not the case in PHP. A
GB>>simple example in the manual showing proper usage of break/continue
GB>>and warning to only use goto as a last resort would be sufficient for
GB>>discouraging newbies from shooting their feet off.
The problem is not only
Stanislav Malyshev wrote:
GS>>I don't think I've ever heard Perl or C maligned on the basis of their
GS>>support for goto. Perhaps I just travel in the wrong circles.
I didn't ever saw any need in Perl goto - except for goto& construct which
isn't goto at all. As for C goto - it's usually use
Stanislav Malyshev wrote:
GS>>I don't think I've ever heard Perl or C maligned on the basis of their
GS>>support for goto. Perhaps I just travel in the wrong circles.
I didn't ever saw any need in Perl goto - except for goto& construct which
isn't goto at all. As for C goto - it's usually use
GS>>Still, goto is the discussion, let's not create strawmen of things not
GS>>on the table.
That was an illustration - C is a different language and C programmer
sometimes has no choice. We still do.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/ +972-
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
AH>>Does C suffer from having goto?
Does C suffer from being able to freely convert any type to any and access
any memory location? Should we add these features too?
--
The first one we already have - you can convert from every to every type. My
> I don't think I've ever heard Perl or C maligned on the basis of
> their support for goto. Perhaps I just travel in the wrong circles.
Perl or C don't get used by people who're in the first stages of
learning to code; you usually build some experience of how not to do
things when you move to th
GS>>And yet it exists and people use it productively - so you've
GS>>successfully undermined your own argument (and Perl's goto is far more
GS>>flexible|evil than the one proposed for PHP).
Care to give example where it is really needed and can't be trivially
reduced to labeled break?
--
Stani
On Jun 7, 2005, at 8:08 AM, Stanislav Malyshev wrote:
AH>>Does C suffer from having goto?
Does C suffer from being able to freely convert any type to any and
access
any memory location? Should we add these features too?
Funny, I was just talking with Andi about that at dinner the other
SE>>possibility to databases. Both can be misused and lead to really bad
SE>>security holes...
This has nothing to do with security - we are talking about entirely
different things, namely code quality and robustness.
You are speaking about abusing a feature. And I tell you that I can
abuse m
Quoting Stanislav Malyshev <[EMAIL PROTECTED]>:
EK>>number on the ratio of abuse vs. use of this new feature.
So far, I personally saw one legitimate use brought up - exiting control
blocks, which can be handled with another proposal, labeled breaks.
Another use brought up - claim that parsers
EK>>sapi/cli/php_cli.c. I don't see why having ability to jump out on
EK>>error like goto end; or goto end_clean; and such would be a bad
EK>>addition to the language.
This is solved by labeled break, as I said number of times - and yes, I'm
not against this addition. What I am against is abili
On Jun 7, 2005, at 8:00 AM, Stanislav Malyshev wrote:
GS>>I don't think I've ever heard Perl or C maligned on the basis
of their
GS>>support for goto. Perhaps I just travel in the wrong circles.
I didn't ever saw any need in Perl goto - except for goto&
construct which
isn't goto at all.
AH>>Does C suffer from having goto?
Does C suffer from being able to freely convert any type to any and access
any memory location? Should we add these features too?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115
--
PHP Internals
On Tuesday 07 June 2005 14:00, Stanislav Malyshev wrote:
> I didn't ever saw any need in Perl goto - except for goto& construct which
> isn't goto at all. As for C goto - it's usually used as replacement for
> multilevel break/continue or in weird code like lexx parsers, and is
> generally frowned
Quoting Nelson Menezes <[EMAIL PROTECTED]>:
> Goto is a plainly bad idea. Yes it has its uses, but 99% of
> the time it would just be completely, mercilessly, utterly abused.
Its not good or bad, just a language construct. Its how you use it.
I agree. I just think it will be used badly in mos
SE>>influence on the reputation of PHP. And I can only guess why the
SE>>negative voices from the Zend corner are raised...
I don't see any need to guess - I explained why in numerous occasions. Do
you have any questions or something is not clear? Or do you mean somebody
other? BTW, this opinio
GS>>I don't think I've ever heard Perl or C maligned on the basis of their
GS>>support for goto. Perhaps I just travel in the wrong circles.
I didn't ever saw any need in Perl goto - except for goto& construct which
isn't goto at all. As for C goto - it's usually used as replacement for
multil
Hello,
I agree. I just think it will be used badly in most instances, and PHP
reputation will suffer as a result. IMHO that's a bad tradeoff when
you consider the advantages you get from goto.
Could you guys please stop the bullshit? An added goto statement will
not decrease the security of P
On Jun 7, 2005, at 7:37 AM, Nelson Menezes wrote:
Goto is a plainly bad idea. Yes it has its uses, but 99% of
the time it would just be completely, mercilessly, utterly abused.
Its not good or bad, just a language construct. Its how you use it.
I agree. I just think it will be used badly
EK>>number on the ratio of abuse vs. use of this new feature.
So far, I personally saw one legitimate use brought up - exiting control
blocks, which can be handled with another proposal, labeled breaks.
Another use brought up - claim that parsers can't work without it - don't
seem to me a valid
> > Goto is a plainly bad idea. Yes it has its uses, but 99% of
> > the time it would just be completely, mercilessly, utterly abused.
>
> Its not good or bad, just a language construct. Its how you use it.
I agree. I just think it will be used badly in most instances, and PHP
reputation will suf
On Tuesday 07 June 2005 12:27, Nelson Menezes wrote:
> Goto is a plainly bad idea. Yes it has its uses, but 99% of the time
> it would just be completely, mercilessly, utterly abused.
>
> As the people taking the language forward, it's the responsability of
> PHP developers not to introduce feature
> Noone is forcing you to use goto. You can spend a lot of time on the
> language, but nontheless, there will always be people that wants to
> shoot themselves in the foot.
I know no-one is. I even agree that goto has its proper uses, and I'd
probably find a couple myself. That's not the point. If
> Goto is a plainly bad idea. Yes it has its uses, but 99% of
> the time it would just be completely, mercilessly, utterly abused.
Its not good or bad, just a language construct. Its how you use it.
> As the people taking the language forward, it's the
> responsability of PHP developers not to
Nelson Menezes wrote:
I'm a professional PHP developer who doesn't like to see the language
get smeared and bad-named every time a oh-so-neat feature is taken by
90% of "web developers" and misused in such a way that makes code
unmaintainable and insecure. Go have a look at the number of security
Sheesh, here we go again...
I'm a professional PHP developer who doesn't like to see the language
get smeared and bad-named every time a oh-so-neat feature is taken by
90% of "web developers" and misused in such a way that makes code
unmaintainable and insecure. Go have a look at the number of sec
On Tue, 7 Jun 2005, Nelson Menezes wrote:
> > Uh? EVERY parser generater that I know of uses goto, and it's definitely
> > not a problem if the generate 'spagetticode' - as nobody ever has to
> > even look at that code.
>
> If you want to build a full-blown parser, PHP is not your language. If
>
Goto is a plainly bad idea. Yes it has its uses, but 99% of the time
it would just be completely, mercilessly, utterly abused.
As the people taking the language forward, it's the responsability of
PHP developers not to introduce features that you just know in advance
are going to drag the language
DR>>Uh? EVERY parser generater that I know of uses goto, and it's definitely
I bet there's no parsers for anything written in Java - Java doesn't have
goto ;)
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115
--
PHP Internals - PHP
On Tue, 7 Jun 2005, Stanislav Malyshev wrote:
> JW>>PHP Code generation tools?
>
> So, what with them? You want to encourage PHP CG tools to generate
> spaghetti soup of code?
Uh? EVERY parser generater that I know of uses goto, and it's definitely
not a problem if the generate 'spagetticode'
JW>>PHP Code generation tools?
So, what with them? You want to encourage PHP CG tools to generate
spaghetti soup of code?
JW>>There is a lot of useful code generation tools out there that would be
JW>>useful when developing in PHP, but quite a few use goto, so porting to
JW>>PHP output becomes
Magnus Määttä wrote:
> I don't see how putting a name on the number makes it any better and I
> still would have to emulate it with loops and breaks and continues,
> unless it's actually a code word for goto ;)
your code with named breaks/continues:
continue_label:
for (...; ...; ...) {
bre
72 matches
Mail list logo
