var L[] in Object tree as /list

ID:926627
 
Aug 12 2012, 10:00 am
Applies to:
Status: Open
Issue hasn't been assigned a status value.
Even though it's declared as a list with square brackets, you wouldn't be able to tell from looking at the object tree (show all nodes).
#1 Aug 12 2012, 12:04 pm
The compiler never actually knows L[] is a list at all, that's why you can't directly access the list procs with it, that's the whole reason for defining a list under /list.
#2 Aug 12 2012, 1:21 pm
But... You can. So it must.
#3 Aug 12 2012, 1:26 pm
You can use list procs when you just use L[]. This automatically typecasts it as a list object, apparently.

var/mylist[0]
mob/verb/test_list()
    mylist.Add("1","2")
    world << list2params(mylist)

It does work, so Nadrew...you're wrong about the compiler not knowing it's a list. Intuitively, it should appear on the Object Tree.
#4 Aug 12 2012, 1:30 pm
In response to Super Saiyan X (#3)
I've been using spaces to declare variables and square brackets for lists every since I discovered I could. I also use the "bounds" variable at compile-time to set bounding boxes.
#5 Aug 12 2012, 1:43 pm
Yeah...I never use bracket lists. nor the bounds variable, or spaces instead of slashes. Still, yeah, feature supported ++, the compiler DOES recognize them as lists, just they're not in the object tree.
#6 Aug 12 2012, 2:36 pm
The compiler is *very* loose about brackets. Take the following:

var/myList[0];
var/list/haha;
var/mob/hi[0];


myList is an untyped variable, haha is a /list, and hi is a /mob. What you would expect is:

myList is a /list, haha is a /list, hi gives a compile-time error (Cannot initialize a list here, or somesuch).

I think the better solution would be to remove the square brackets altogether, as they are really a language inconsistency. They are also a bit of an oddity, because in virtually any other language declaring an array with a specific size will not let you expand or shrink that array.

I actually expected the same to be the case here (That if you initialized a list with a fixed size, the size was immutable), but thats not the case after testing it.
#7 Aug 12 2012, 2:54 pm
In response to Alathon (#6)
myList is most definitely a /list variable. Typecasted, declared, initialized. The only problem here is that the object tree doesn't categorize lists as intuitively as possible in all cases.
#8 Aug 12 2012, 3:14 pm
In response to Kaiochao (#7)
Kaiochao wrote:
myList is most definitely a /list variable. Typecasted, declared, initialized. The only problem here is that the object tree doesn't categorize lists as intuitively as possible in all cases.

According to the Dream Maker IDE it is untyped. You know, the thing everyone in this thread is talking about.

The biggest problem here is a huge language inconsistency, for no gain. One that is most likely there as a legacy implementation from when there were no procedures attached to lists at all. And that causes 'interesting' things such as var/mob/hi[0] being a /list, but also being interpreted as a mob at the same time.

As an example, this will silently crash the procedure and not generate any compile-time / runtime errors or warnings:

var/mob/hi[0];
mob/verb/Test() {
    world << "[hi.name]";
}
#9 Aug 12 2012, 4:49 pm
I think the reason why brackets are still in is because of the fact you can directly access them through numbered indexes (depending on what kind of list they are of course). The ones that might show a few issues are associative lists when trying to use numbered index to access square brackets since they can utilize stringed names in square brackets.

Some of the libraries I'm working on utilize square brackets not to initalize, but rather to access the data (using a handy 'for' loop for such a situation) through numbered indexes.
#10 Aug 12 2012, 4:53 pm
In response to Bandock (#9)
Bandock wrote:
I think the reason why brackets are still in is because of the fact you can directly access them through numbered indexes (depending on what kind of list they are of course). The ones that might show a few issues are associative lists when trying to use numbered index to access square brackets since they can utilize stringed names in square brackets.
Some of the libraries I'm working on utilize square brackets not to initalize, but rather to access the data (using a handy 'for' loop for such a situation) through numbered indexes.

True. It still feels like half a solution though - In the current context, a list.Get(idx) proc seems more appropriate.
#11 Aug 12 2012, 5:14 pm
In response to Alathon (#10)
As well as list.Set(idx, value). But why do that when we can use brackets? I like it because it reminds me of JavaScript somewhat.

Also, I'd say that declaring a variable "var mob/L[]" without any kind of error is a bug not related to my issue.
#12 Aug 13 2012, 2:16 am
In response to Kaiochao (#11)
Kaiochao wrote:
Also, I'd say that declaring a variable "var mob/L[]" without any kind of error is a bug not related to my issue.

It is. It was more to point out that it seems to really have wacky elements surrounding suffix brackets.
#13 Aug 13 2012, 4:11 am
I remember Lummox saying something about lists being implemented fairly inconsistently through BYOND about three or four years ago. I've actually encountered some really weird list bugs particularly in the savefile access portions of the engine.