"I've already explained to you how you can avoid that."
Where? Not in this thread.
"Or you could override the iterator to return links, if you *need* them, rather than the actual objects."
How do I override the TList iterator without breaking other people's code when they try to use my library, and without having to make my own list type, which possibly extends the tlist type, which is retarded, because the point of my requesting that feature was to make my life EASIER, and making an extra type whenever I need a list is not making my life easier?
"Try an associative array instead, like TMap (log n)"
Uh, you do know that a TMap is a binary tree, and that unless you balance it when creating it, which would be a big pain in the ass to do, you could potentially have to iterate through every single element in it just as with a list.
And Hashmap? I know what a hash is, and though I don't know what a hashmap is exactly I think I have a pretty good idea, and that is just as dumb as the TMap suggestion for the situation I described.
TMaps are for doing stuff like figuring out which polygons are on the front side of a particular polygon. Hashmaps are... Probably for finding a particular string in a list of strings quickly. Neither of which is anywhere NEAR suited for the purpouse I described.
Talk about attacking every problem as if it where a nail!
"As I've also already explained, this does not nessecarilly involve changing the core BMX modules."
But I bet it does involve creating your own type that extends the list type.
Anyway Flameduckie, you can call my design philosophy crap all you like, but I have 200 happy customers who would disagree wirh you. :-)
I suspect if we were software tools, you would be Kai's power tools. You'd have a slick interface with a few objects on the screen. Click the objects, and more objects would appear. And click those, and more would appear. Very pretty to look at... and utterly USELESS to an artist, because all the real functionality is five layers down from where you started, and what functionality there is is very rigid and inflexible, with no way to enter text in textboxes, because hey, you've got a dial, you don't need to enter numbers manually TOO. That would be bad design!
I on the other hand would be Sonic Foundry's Sound Forge. You might find my interface daunting at first glance, but once you realise that everything is exactly where you expect it to be, and works exactly how you expect it to work, it's really convenient having most of the functionality right there on the face of things. And it's not like 3D Studio Max where EVERY peice of functionality is on one biug messy screen. No, my interface has order to it. It has menus, with names, and there are things in those menus that are supposed to be there. But there aren't six levels of menus because hey, we can't have VOLUME ADJUSTMENT and RESAMPLE on the same menu! That's crazy! Those are different things entirely! Well, yeah, that's true, but it sure is convenient having them on one menu. Do uou really want to have to go three menus down to get to them just so everything is object oriented? No, I didn't think so!
So, no Flameduck, my design does not suck. Yours is just too damn pretty for its own good. :-)
Where? Not in this thread.
"Or you could override the iterator to return links, if you *need* them, rather than the actual objects."
How do I override the TList iterator without breaking other people's code when they try to use my library, and without having to make my own list type, which possibly extends the tlist type, which is retarded, because the point of my requesting that feature was to make my life EASIER, and making an extra type whenever I need a list is not making my life easier?
"Try an associative array instead, like TMap (log n)"
Uh, you do know that a TMap is a binary tree, and that unless you balance it when creating it, which would be a big pain in the ass to do, you could potentially have to iterate through every single element in it just as with a list.
And Hashmap? I know what a hash is, and though I don't know what a hashmap is exactly I think I have a pretty good idea, and that is just as dumb as the TMap suggestion for the situation I described.
TMaps are for doing stuff like figuring out which polygons are on the front side of a particular polygon. Hashmaps are... Probably for finding a particular string in a list of strings quickly. Neither of which is anywhere NEAR suited for the purpouse I described.
Talk about attacking every problem as if it where a nail!
"As I've also already explained, this does not nessecarilly involve changing the core BMX modules."
But I bet it does involve creating your own type that extends the list type.
Anyway Flameduckie, you can call my design philosophy crap all you like, but I have 200 happy customers who would disagree wirh you. :-)
I suspect if we were software tools, you would be Kai's power tools. You'd have a slick interface with a few objects on the screen. Click the objects, and more objects would appear. And click those, and more would appear. Very pretty to look at... and utterly USELESS to an artist, because all the real functionality is five layers down from where you started, and what functionality there is is very rigid and inflexible, with no way to enter text in textboxes, because hey, you've got a dial, you don't need to enter numbers manually TOO. That would be bad design!
I on the other hand would be Sonic Foundry's Sound Forge. You might find my interface daunting at first glance, but once you realise that everything is exactly where you expect it to be, and works exactly how you expect it to work, it's really convenient having most of the functionality right there on the face of things. And it's not like 3D Studio Max where EVERY peice of functionality is on one biug messy screen. No, my interface has order to it. It has menus, with names, and there are things in those menus that are supposed to be there. But there aren't six levels of menus because hey, we can't have VOLUME ADJUSTMENT and RESAMPLE on the same menu! That's crazy! Those are different things entirely! Well, yeah, that's true, but it sure is convenient having them on one menu. Do uou really want to have to go three menus down to get to them just so everything is object oriented? No, I didn't think so!
So, no Flameduck, my design does not suck. Yours is just too damn pretty for its own good. :-)