for (int i = 0; i < 5; i++)
{
int num = array[i];
printf("%d", num);
for (int i = 0; i < 5; i++)
printf("%d", i * num);
}
I'll try to explain it in your own language.
no declarations inside for() in C ===> your example ===> *crap*
loose typing ===> no decla
On Sat, 30 Aug 2003, Andi Gutmans wrote:
>>If so, then libxml 2.5.8 would have to be marked bad unless you can also
>>know when the other mods call their cleanup. This is a 2.5.8 issue only as
>>it was introduce in that version and fixed in 2.5.9.
>
>Can someone who knows configure well please add
Actually, with a careful implementation, backwards compatibility can be
achieved. A separate symbol table, indeed I agree, would be
undesirable. Instead, the interpreter could simply mask the other
variables of the same name during the loop, and return things to normal
afterward.
P.S.
Consider
Not so. I supplied this version earlier:
int array[] = {1, 2, 3, 4, 5};
for (int i = 0; i < 5; i++)
{
int num = array[i];
printf("%d", num);
for (int i = 0; i < 5; i++)
printf("%d", i * num);
}
On Saturday, Aug 30, 2003, at 15:19 America/New_York, Rasmus Le
On Sat, 30 Aug 2003 [EMAIL PROTECTED] wrote:
> I'm talking about the traditional for construct on which the PHP
> version is based. In PHP, that part of the for construct is somewhat
> meaningless. I'm saying that it is not as programmatically powerful as
> it could be. I understand how it currentl
At 09:56 AM 8/30/2003 -0400, Rob Richards wrote:
From: Andi Gutmans
> Ouch. Now the question is how do we solve this? Do we make ./configure
bail
> out on such versions or do we hack something into PHP so that it doesn't
> call this function more than once?
> I really want to reduce the block size
PHP has worked like this for years and people were & are happy with it. Even
if you somehow were able to convince (which is not happening) that this
change is useful, it still would not happen. A major functionality change
such as this would break backwards compatibility and render vast majority
Hi,
You have made your statement, we heard you, and you have made your point.
You will just have to accept that we do not consider this a problem and
don't intend on changing it (ever).
Please let this thread die...
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, vi
It is you who attributes such an elevating status to this discourse. I
had not intention of pretentiousness. You have, in fact, condemned
yourself:
>>PHP is designed for dummies.
On Saturday, Aug 30, 2003, at 14:55 America/New_York, Wez Furlong wrote:
OK, so how long before we get to prove God
I'm talking about the traditional for construct on which the PHP
version is based. In PHP, that part of the for construct is somewhat
meaningless. I'm saying that it is not as programmatically powerful as
it could be. I understand how it currently works (what you have been
stating), and I am sa
OK, so how long before we get to prove Godwins Law?
The way that scoping works in PHP is designed to make things as simple as
possible for the person writing a PHP script (to some extent, PHP is
designed for dummies). There is no way on earth that we can or will change
this *feature*.
So please,
On Sat, 30 Aug 2003 [EMAIL PROTECTED] wrote:
> That part of the for loop is inherently declaratory.
That's where you are wrong.
for($i=0; $i<10; $i++)
There is no declaration there at all. $i=0 is simply an assignment.
Nothing more, nothing less. Loops and other constructs do not have
separa
Dear LingWitt,
On Sat, 30 Aug 2003 [EMAIL PROTECTED] wrote:
> > - for doesn't span any declaration level and hence does not have its
> > own symbol table
>
> This is ridiculous.
No, it is reality! If you don't like our reality, but instead want to
live on your own little one-person reality,
Hi, if that bothers you so much, why don't you just write your own version
of PHP and allow ppl to download it, then we'll see how many ppl downloads
your version... You know, it's more like a feature than a bug...
--
// DvDmanDT
MSN: [EMAIL PROTECTED]
Mail: [EMAIL PROTECTED]
<[EMAIL PROTECTED]>
On Saturday, Aug 30, 2003, at 14:31 America/New_York, Marcus Börger
wrote:
Hello LingWitt,
Hi.
- PHP is typeless
Thanks, but that's established.
- for doesn't span any declaration level and hence does not have its
own
symbol table
This is ridiculous.
- PHP is not c, not C++ not Java, not...
Hello LingWitt,
- PHP is typeless
- for doesn't span any declaration level and hence does not have its own
symbol table
- PHP is not c, not C++ not Java, not...IT IS PHP
Saturday, August 30, 2003, 8:24:49 PM, you wrote:
Lic> That part of the for loop is inherently declaratory. As a result, the
That part of the for loop is inherently declaratory. As a result, the
interpreter should add any variables in that portion to the new symbol
table of that for loop. Any most other languages, that portion of the
for loop creates variables specifically in the scope of the for loop.
Other variable
PHP, is a loosely typed language. If you want a strongly typed language
where you can redeclare and re-use the same variable names within the same
scope, then use a strongly typed language. There are plenty of them
around. This will never ever change in PHP.
-Rasmus
On Sat, 30 Aug 2003 [EMAIL
On Sat, 30 Aug 2003 [EMAIL PROTECTED] wrote:
>
> On Saturday, Aug 30, 2003, at 10:33 America/New_York, Derick Rethans
> wrote:
>
> > On Sat, 30 Aug 2003 [EMAIL PROTECTED] wrote:
> >
> >> Since the inner loop declares $i again, it should mask the outer
> >> loop's
> >> $i as per other languag
I'm gonna take a look into this. Anyway I should've added an news entry
with some detail...
> No problem, bandwidth is cheap ;)
The accumulation should be countless though.
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
This is not a how-to question. This is a statement. There was not
question mark in any of my emails. This is criticism, and
criticms=>improvement=>development.
On Saturday, Aug 30, 2003, at 10:54 America/New_York, Wez Furlong wrote:
PHP is not C++.
Please go and carefully read the whole
PHP is not C++.
Please go and carefully read the whole PHP manual from start to finish, and
if you are still unsure of how to use PHP, ask your questions on the general
list.
Your posts have nothing to do with internals issues.
--Wez.
> //In the following example, the inner loop 'i' masks the ou
On Saturday, Aug 30, 2003, at 10:33 America/New_York, Derick Rethans
wrote:
On Sat, 30 Aug 2003 [EMAIL PROTECTED] wrote:
Since the inner loop declares $i again, it should mask the outer
loop's
$i as per other languages. Besides being useful, it makes more sense.
No, that's not true. You don't
Hi,
On Sat, 30 Aug 2003, Moriyoshi Koizumi wrote:
> Did you run buildconf yet?
Yes, after ./cvsclean I did.
> p.s. no need to paste all those lines :)
No problem, bandwidth is cheap ;)
regards,
Derick
--
"Interpreting what the GPL actually means is a job best left to those
Hi,
Did you run buildconf yet?
--with-libmbfl is not needed unless you want to use an external one.
Moriyoshi
p.s. no need to paste all those lines :)
Derick Rethans <[EMAIL PROTECTED]> wrote:
> See these errors:
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, vis
On Sat, 30 Aug 2003 [EMAIL PROTECTED] wrote:
> Firstly, thanks for the tip.
> Secondly, since you fixed the problems I enumerated in another version,
> it would seem that my posting is relevant to development.
That's not your decision to make. It's totally irrelevant.
Derick
--
"Interpreting
On Sat, 30 Aug 2003 [EMAIL PROTECTED] wrote:
> Since the inner loop declares $i again, it should mask the outer loop's
> $i as per other languages. Besides being useful, it makes more sense.
No, that's not true. You don't redeclare ANYTHING here... you're just
using the same variable $i, just
Firstly, thanks for the tip.
Secondly, since you fixed the problems I enumerated in another version,
it would seem that my posting is relevant to development.
Thanks,
[EMAIL PROTECTED]
On Saturday, Aug 30, 2003, at 10:22 America/New_York, Derick Rethans
wrote:
Try PHP 5, and stop mailing those
Since the inner loop declares $i again, it should mask the outer loop's
$i as per other languages. Besides being useful, it makes more sense.
Otherwise, the declaratory statement in the second loop is completely
meaningless.
On Saturday, Aug 30, 2003, at 10:21 America/New_York, Derick Rethans
On Sat, 30 Aug 2003 [EMAIL PROTECTED] wrote:
> The current support for references is mediocre at best. For instance:
>
> class foobar
> {
> var $variable;
>
> function foobar()
> {
> $variable = "foobar";
> }
> }
>
> //This form of new assignment shou
On Sat, 30 Aug 2003 [EMAIL PROTECTED] wrote:
> The inner loop $i doesn't mask the outer loop $i.
> Thus, the whole things gets screwed up.
? This example works perfectly fine. What's your problem here? What do
you mean with "mask the outer loop"? Of course if you modify $i INSIDE
the loop the o
On Sat, 30 Aug 2003, Marcus Börger wrote:
> Hello Derick,
>
> Saturday, August 30, 2003, 3:50:25 PM, you wrote:
>
>
> well you need --with-libmbfl
Well, that should be on by default if I do --enable-mbstring. We bundle
the library, so I see no reason why that other lib needs to be
'activated
Variable scope is mediocre at best. For instances:
$array = array(1, 2, 3, 4, 5);
for ($i = 0; $i < 5; $i++)
{
$num = $array[$i];
echo $num;
for ($i = 0; $i < 5; $i++)
{
echo $num * $i;
}
}
The inner loop $i doesn't mask the outer loop $i.
T
Hello Derick,
Saturday, August 30, 2003, 3:50:25 PM, you wrote:
well you need --with-libmbfl
maybe we drop --enablembstring becuase it no longer makes sense without the
lib?
--
Best regards,
Marcusmailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Developm
The current support for references is mediocre at best. For instance:
class foobar
{
var $variable;
function foobar()
{
$variable = "foobar";
}
}
//This form of new assignment should be the default
$a = & new foobar();
$b = & new foobar();
$
See these errors:
ext/mbstring/mbstring.o: In function `php_mb_parse_encoding_list':
/dat/dev/php/php-5.0.0dev/ext/mbstring/mbstring.c:343: undefined reference to
`mbfl_name2no_encoding'
ext/mbstring/mbstring.o: In function `php_mb_parse_encoding_array':
/dat/dev/php/php-5.0.0dev/ext/mbstring/mbs
From: Andi Gutmans
> Ouch. Now the question is how do we solve this? Do we make ./configure
bail
> out on such versions or do we hack something into PHP so that it doesn't
> call this function more than once?
> I really want to reduce the block size in my mem manager from 256KB to
16KB
> but I can'
At 03:09 PM 8/30/2003 +0200, Thies C. Arntzen wrote:
you are likely to have a buggy version of libXml, that
causes this when xmlCleanupParser is called more than once.
this happens if two php-modules use libXml and call
xmlCleanupParser in the [R|M]SHUTDOWN
Ouch. Now the question i
On Sat, Aug 30, 2003 at 04:05:42PM +0300, Andi Gutmans wrote:
> Hi,
>
> I've been debugging a problem with my memory manager for quite a while (I
> was playing with different block sizes) when I discovered there doesn't
> seem to be a bug but the heap gets corrupted by some other place in PHP. I
Hi,
I've been debugging a problem with my memory manager for quite a while (I
was playing with different block sizes) when I discovered there doesn't
seem to be a bug but the heap gets corrupted by some other place in PHP. It
just happens that the memory manager makes this problem appear sooner
* Thus wrote Sara Golemon ([EMAIL PROTECTED]):
> > Can this not be done easily with array_walk?
> >
> Yes, though the primary purpose here is to have a method to create a
> form-encoded query string internally, exporting it to userspace is just a
> "why the heck not" side-effect.
Ahh.. ok.
>
> >
41 matches
Mail list logo
