Calling from a list.

Page: 1 2 3 4
ID:1313313
 
Jul 3 2013, 11:41 pm (Edited on Jun 30 2014, 2:35 pm)
Resolved
Proc calls and list reads can now be used in conjunction with the . or : operators. Since procs do not have such a thing as a return types and there is no such thing as a typed list, . and : behave identically in these cases.
Applies to:DM Language
Status: Resolved (512.1386)
This issue has been resolved.
The ability to call a proc directly from a object from within a list.

var/list/List = list(new/obj/Test)

obj/Test
    proc/Check()
        return TRUE

proc
    Testing()
        if(List[1]:Check())
            world<<"This works!"
Jul 4 2013, 12:17 am
 
client/verb/test()
    var/list/L = new
    var/obj/o = new
    L += o
    if(call(L[1], /obj/proc/some_proc)())
        world << "another message"

obj
    proc
        some_proc()
            world << "some message"
            return 1

You already can?
Jul 4 2013, 12:23 am
In response to Neimo
Neimo wrote:
client/verb/test()
>   var/list/L = new
>   var/obj/o = new
>   L += o
>   if(call(L[1], /obj/proc/some_proc)())
>       world << "another message"
>
> obj
>   proc
>       some_proc()
>           world << "some message"
>           return 1

You already can?

Without having to use call :p if I wanted to do that I would.
Jul 4 2013, 7:10 am
 
for(var/obj/Test in List)
     if(Test && Test.Check())
          world << "This works!"


or

var/obj/Test/listobj = List[1]
if(listobj && listobj.Check())
     world << "This works!"
Jul 4 2013, 8:38 am (Edited on Jun 30 2014, 9:02 pm)
or
if(L[1]:Check())
Jul 4 2013, 8:54 am
You'd never be able to do this with the . - the strict deference operator.
You'd have to use : - the lax dereference operator.
Jul 4 2013, 9:09 am
In response to Super Saiyan X
Super Saiyan X wrote:
You'd never be able to do this with the . - the strict deference operator.
You'd have to use : - the lax dereference operator.

Oops seemed to overlook that.
Jun 28 2014, 4:52 pm
Stephen001 resolved issue (Redundant)
Jun 28 2014, 4:54 pm
Any information on why it's considered redundant?
Jun 28 2014, 4:59 pm
Because : or a type cast into a variable permits the same thing, without muddying the language semantics further.

. operator is specifically a direct reference operation, it uses the type information on the given variable at compile-time to enforce if a given reference is okay to make. The list presents no compile-time information on it's contents, so there's no guarantee the compiler can make, AKA the operation makes no sense.
Jun 28 2014, 7:23 pm
just an FYI, Stephen, the : operator doesn't work with this, even though it seems like it should. It outputs a syntax error - error: :: expected end of statement, upon compile. I think that's enough to make this not redundant, as it currently doesn't work as expected.
Jun 28 2014, 8:13 pm
The typecast scenario however, does work.
Jun 30 2014, 2:27 pm
I don't think allowing somelist[1]:someproc() as valid syntax is a good idea. It's strictly better in all cases to enforce type casting.
Jun 30 2014, 2:31 pm
In response to MisterPerson
MisterPerson wrote:
I don't think allowing somelist[1]:someproc() as valid syntax is a good idea. It's strictly better in all cases to enforce type casting.

Sure, type casting is always the best course of action, but the colon operator exists for that very reason. The thing is that it /is/ a valid syntax, in cases where it's not a list element. If it's just a variable, it's perfectly fine. You don't need to typecast to make this work. You just need to create a variable pointing to the list element.

What is being asked for: make the colon operator work as expected with all potential pointers to objects, as that's the entire point of the colon operator.
Jun 30 2014, 8:30 pm
In response to Super Saiyan X
Super Saiyan X wrote:
MisterPerson wrote:
I don't think allowing somelist[1]:someproc() as valid syntax is a good idea. It's strictly better in all cases to enforce type casting.

Sure, type casting is always the best course of action, but the colon operator exists for that very reason. The thing is that it /is/ a valid syntax, in cases where it's not a list element. If it's just a variable, it's perfectly fine. You don't need to typecast to make this work. You just need to create a variable pointing to the list element.

What is being asked for: make the colon operator work as expected with all potential pointers to objects, as that's the entire point of the colon operator.

I agree, we are experiencing an issue where the : does not operate as expected within the functionality specification of the language. If anything, it's a bug that it isn't working as designed, as you yourself just said Stephen.
Jun 30 2014, 9:28 pm
What is being asked for: make the colon operator work as expected with all potential pointers to objects, as that's the entire point of the colon operator.

I wholeheartedly agree. It doesn't make sense that BYOND's members are differentiated between variables and procs and verbs.

Fact of the matter is that nearly every other language doesn't differentiate these things on a functional level. Members are members, and accesses are accesses.

() is an operator, and : is an operator. Why should they both not work in tandem?

Not only that, but the way BYOND's VM is optimized (read: very little at best, not at all at worst), casting is kind of a big deal in performance terms when you really start to look at it.

Now, you might look at Call() as being an alternative too, but without casting the type into a datum first, you will get a safety check because it assumes that you are running DLL functions.

Redundant is the wrong call here, because neither typecasting nor Call() are the same thing as expanding ":" to methods.
Jun 30 2014, 10:03 pm
Another issue that I think could be resolved is that the default return variable (.) is not compatible with the runtime search operator (:).

There are cases where you might want to set a proc's default return var to an object, before accessing its variables or procedures, but attempting to do something like:
. = new /mob/enemy
.:desc = "Very Dangerous!"

currently just confuses the compiler.
Jun 30 2014, 10:49 pm
Well, marking status works a little better if OP doesn't edit the topic after I've marked the status in question.

I'll shift this over to bug reports, but I have a feeling that due to the error being spat out, that it's a lexer/compiler faux pas, and possibly not the more straight-forward to fix.
Jun 30 2014, 10:49 pm
Stephen001 changed status to 'Open'
Jun 30 2014, 10:53 pm
In response to Stephen001
Stephen001 wrote:
Well, marking status works a little better if OP doesn't edit the topic after I've marked the status in question.


Page: 1 2 3 4