I personally feel static and dynamic arrays in types are both essential. I would be willing to wait 8 weeks. I would be willing to live with a normal release and then 8 weeks later get an update with dynamic types in UDTs.
Here's a story about how I'm using it:
I'm working on a GUI in a different language. The language supports dynamic arrays in types.
My code looks like this. Sorry for the line numbers:
40 Structure odd_gadgetProperties
41 title as string ;the title the gadget displays
42 ;togglable as integer ; whether it is a togglable gadget or not
43
44 inside_width as string ; used by scrollarea widget
45 inside_height as string ; used by scrollarea widget
46 scrollstep as string ; used by scrollarea widget
47
48 minimum as integer ;used by scrollbar
49 maximum as integer ;used by scrollbar
50 pagelength as integer ; used by scrollbar
51 vertical as integer ; used by scrollbar
52 EndStructure
53
54 Structure odd_gadget
55 gadgetId as integer ; id of gadget
56
57 extraData as integer ; extra data the gadget needs to carry
58
59 x as string
60 y as string
61 width as string
62 height as string
63
64 disabled as string
65
66 constant_name as string ; string name of gadget for use in events
67
68 typeOfGadget as integer ; the type of gadget that will be used
69
70 properties.odd_gadgetProperties ; the properties of the gadget
71
72 EndStructure
73
74 Structure odd_window
75 windowId as integer
76
77 title as string ;window title
78
79 constant_name as string ;name of the window for use in events
80
81 x as string
82 y as string
83 height as string
84 width as string
85
86 disabled as integer ;true/false active or inactive window
87
88 closeable as integer ;true/false can be closed
89 resizeable as integer ;true/false can be resized
90 moveable as integer ;true/false can be moved, in Case of docks, can be docked To other parts of the screen Or undocked If set in dockable
91 borderless as integer ;show the border
92
93 dockable as integer ;0 can't be docked, 1 can be docked or undocked, 2 can only be in docked position
94 dockPosition as integer ; 1 = left, 2 = top, 3 = right, 4 = bottom
95
96 List childGadgets.odd_gadget() ;the list of gadgets in the window
97
98 EndStructure
99
100 Global NewList odd_windows.odd_window()
so to add a window, I call a function that adds an item to my odd_windows dynamic array (list in this language's case). From there, I add widgets to the window. There is a bit of waste there, mostly by using strings the way I am (there's other reasons that don't really need delving into in this thread), though there is waste in linking UDTs. However, the structure in my mind is so much simpler than it would otherwise be.
In a typical running, the overall structure looks like this
odd_windows(0)
x = "0" ; string here because I parse certain information, like "in", "%", "center", etc..
y = "0"
height = "2in"
width = "4in"
disabled = false
closeable = true
moveable = true
borderless = false
dockable = 0
dockposition = 0
childGadgets(0)
gadgetID = (stores a random id used by the base language)
extraData as integer (data that I may store to the button)
x = "0"
y = "0"
width = "0.5in"
height = "0.5in"
disabled = false
constant_name = "name i give it"
typeOfGadget = #button
properties
title = "Button"
inside_width = ""
inside_height = ""
scrollstep = ""
minimum = 0
maximum = 0
pagelength = 0
vertical = 0
childGadgets(1)
gadgetID = (stores a random id used by the base language)
extraData as integer (data that I may store to the button)
x = "0"
y = "0"
width = "0.5in"
height = "0.5in"
disabled = false
constant_name = "name i give it"
typeOfGadget = button
properties
title = "Button"
inside_width = ""
inside_height = ""
scrollstep = ""
minimum = 0
maximum = 0
pagelength = 0
vertical = 0
As you can see, there's a bit of waste, but it's mostly down to me not yet optimizing things. The properties UDT is particularly wasteful, but with another list (and more complexity) I could shrink that down.
Now, try doing something like that without allowing dynamic arrays in types, i'd end up with 2 distinct arrays. A window and gadget array. The gadget array would have to have an ID field referencing the window it belongs to. I would have to scan each index to find the window it belongs to, and this would be very slow because you could have dozens of buttons and widgets. Every time you needed to update the buttons in a window scan the list (probably every loop).
I could cache the associations in a 3rd array, but since I can't have dynamic arrays in dynamic arrays, I'd need a distinct array for each window. This means my gui system cannot really be dynamic and have caching.
I could have one cache array for the current window, I guess that would be a good tradeoff.
Anyway, my point is, we're starting to deal with caching and crazy unlinked (but theoretically linked) structures and it's a big mess.
With my array, in may seem a bit jumbled, but it's all linked in code, and in the debugger it gives an output just like what I posted here. It's *awesome*
And this isn't useful just for guis, but think of a NPCs inventory. How would you program that? You'd have a dynamic array storing all of the items in inventory. But what if you want a variable number of NPCs with a variable number of inventory items. You're hosed again
So yeah, they're complex, but it's nice to work with. That said, memory on these phones is limited, so if I can't even take advantage of it (you'd know better than me) then feel free to ignore me
