Suggestion - Structures

ID:135029
 
May 11 2005, 6:20 pm
I suggest there be a second root prototype, 'struct'. These 'struct'ures can have variables, and procedures, pretty much everything /datum has, except for Topic(). They can not be referenced to. However, since there's no reference, they cannot be used as output paramiters in procedures, nor be shared between two datums. When a variable is assigned to a /struct, it creates a copy of itself. As for variables that point to datums, (such as /list) it copies to reference to that datum, rather than the a clone of the datum.

struct/test
  var
    val1 = 0
    list/val2 = list(3, "heh", new/obj)

proc/Test()
  var/struct/test
    myStruct1 = new
    myStruct2 = myStruct1
  myStruct1.val1 = 1
   // Now (myStruct1.val1 == 1)
   // And (myStruct2.val1 == 0)
  myStruct1.val2.Add(null)
   // Now (myStruct1.val2 == list(3, "heh", a /obj, null))
   // And (myStruct1.val2 == myStruct2.val2)
  myStruct2.val2 = list()
   // Now (myStruct1.val2 == list(3, "heh", a /obj, null))
   // And (myStruct2.val2 == list())


As mentioned, the greatest advantage to these is the fact that they cannot be referenced, so you can use a virtually unlimited number of them at once.
May 11 2005, 6:58 pm
I fail to see how an inability to reference them would be a benefit, let alone compatible with BYOND. For every aspect of this a datum is better. None of this really makes any sense.

Lummox JR
May 11 2005, 9:49 pm
In response to Lummox JR
I fail to see how an inability to reference them would be a benefit, let alone compatible with BYOND. For every aspect of this a datum is better. None of this really makes any sense.


Occasionally you want a few associated variables without having to go through the overhead of creating and cleaning up a full blown datum. Currently for my Explosions2 library I just push raw positional data for the node locations to the stack. Would work a lot cleaner if I could use something like a struct where no more initialization or cleanup is done over that of a standard var.
May 12 2005, 9:45 am
In response to Lummox JR
Lummox JR wrote:
I fail to see how an inability to reference them would be a benefit, let alone compatible with BYOND. For every aspect of this a datum is better. None of this really makes any sense.

Lummox JR

As I said at the footer, there's virtually no limit to the number of these you can create at once. Datums, however, have a limit, thanks to the ability to reference to them.
May 12 2005, 12:26 pm
In response to Yota
Yota wrote:
Lummox JR wrote:
I fail to see how an inability to reference them would be a benefit, let alone compatible with BYOND. For every aspect of this a datum is better. None of this really makes any sense.

As I said at the footer, there's virtually no limit to the number of these you can create at once. Datums, however, have a limit, thanks to the ability to reference to them.

But not referencing the structures is incompatible with the entire way BYOND runs. Plus, you're quite wrong about having no limit. Structures still take up memory and hold a specific position therein. BYOND would still need to reference them to allocate them properly, and to handle garbage collection. The only way you could get away with having no reference is if your structure was less than 4 bytes in size. Even then you'd need to somehow keep track of its type. Like I said, there's no sense to this.

Lummox JR
May 12 2005, 12:28 pm
In response to Theodis
Theodis wrote:
Occasionally you want a few associated variables without having to go through the overhead of creating and cleaning up a full blown datum. Currently for my Explosions2 library I just push raw positional data for the node locations to the stack. Would work a lot cleaner if I could use something like a struct where no more initialization or cleanup is done over that of a standard var.

Aye, that'd be nice, but I don't see any way it's possible in BYOND. As it is a datum is basically the closest to a struct you can get in a loosely typed, garbage-collected language. As it is, it'd still be necessary to reference the struct for use, so I don't get what Yota's on about.

Lummox JR
May 12 2005, 3:22 pm
In response to Lummox JR
I agree, Datums are all you'll ever really *NEED*.

Personally, I'd like to see the limits of objects pushed a bit in the future, or at least totally abolished and dependent on how much system memory you have... But that's just me.
May 12 2005, 7:25 pm
In response to Lummox JR
Woah, I didn't mean to remove the internal references, just the references at DM level. For example, I see that daums have thier limit because their references are such: "[0xXXXXXXXX]". What I ment is that the structures are not bound to THESE.

These structures mimic thoes in the low-end languages, as the variable stores a pointer to thier location in memory, where when it comes to classes, it stores a pointer to thier reference.
May 13 2005, 2:42 am
In response to Yota
Yota wrote:
Woah, I didn't mean to remove the internal references, just the references at DM level. For example, I see that daums have thier limit because their references are such: "[0xXXXXXXXX]". What I ment is that the structures are not bound to THESE.

These structures mimic thoes in the low-end languages, as the variable stores a pointer to thier location in memory, where when it comes to classes, it stores a pointer to thier reference.

A far simpler solution would be to expand the number of bytes used for reference numbers. As you noted, most datum types only use 2 bytes (4 hex digits) of the reference string which is the reason for the 65536 limit. If we expand it to use 3 bytes (6 hex digits), then we could have over 16 million of each datum type; which should be more than enough for most programs. We really can't push it any further than that with the existing reference structure, since the most significant byte is used to identify the datum type.
May 13 2005, 8:03 am
In response to Shadowdarke
Shadowdarke wrote:
A far simpler solution would be to expand the number of bytes used for reference numbers. As you noted, most datum types only use 2 bytes (4 hex digits) of the reference string which is the reason for the 65536 limit. If we expand it to use 3 bytes (6 hex digits), then we could have over 16 million of each datum type; which should be more than enough for most programs. We really can't push it any further than that with the existing reference structure, since the most significant byte is used to identify the datum type.

16,777,216 should be enough.

These are what I've found..
Atom     01 00 XXXX (Including /turf.)
MovAtom  02 00 XXXX (Including /obj.)
Mob      03 00 XXXX
Area     04 00 XXXX
Client   05 00 XXXX
Image    0D 00 XXXX
World    0E 00 XXXX
List     0F 00 XXXX
Datum    21 00 XXXX (Including /icon, /sound.)
Savefile 23 00 XXXX

And you're right, I've never noticed that byte used.

So I'd be happy with either one of these approches, although the no-reference concept does have a few uses. Who knows, they could both be done.

<small>Durring my tests, I attempted using 'world << "\ref[global]"' just for fun, and it didn't even raise a compile error. When I ran the line, I recieved a 'Cannot read null.Del' run-time error. Garbage collector?</small>
May 13 2005, 6:26 pm
In response to Yota
Yota wrote:
Woah, I didn't mean to remove the internal references, just the references at DM level. For example, I see that daums have thier limit because their references are such: "[0xXXXXXXXX]". What I ment is that the structures are not bound to THESE.

I don't think you're getting this; there is no way to remove the references at the DM level. The internal reference is the exact same thing.

As for the 64K limit, that's a separate issue. The problem with expanding these limits is that many parts of the BYOND code use the raw datatype instead of the better, more specific DM___ID datatypes. Finding and fixing all those mistypings--and potentially splitting some service routines into 2-byte and 3+-byte versions--would be a nightmare.

These structures mimic thoes in the low-end languages, as the variable stores a pointer to thier location in memory, where when it comes to classes, it stores a pointer to thier reference.

Thing is, that's not even possible because DM is not a low-level language.

Lummox JR