New value for Caller() [and self()]

[PeterH]

I wish a new value for function(s) Caller() and Self() as it uses the same: 'label'

In the moment I use Caller('caption') to identify a script (in a scriptfile). But often this is rather long - so I would prefer to use the label.

If, for a script, only 1 of both values is specified, I think Caption and Label should return the same value.

OT here: should XY-internal functions generally allow keywords in mixed case? (I love to write keywords with a capital 1st letter for easy recognition, or even all upper.)
Just tested: Self() allows it. But the other day I had problems with Writefile(): mode='A' was not recognized, defaulted to 'o'! So I lost (test-)data (Without warning for illegal mode= )

[admin]

OK, added.

OT here: should XY-internal functions generally allow keywords in mixed case? (I love to write keywords with a capital 1st letter for easy recognition, or even all upper.)
Just tested: Self() allows it. But the other day I had problems with Writefile(): mode='A' was not recognized, defaulted to 'o'! So I lost (test-)data (Without warning for illegal mode= )

No general mixed case. Some functions already now use case-sensitive arguments.

Writefile: thanks for the hint. Next version will show an error.

[PeterH]

1) thanks a lot

To mixed case: one thing is if a typo (Upper/lower character) leads to an error. Especially if reported
But if these lead to different results, i.e. 'a' differs in function from 'A', typos are much more problematic. So for me: I don't like that
(Isn't it like unix?)

Example: my user functions often translate keywords to upper, for easy comparison. Bad if such an operand will be forwarded to an XY-internal function it's problematic. In the moment for the writefile-operand I translate all keywords to lower - but also bad, if upper and lower have different meanings.
Sure: for me the operand can have "local" meaning and must be compared, or it can be passed to writefile. So it's a bit complex to translate for local use, but not for passing.

[admin]

Agreed. I said "Some functions already now use case-sensitive arguments" and meant case is distinctive in arguments for some functions. However, I *think* I was wrong. At least I cannot find an example now.

I still don't want to make arguments case-insensitive.

If you find another case like writefile let me know.

[PeterH]

Also thought I once had seen an operand with different meaning for upper and lower case. And also don't find it...

Other examples I found:
For Attrstamp(attr=) you explicitely define "any case". (That's fine )
Sync(command=) also says case-insensitive.
Tab(Operation=) does not say it.
Trim(mode=) "insensitive".

Now I don't understand your intention, e.g.for the mentioned Writefile(): do you want to make it case insensitive, or do you want to show an error?

What I'd say: if a key-operand receives something that's not expected, an error should be shown.
If operands are case sensitive, then wrong case is unexpected => error message. ( )
(In both cases the script might be able to be continued "on user request" with default values. Or maybe case-translated values??)

[admin]

Now I don't understand your intention, e.g.for the mentioned Writefile(): do you want to make it case insensitive, or do you want to show an error?

show an error

IMO scripting is a power tool that needs to be employed with care. I cannot make it fool proof. It's not meant for fools.

The Writefile case was an exception: loss of data -- hey, that triggers the red alarm. I had to act right away.

[PeterH]

You don't need fools to produce scripting errors

If you want to say you will show errors only on situations that can lead to data loss I think you are wrong: you should do it for every recognized / recognizable error. To support fools and non-fools.

I also think that it doesn't make much sense to differentiate on case for keywords, especially for windows systems - it's just unusual there. But I think this is much less important.

[admin]

Agreed. That's why I said: If you find another case like writefile let me know.

[PeterH]

Agreed. That's why I said: If you find another case like writefile let me know.

Hm: is this comparable?
If a script calls User Functions that don't exist it works "without problem". That is: the calls are taken as strings and silently returned.

What happened? For debugging another error in preprocessing(!) I commented an include. The error turned out to be a missing single quote. After correcting the quote I forgot to re-enable the include. The script worked without showing any problem. But the result was lkgfvcnkj.
Debug showed that the calls to now unknown functions were taken as (unquoted) strings, handled literally...

So I'd expect a construct name( should always be seen as a function call, and if the function is unknown it's an error and should be reported.

For reporting: maybe, especially for users running scripts of other persons, it would be fine if script errors would be shown in an explicit "Error Dialog", with options like "Terminate(Default)", "Analyze(=Step)", "Contine(handle with care!)"

-----
On Topic
No time to test caller('label') till now

Edit: To stop I installed curr beta, and tried Try Script with:

Code: Select all

"Dieses Script : DS"
 echo self('Caption') . " : " . self('label');

Thanks a lot - that will help me!

[admin]

So I'd expect a construct name( should always be seen as a function call, and if the function is unknown it's an error and should be reported.

Convinced. Coming...

[PeterH]

Just came home, saw this, and saw the beta

In my eyes: big step in - ah - name it reliability or so.

For me:

And On Topic again (though I think "of topic" in this thread was very use-/helpful)
Will code a bit in the function for which I wished Caller('label')

[bdeshi]

topic: undefined functions
your enhancement is too aggressive

Code: Select all

  if !abs(0) {echo n;} else {echo y};
  if !abs(1) {echo n;} else {echo y};
  if !(abs(0)) {echo n;} else {echo y};
  if !(abs(1)) {echo n;} else {echo y};

All like this worked earlier. You might say !function() is not recommended, but there's no excuse for breaking !(function())


ed.

[PeterH]

Sammay, you're right!

If (!IsSet($_DB_sn0)) {...
"Call to undefined function isset"

[bdeshi]

back to primary topic:
let self() return function name and namespace when called within a function: self('name'); self('namespace');
self('caption') returns 'function functionname' *. self('name') will return just 'functionname'


ed. * that was a nice surprise,

[admin]

topic: undefined functions
your enhancement is too aggressive

Code: Select all

  if !abs(0) {echo n;} else {echo y};
  if !abs(1) {echo n;} else {echo y};
  if !(abs(0)) {echo n;} else {echo y};
  if !(abs(1)) {echo n;} else {echo y};

All like this worked earlier. You might say !function() is not recommended, but there's no excuse for breaking !(function())


ed.

Yo, , thanks!. Coming...