XYplorer Beta Club

admin wrote:Yes, this is bad. Any ideas?

If you would add ++$i, I'd change all my scripts

OK: it's a hard decision for you. As this would be the correct usage, I'd really change my scripts - though it's a bit of work to do. And these scripts would not be compatible with old XY-versions.

But what do others say? Or is $i++ as part of an equation, or an operand for a called function, (i.e. not stand-alone) only rarely used? (I used these both, and stand-alone...)
But I think the number of scripts is limited for everybody - and you can search for "++". Change really would be easyest if you just could change $i++ to ++$i, else you have to change start-values, limits, etc.

(I'm now off for some hours.)

edit: typo

PeterH wrote:But what do others say?

Indeed, deprecating a language's syntax w/o generating any troubles is tough stuff.

Hmm, let's summarize what we have
- a user who submitted a bug or hint to some remaining inconsistency
- a language owner who hates signs of imperfection or inconsistency more than (almost) anything else
- more users who share the opinion of the bug submitter - and belong to the crowd of major script suppliers

To me it's clear: improve the syntax - every single following "uarggggg, wtf" will be cared for quite fast here.

@Don: I guess you don't want the SC engine to support different syntax versions at all, right?


Cheers,
Filehero

Filehero wrote:@Don: I guess you don't want the SC engine to support different syntax versions at all, right?

That would be a nightmare.

Given that XY scripting syntax closely follows PHP syntax ever since, the old behavior could be seen as a bug. So this is a bug fix. And by all means it should be done.

Thanks the Qwerty for the explanations, as both you and Don stated it all has to do with "variables first incremented and then returned" vs "returned and then incremented".

Just tested with the "expanded dereference operator". (v14.30.0001)

Great!!! :-)

Code looks much better this way. Though I will wait a bit before change real life
Some (rather unrelated) examples "before": And the same "after":It's better to write, and better to read, I think.
So thanks a lot, and


With the new $i++ I will wait a bit, as code will become backword incompatible.

I think I've only used the increment operator on a line by itself so changing it isn't a big problem for me - even leaving it broken is okay with me just inconsistent with my experience.

That said I'm curious if this is actually in-line with PHP as I would have thought the incrementing was done after the echo statement, though what that means for echo $a++ + $a++ I'm not entirely sure

TheQwerty wrote:I think I've only used the increment operator on a line by itself so changing it isn't a big problem for me - even leaving it broken is okay with me just inconsistent with my experience.

That said I'm curious if this is actually in-line with PHP as I would have thought the incrementing was done after the echo statement, though what that means for echo $a++ + $a++ I'm not entirely sure

Code: Select all

$a = 1; echo $a++ + 1; echo $a; //2; 2
      Note in the following that the left operand is incremented before the 
      right operand is added. Finally, after the addition, the right operand is 
      incremented:
        $a = 1; echo $a++ + $a++; echo $a; //3; 3 

I tested it with PHP. Yes, it's the same over there.

admin wrote:I tested it with PHP. Yes, it's the same over there.

Figured you would have checked it but wanted to make sure. Turns out it's the same in C#, so I've learned something new today.

And with that knowledge I intend to continue my trend of avoiding incrementing within expressions. This power is better used by itself.

Oh - is this a bug? Try:
$a = 1; echo " $a $a++ $a++ $a++ $a ";

Seems inside double quotes $a++ isn't recognized as a variable, so just taken as text.
I wouldn't expect this.

PeterH wrote:Oh - is this a bug? Try:
$a = 1; echo " $a $a++ $a++ $a++ $a ";

Seems inside double quotes $a++ isn't recognized as a variable, so just taken as text.
I wouldn't expect this.

I would.

PeterH wrote:Oh - is this a bug? Try:
$a = 1; echo " $a $a++ $a++ $a++ $a ";

Seems inside double quotes $a++ isn't recognized as a variable, so just taken as text.
I wouldn't expect this.

I would expect this to echo "1 1++ 1++ 1++ 1" just as I would expect $a = 1; echo "$a + 2"; to echo "1 + 2".

Though I'd have to re-read the acceptable characters for a variable name to determine what I'd expect from:
$a = 1; $a++ = 2; echo "$a $a++ $a++ $a++ $a"
EDIT: Though I'd hope this is actually an error with $a++ = 2 being invalid. /edit

And this is too much for a weekend...
$a = 1; *$a++ = 2; echo $a $a++ *$a *$a++;

admin wrote:I would.

With a good reason?

I must admit: had this idea just for visualization of multiple ++ in one "expression".

Edit: OK - you might see this like a kind of function - and functions inside quotes

Edit2: though TheQwerty seems correct: the variable $a should have been recognized, so 1++
Edit3: it shouldn't only: it really does Sorry I remembered wrong!

OK, conc. $i++: I decided to leave things as they are now (v14.30.0003). There is no other way to go. So scripts that use increments as an argument must be adjusted to the new way (FIRST assign current value, THEN increment).

Could it be that "copydata hwnd, data, mode" does not copy/send any data at all if data is an empty string? It seems my OnMessage-Reactor in my other proggi does not even react...

got an overflow 0 \ 0 error on loadtree with a long list of paths