XYplorer Beta Club

Posted: **14 Sep 2010 23:25**

(I know I'm late, I hadn't updated in a little while

)

As a wish for the future, when you do something like this:

v9.40.0007 - 2010-08-10 20:37
    ! SC getinfo("SelectedItemsPathNames") and
      getinfo("SelectedItemsNames") returned a trailing delimiter after
      the last returned item. Fixed. Now delimiters are found only
      between the items.

It's not a but you fixed, you changed the behavior of a function. Completely different. No really, because delimiters are meant to be there each time, because they are delimiters and not separators(*). It's a whole different thing, and yes some values for getinfo (now just get) do use a delimiter, while others use a separator, and it might be a good idea/understandable that you want to make it all the same, consistency and whatnot.

(*) Okay, I know a delimiter is just a separator, I'm sure it could be argued that those mean the same or whatever. That's not the point so if someone was willing to quote the dictionary or something, please don't. I used delimiter and separator to mean different things here because it's quite simple to grasp, and that's how it was meant (I believe) in the Help as well, using delimiter for "after each element" and separator for "between elements."

Still:
- You did not fixed a bug, everything was working fine, as expected & documented. You changed the way a function works. Also, you should update the doc, those are not delimiters anymore, but separators. Or, no need to use different terms to (now) mean the same thing.
- When you do such an important change (and as we've seen, it is important) it should probably be written down elsewhere than just lost in the changelog, because I doubt I'm the only only who uses/used those things in scripts, and since you changed how that function works, you probably broke some (other) scripts out there. It is worth noting in big letters on the website or something, IMHO.

Posted: **15 Sep 2010 01:16**

jacky wrote:(*) Okay, I know a delimiter is just a separator, I'm sure it could be argued that those mean the same or whatever. That's not the point so if someone was willing to quote the dictionary or something, please don't. I used delimiter and separator to mean different things here because it's quite simple to grasp, and that's how it was meant (I believe) in the Help as well, using delimiter for "after each element" and separator for "between elements."

I agree especially to the very last part, saying delimiter and separator are not the same.

But the question: what should we expect here?
I'd really expect a separator! Even if documentation says "delimiter"

From this point of view the change was OK - and the documentation should be changed to match?

But that's just me - what do others think about that?

Posted: **15 Sep 2010 08:53**

PeterH wrote:
jacky wrote:(*) Okay, I know a delimiter is just a separator, I'm sure it could be argued that those mean the same or whatever. That's not the point so if someone was willing to quote the dictionary or something, please don't. I used delimiter and separator to mean different things here because it's quite simple to grasp, and that's how it was meant (I believe) in the Help as well, using delimiter for "after each element" and separator for "between elements."
I agree especially to the very last part, saying delimiter and separator are not the same.

But the question: what should we expect here?
I'd really expect a separator! Even if documentation says "delimiter"
From this point of view the change was OK - and the documentation should be changed to match?

But that's just me - what do others think about that?

Yes, I also agree about using "delimiter" and "separator" with a different meaning. And that "separator" here is the correct word.

OTOH, now all "get" sub-types using delimiters/separators work the same (namely the separator-way):
"tree"
"list_copyto"
"list_hilitefolder"
"selecteditemspathnames"
"selecteditemsnames"

So I think the fix/change was good (and from my POV it was definitely a bug because it was never intended like it was before the fix).

Posted: **15 Sep 2010 09:48**

admin wrote:So I think the fix/change was good (and from my POV it was definitely a bug because it was never intended like it was before the fix).

Well, here's why I disagree:

- you say it was never intended to work as it used to, yet that's how it worked and the documentation used delimiter for those, but separator for other cases, indicating that was - or could be seen as - the intent. And it was the way it worked.
- it's not a bug that made the value returned not right/formatted as expected on special circumstances, you changed the format of the returned value all the time
- you didn't change that because in a beta 2 days earlier you introduced those, and then realized separator was better than delimiter. You did change this:

Code: Select all

v7.60.0017 - 2008-09-19 09:09
    + Scripting got a new function.
      Note: The command getinfo is converted into a function! Since it was
      introduced after the last official release it's still considered
      BETA so there's no compatibility code. IOW: You have to upgrade your
      scripts if they use getinfo.
     
      Name: GetInfo
      Action: Get various info into variable.
      Syntax: getinfo(info, [param1])
        info:   [required] sort of info (New: *NOT* case-sensitive!)
        param1: [optional] depends on info
        return: retrieved info
      Possible values for info and param1:
      - "CountSelected", [(unused)]
        Count of selected items in List.
      - "SelectedItemsPathNames", [delimiter=CRLF]
        All selected items (full path) in List, delimited by param1.
      - "SelectedItemsNames", [delimiter=CRLF]
        All selected items (name, no path) in List, delimited by param1.
      Examples:
        ::$a=getinfo("CountSelected"); msg $a;
        ::$a=getinfo("SelectedItemsPathNames", "|"); msg $a;
        ::msg getinfo("selecteditemsnames", chr(10));

And actually, one could argue not even since that was based on this:

Code: Select all

v7.60.0005 - 2008-09-12 15:14
    + Scripting got a new command:
      - GetInfo
        Action: Get various info into variable.
        Syntax: getinfo output, info, [param1]
          output: [required] variable
          info:   [required] sort of info (case-sensitive)
          param1: [optional] depends on info
        Possible values for info and param1:
        - "CountSelected", [(unused)]
          Count of selected items in List.
        - "SelectedItemsPathNames", [delimiter=CRLF]
          All selected items (full path/name) in List, delimited by
          param1.
        Examples:
          ::getinfo $a, "CountSelected"; msg $a
          ::getinfo $a, "SelectedItemsPathNames", "|"; msg $a

So what you call "fixing a bug" is changing the way a SC works, the format returned, and that from 7.60.0005 (2008-09-12) to v9.40.0007 (2010-08-10). You really think in during those almost 2 years no one ever got used to that format, that it was intended (since documented as such), and that such a change doesn't fall under "minor bug fix" but something that outta be mentioned (since it will break things), at the very least on the help under the getinfo (get) function, and maybe on a separated scripting changelog that would list such major/important changes? Come on!

Again, I'm not against the change itself at all, but the way it was "done."

Posted: **15 Sep 2010 10:04**

I guess you're right.

I don't believe in communicating important things. In my experience it does not work. The better strategy would have been to add a new param (e.g. "SelectedItemsNames2") that behaves the new way.

Next time.

Posted: **15 Sep 2010 10:38**

I don't know, at one time when syntax changed, XY had a nice little popup to warn users. So there's a precedent of communicating important things (and at least to those/some to whom it matters, it means something).

Surely, it couldn't hurt to put it on the help file. I'm no expert, but I do a little PHP, and on the help page for a given function they list such changes. The help file, along with using "separator" instead of "delimiter," could have a note: from XY 9.40.0007 onwards <param1> is now used as a separator and not a delimiter.

Posted: **15 Sep 2010 10:44**

One thing: for my kind of "thinking" the change to "separator" was logical.

And the other: a change in syntax for scripting always is a problem. Sure it would be fine to have some compatibility. But: if this is payed by a more complicated (call it "strange") expression of the new version, like "SelectedItemsNames2", I don't know if that's good. In the moment it seems OK - but in 5 years? I don't know...

If I understand jacky correct: yes - it could be quite good to have a historical list of syntax changes for scripting, maybe best in helpfile. At least this could be a fast help what to look at, if a script starts showing problems.

XYplorer Beta Club

This was not a bug, and is important!

This was not a bug, and is important!

Re: This was not a bug, and is important!

Re: This was not a bug, and is important!

Re: This was not a bug, and is important!

Re: This was not a bug, and is important!

Re: This was not a bug, and is important!

Re: This was not a bug, and is important!