Index Objects in Feature Requests

ID:116016
 
Jul 17 2011, 7:26 am
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
It would be nice if we could specify that certain objects (other than lists) could be indexed. An 'Index(i)' proc could be defined on those types which the programmer wants to be indexable.

This would allow for more flexible use of 'lists' (since we could then define types which fully meet the list interface but which take operations when they're modified, e.g. a list representing the contents of a grid control could update that control when the list is modified in any way).
#1 Jul 17 2011, 10:29 am
Hazman:
This would allow for more flexible use of 'lists' (since we could then define types which fully meet the list interface but which take operations when they're modified, e.g. a list representing the contents of a grid control could update that control when the list is modified in any way).

I always wanted a way to add a child to lists and be able to override some of its procs :(.
#2 Jul 18 2011, 11:01 am
Originally I was thinking this wouldn't be very feasible, but looking in the code I actually see no significant reason it couldn't be done. To work it wouuld require two procs, one to get a val from an index and one to set it.
#3 Jul 20 2011, 7:55 pm
I'm having trouble understanding what an index object is. I do know what a list is, however :\
#4 Jul 20 2011, 8:38 pm
Kaiochao wrote:
I'm having trouble understanding what an index object is. I do know what a list is, however :\

An index is a position in the list. Used as a verb it pretty much means adding it to the list at a certain index (don't quote me on that...EVER).
#5 Jul 20 2011, 9:03 pm
So... setting an index to an object? I don't know, maybe a code example would help.
var L[5]
L[2] = "b"
L[4] = "d"
L[3] = "c"
L[1] = "a"
L[5] = "e"

// L == list("a","b","c","d","e")
#6 Jul 20 2011, 9:07 pm
Kaiochao wrote:
So... setting an index to an object? I don't know, maybe a code example would help.
> var L[5]
> L[2] = "b"
> L[4] = "d"
> L[3] = "c"
> L[1] = "a"
> L[5] = "e"
>
> // L == list("a","b","c","d","e")
That's indexing them yeah.
#7 Jul 21 2011, 12:38 am
Essentially it allows you to syntactically treat an object as a list. Many programming languages allow this in some form (C# and Java, C++ etc). To take advantage of it you specify two methods: how to get an indexed value, and how to set an indexed value. For example, supposing we want to create a list which is automatically sorted:

sorted_list
    var/backing_list = list()
    Index_Get(index)
        return backing_list[index]
    Index_Set(index ,value)
        backing_list[index] = value
        Sort()

    proc
        Sort() // some sorting algorithm
        Add()  //standard list procs
        Remove()
        Swap()
        //etc


Of course this could be done with just an object which you access via get() and set() procs. But such an object cannot be treated as a list and cannot be used in places where a list could be.
#8 Jul 21 2011, 5:26 am
Hazman wrote:
Essentially it allows you to syntactically treat an object as a list. Many programming languages allow this in some form (C# and Java, C++ etc). To take advantage of it you specify two methods: how to get an indexed value, and how to set an indexed value. For example, supposing we want to create a list which is automatically sorted:
> sorted_list
>     var/backing_list = list()
>     Index_Get(index)
>         return backing_list[index]
>     Index_Set(index ,value)
>         backing_list[index] = value
>         Sort()
>
>     proc
>         Sort() // some sorting algorithm
>         Add()  //standard list procs
>         Remove()
>         Swap()
>         //etc
>

Of course this could be done with just an object which you access via get() and set() procs. But such an object cannot be treated as a list and cannot be used in places where a list could be.

If it wasn't going to be treated as a list couldn't you just make the object yourself?
#9 Jul 21 2011, 3:10 pm
Yes but IMO it's important that the object be treatable exactly like a list and be usable in places where lists are used (e.g. list2params, for loops etc.). Not sure if this is as easy as Lummox's plan (since being able to index a variable doesn't imply that you can treat it as a list).
#10 Jul 21 2011, 4:09 pm
Being able to treat the object as a list in other routines is a much different proposition.
#11 Aug 2 2011, 11:19 am
Why not just make it so you can define an object with parent_type = /list?
Then, in procs of the object, you simply use the src var to access the list. e.g. src[i] = value, for(var/X in src), etc.
This might be too different from the original suggestion, though.
Yeah, now that I think of it, you would need to be able to override all of the list procs, in that case. (Copy, Cut, Add, Remove, etc.)
#12 Aug 2 2011, 2:30 pm
I understand why this is handy, but the ways you can currently implement this are almost as simple. Instead of saying "my_list[1]" you say "my_list.get(1)". Instead of saying "for(var/x in sorted)" you'd say "for(var/x in sorted.to_list())".

Hazman wrote:
Of course this could be done with just an object which you access via get() and set() procs. But such an object cannot be treated as a list and cannot be used in places where a list could be.

Built-in procs wouldn't support the types of lists you've defined, but I can't think of a situation where you'd want to do that. Chances are that the place where you're referencing this sorted list object is in code that you wrote, so you can make your code handle lists and sorted lists.