Assigning lists a type

ID:169605
 
May 26 2005, 2:14 pm
One of the largely annoying things about dealing with lists in BYOND is that to work with an item in a list you need to assign it to a temorary reference. This makes code involving lists messier than neccessary. It would be nice to be able to assign a type to the list and allow you to directly use variables and call procs without the need of a temporary reference. For example

var/obj/objList[]
obj/var/a

proc/HalfTotal()
  . = 0
  for(var/i = 0; i < objList.len>>1 ; i++)
    . += objList[i].a


Currently you'd need to create an object reference and assign it to the object within the list at the specified index then on another line get the value from the reference. While in this case it doesn't save much but in a more complex data structure with nested objects with lists this would be a real life saver. The best part is not much needs to be added to support this syntax since you can already define a list with a type path like I did above but I think currently it is just ignored.

Would also be nice is a similiar thing could be done with proc return values though this would probably require a larger overhaul.
May 26 2005, 4:27 pm
Theodis wrote:
One of the largely annoying things about dealing with lists in BYOND is that to work with an item in a list you need to assign it to a temorary reference. This makes code involving lists messier than neccessary. It would be nice to be able to assign a type to the list and allow you to directly use variables and call procs without the need of a temporary reference.
...
Currently you'd need to create an object reference and assign it to the object within the list at the specified index then on another line get the value from the reference. While in this case it doesn't save much but in a more complex data structure with nested objects with lists this would be a real life saver. The best part is not much needs to be added to support this syntax since you can already define a list with a type path like I did above but I think currently it is just ignored.

Actually quite a bit would need to be changed. The type path is for the list itself, but does not apply to the items inside. It'd still be important to define the list as a /list, too, because of the need to access list procs and vars. What you're asking is basically an equivalent of a template array class in C++, which isn't even really as easy as C++ makes it out to be.

Chalk the list thing up to the difference between lists and true arrays. Ultimately they're not the same thing, and will never be. A true array has a type, but in list languages (which are invariably loosely typed like BYOND), any item at all may be added to a list. To try to force a list to be typed is basically to try to totally redefine the language to use arrays instead of lists.

Would also be nice is a similiar thing could be done with proc return values though this would probably require a larger overhaul.

They'd both require overhauls. I suspect however that setting a return type for a proc would be easier by several orders of magnitude. Syntax and most other aspects would be nothing compared to typing a list. The list thing is basically impossible in almost any language that uses them, due to severely conflicting design.

However, both would break a lot of existing code, as the : operator is used for both proc/var access and the ternary ?: operator. (It's also used for paths!) When the : operator is encountered following a closing bracket or parenthesis, BYOND knows it will not be used for proc/var access, and treats it automatically as something different. The only way to avoid this would be to disallow use of the : operator in those scenarios, and only allow the . operator instead. Granted there's something to be said for that.

Lummox JR
May 26 2005, 5:21 pm
In response to Lummox JR
Chalk the list thing up to the difference between lists and true arrays. Ultimately they're not the same thing, and will never be. A true array has a type, but in list languages (which are invariably loosely typed like BYOND), any item at all may be added to a list. To try to force a list to be typed is basically to try to totally redefine the language to use arrays instead of lists.

You wouldn't be forcing them to anything. It is just for compile time syntax checks much like this

turf/Entered(mob/m)
  if(istype(m))
    m << "You entered [src]!"


The parameter is in no way restricted to being a mob. The type definition is mearly for compile time checks. For the list it could be the same where you could access properies directly as if the item where of the defined type and it would cause a runtime error in the same way if the stored item didn't have the property or proc.

They'd both require overhauls. I suspect however that setting a return type for a proc would be easier by several orders of magnitude. Syntax and most other aspects would be nothing compared to typing a list. The list thing is basically impossible in almost any language that uses them, due to severely conflicting design.

Though in some languages that I've used allow you to typecast an item and access the properties without any temorary reference which is essentially what the type path defined for the list would do each time you access a list item's property or proc.

However, both would break a lot of existing code, as the : operator is used for both proc/var access and the ternary ?: operator. (It's also used for paths!) When the : operator is encountered following a closing bracket or parenthesis, BYOND knows it will not be used for proc/var access, and treats it automatically as something different. The only way to avoid this would be to disallow use of the : operator in those scenarios, and only allow the . operator instead. Granted there's something to be said for that.

Yeah I can see the problem with the colon operator being a problem. Though like in C++ with nested templates you can just require a space to differentiate the two operators. The ? operator with a following list element doesn't come up too much so I doubt it would break too much. There have been changes that have caused larger breakages in the past like changes to file IO and to whole indentation thing.

Besides it looks cleaner when you put spaces inbetween the operands of binary and ternary operators anyway :).