Defining list or savefile procs

ID:132967
 
Jul 14 2009, 6:40 pm
A quick forum search gave me no results about this previously being suggested, so my basic suggestion is this:
list/proc/MyProc(arg1,arg2,etc)
    //code runs through here
    return
//---
var/list/MyList=new
MyList.MyProc(1,2,3)
//Or at least
datum/proc/DatumProc(arg1,arg2,etc)
    var/list/Src=src
    if(!istype(Src)){return}
    //code runs through here
    return
//---
var/list/MyList=new
MyList.DatumProc(1,2,3)

Being able to define procs under the list or savefile type instead of having procs where their first argument is a list or a savefile. We can already define procs on nearly any other type. Why not lists and savefiles too?
If not being able to define the type under savefiles or lists, we should at least be able to define a datum proc that can be called on a list. What I mean is that you should finally do what is noted in the help file and make savefiles or lists derived from /datum so that we can call a datum proc on a list.

Before anyone replies, I know you can do this:
proc/MyProc(list/L,arg1,arg2,etc)
    //code runs through here
    return

If you're just going to talk about how this can already be done by making the first argument of a proc a list, then please don't reply. I already know this. The staff knows this. It's up to the staff whether or not they implement my suggestion in the future. I know it's not high-priority and I'm not asking for anything now. It's just a suggestion.
Jul 14 2009, 7:38 pm
Naokohiro wrote:
Being able to define procs under the list or savefile type instead of having procs where their first argument is a list or a savefile. We can already define procs on nearly any other type. Why not lists and savefiles too?

I like this idea quite a lot. I'm not sure how difficult it would be but I'd like to be able to do it.

Is this concept plausible? If so... Win! :D
Jul 14 2009, 10:10 pm
Naokohiro wrote:
A quick forum search gave me no results about this previously being suggested

Hmm, I find it difficult to believe it hasn't. o_O I'd think the Staff has considered it in the past, though that was probably the far past.

We can already define procs on nearly any other type. Why not lists and savefiles too?

Lists and savefiles are after all very special objects handled entirely internally by DM, so it's no surprise there. We've never actually had any such control over them (as far as OOP goes) and the ability to declare procs on them wouldn't make such a difference as it does for objects you can actually control, modify, and derive your own subtypes from. Adding the ability to do that with those types would be non-trivial, I'd imagine - those types are probably non user-modifiable in their design.

If not being able to define the type under savefiles or lists, we should at least be able to define a datum proc that can be called on a list. What I mean is that you should finally do what is noted in the help file and make savefiles or lists derived from /datum so that we can call a datum proc on a list.

Dunno if that's ultimately a good idea or not, though. Declaring on /list itself is indeed preferred: lists are very often used and making them derived from /datum may add overhead when they're used, and not much else (even if we might be able to do things like override list/New(), it wouldn't add much new usefulness, though it would be interesting). Also, would this make lists or savefiles initialized take space in the datum limit? Anyway, I think the distinction between /datum and very special types like /world, /list, /savefile isn't actually bad.
Jul 15 2009, 5:57 am
So you want them to write entirely new systems so you can save on writing 1 line (or less) of code?
Jul 15 2009, 6:57 am
In response to Falacy
It may not take "writing entirely new systems", who is to say other than the BYOND Staff? Also, it's not about saving a line of code (I don't even see which line you'd supposedly saved), but having your procedures defined on the object itself, so they can't actually run without an object and are automatically stopped if that object is deleted.
Jul 15 2009, 7:05 am
In response to Kaioken
Kaioken wrote:
It may not take "writing entirely new systems", who is to say other than the BYOND Staff?

I say =P


Also, it's not about saving a line of code (I don't even see which line you'd supposedly saved),

As he said in the first post: "...instead of having procs where their first argument is a list or a savefile."


but having your procedures defined on the object itself, so they can't actually run without an object and are automatically stopped if that object is deleted.

How would a list be deleted? And this can pretty much already be accomplished now by using datums... You'd just have to do something like:
datum/ListDatum
 var/list/List=list()
 proc/AddStuff(stuff)
    src.List+=stuff

mob/var/datum/ListDatum/Skills=new()

Player.Skills.List+=whatever // for direct access, or
Player.Skills.AddStuff(whatever) // to run a proc on the list

If anything though, I think that would cause even more problems if "deleted"... Cannot access null.AddStuff!
Jul 15 2009, 8:00 am (Edited on Jul 15 2009, 8:26 am)
In response to Falacy
Falacy wrote:
I say =P

Yes, which is why that was quite meaningless, especially since you just threw an exaggerated statement off.

As he said in the first post: "...instead of having procs where their first argument is a list or a savefile."

Yep, again, I don't see how you're saving any line here. Maybe you mean a few characters to declare an argument, but that's not the point here, as mentioned.

How would a list be deleted?

Silly question - silly, obvious answer: like any other object. Which, if you don't know, is by losing all references to it (and then in turn being garbage collected) or having del explicitly used on.

And this can pretty much already be accomplished now by using datums...

Not exactly, nor does it matter. As the OP said himself, this request is low priority and by nature doesn't enable anything groundbreaking that wasn't possible one way or another before. This makes it doubtful that it'll be done anytime soon if it's not trivial to do, though.

datum/ListDatum


FYI, new datums are defined by just putting the object definition on the topmost/leftmost indentation level (meaning under nothing). This means the code above actually creates 2 datums; one 'datum' (which probably isn't usable, because of the built-in ancestor type with the same name) and one derived from it, with path /datum/ListDatum, haha. >_>
You only put stuff under '/datum' if you're adding properties to all datums (== under the base ancestor), not new datums/subtypes.

EDIT: Ah, where's your reply gone? ;P

Falacy babbled:
That's like saying you don't define mobs as datum/atom/movable/mob/Whatever. Sure that's a little extra work, but its not creating imaginary parent/subtypes.

Let me explain to you type paths work. There is only one path that can refer to a specific object type, and the path isn't necessarily influenced by what the object is derived from. That's why the path to /mob is just that, /mob. You define new mob subtypes by putting them under the /mob node. Datums however are special and are defined by putting them on no node at all, not under /datum.

Meaning, of course it's not creating any imaginary types, it's creating actual ones. You can't refer to a specific type by using an imaginary node - /datum/atom/movable/mob illustrates what mobs inherit from, but it is not a type that exists (and you can't use it to refer to mobs) [therefore a new one is created]. Only /mob does.
Jul 15 2009, 8:40 am (Edited on Jul 15 2009, 8:47 am)
In response to Kaioken
OK since I'm getting tired of deleting and re-posting things I'm just gonna say this:
I tend to do what works, BYOND has few competent resources for learning from, and even less (if any) conformity standards, so pretty much anything goes. Unless there's some negative effect on efficiency; I don't have a problem with it. If nothing else, datum/DatumTypes keeps them all nicely grouped in the Object tree. And since mob/mob/MobType wouldn't create any problems, I don't see why datum/datum/DatumType would. And due to this topic, and looking into paths just now, I'd have to say they make little-to-no sense. A mob is technically a datum/atom/movable/mob, but you can't access it that way?
Jul 15 2009, 8:49 am
In response to Falacy
Falacy wrote:
And since mob/mob/MobType wouldn't create any problems, I don't see why datum/datum/DatumType would.

Neither creates problems, they just create 2 object types when only one is wanted.

And due to this topic, and looking into paths just now, I'd have to say they make little-to-no sense. A mob is technically a datum/atom/movable/mob, but you can't access it that way? Genius design.

Don't forget types and paths are kinda separate. Using parent_type, you can make an obj that is under the /mob node, and access it using a /mob path: 
mob
   my_ball
      parent_type = /obj
obj/verb/Kick()
   ...

proc/Kick_a_ball()
   var/mob/my_ball/O = new
   O.Kick() //my_ball actually inherits from /obj, so it can be kicked

The built-in types like /mob are no different, in psuedo-DM syntax, the built-in object tree definition would look like this 
datum
atom
   parent_type = /datum
   movable
mob
   parent_type = /atom/movable


Lastly, a type path is the identifier of a specific object type. Being that, you could only refer to an object type by its one identifier. Think about a person having multiple ID numbers - that's a similar situation to /mob being identified by multiple paths such as /mob, /atom/movable/mob and /datum/atom/movable/mob.