can @extended be a string?

[orbs]

is it possible to set @extended to return a string (or any other data type, for that matter)?

currently i'm using a ByRef to return an "extended" string value, but using the native @extended will make it much more convenient.

[JohnOne]

It is quite trivial to test.

[czardas]

NOPE!

[orbs]

It is quite trivial to test.

and test it i did; however since the results suggest only a "no" as an answer, i thought it worth asking in case i miss some configuration that need to be changed. 

 

NOPE!

thanks for the straightforwardness!

[czardas]

It appears to be an internal conversion from string to integer. So if your string is "21" then you will get 21, but if it is a word, then the conversion produces 0. The extended value was never intended to be used with strings.

Edited August 10, 2014 by czardas

[guinness]

There is a trac request for this to happen, as some native functions fo return a string.

[czardas]

I don't really see a reason to return a string if a number suffices. Other than having to reference the meaning of an extended value, there is no further inconvenience. There are many possible ways to create multiple return values. For consistancy, perhaps error values ought to have the same functionality as extended values - as is the case right now. Integers certainly suffice, but it's obviously not up to me.

Edited August 10, 2014 by czardas

[water]

The ticket Guinness is talking about is #2793.

[czardas]

Thanks water, I added a comment.

[jchd]

Since at least one built-in function is using the ability to place a string in @extended I'd say it should be a feature open to user code as well. And once @extended is allowed to hold Int32 and String variants why not raise the limitation and allow any datatype there?

Edited August 10, 2014 by jchd

[guinness]

I agree, though probably numbers and strings are suffice.

[czardas]

I don't see why numbers are not suffice. If a string extended value has been used, it signals another great overhaul. I am mostly concerned about consistancy and performance. Could the extended string return value not be made to fit with the overall consistancy which already exists? jchd has a point too, but it seems to me to be opening Pandora's box for no reason that I can imagine. You can already return an array with as much variety of data as you wish, modify variables ByRef etc... Please explain the advantage to me.

Edited August 10, 2014 by czardas

[jchd]

guinness,

Maybe, but why more code to check the datatype and create another error condition to check with a problematic treatment?

Func a()
    ; ... blah
    If $somecondition Then SetError(3, $something, 0)   ; how to easily report that $something is a forbidden datatype?
EndFunc

Of course it would be ugly to set @extended to some huge Map or even a significantly large array (assuming arrays could be allowed as well) but then is that really a problem? Everybody is free to misuse the language and code things that hurt common sense.

czardas,

It isn't opening a can of worms, just offering a simple possibility in legitimate cases where the feature makes sense. In fact, ability to return any variable could even make the core, SetError() and SetExtended() simpler for not having to convert what is passed to these functions to the domain @extended currently has its limited range.

[czardas]

czardas,

 

It isn't opening a can of worms, just offering a simple possibility in legitimate cases where the feature makes sense. In fact, ability to return any variable could even make the core, SetError() and SetExtended() simpler for not having to convert what is passed to these functions to the domain @extended currently has its limited range.

 

If it involves less internal checks then maybe it's less of a problem to modify - I suppose. It's certainly not an essential change. The question I have is: would it show any advantage over the multiple alternatives which are already part of the language? If so, then I consider it a good idea. If not, then I think it's a waste of time.

Edited August 10, 2014 by czardas

[jchd]

It can be pretty useful for not having to wrap [return, extended] in an array, then copy back return (at least) in another variable. Suppose Return is a large object: since we don't have references, you'd have to deep copy this large object twice for no good reason, just wasting cycles.

[JohnOne]

It's less user coding I suppose but beyond that I do not see much of a gain.

It's quite simple to emulate.
 

Global $Extended, $Error

_Func()

MsgBox(0,$Error,$Extended)

Func _Func()
    _SetError("hello", "World")
EndFunc

Func _SetError($err = "", $ext = "")
    $Error = $err
    $Extended = $ext
EndFunc

[jchd]

That means too many global variables of scarce use. I wouldn't recommend that in a medium-size project. Also I never said it's a gain, per se. It's just more flexibility at little cost (my guess) for limited use.

Thinking again at it and since ther is at least one function returning a string, my bet is that the core code is already processing a variant. If that's the case only SetError and SetExtended need raising their limit.

Edited August 10, 2014 by jchd

[JohnOne]

I tend to dissniss the "global variable" argument, it's 2 globals.

#include "Constants.au3" there's hundreds in there.

Edited August 10, 2014 by JohnOne

[guinness]

#include "Constants.au3" there's hundreds in there.

Not the same thing I'm afraid.

[JohnOne]

Exactly the same thing, A global variable is a global variable, it's a global variable in your script, nothing more and nothing less.