Page 3 of 4
Posted: Sun Jan 13, 2008 12:47 am
by ZeHa
You just said it can produce bugs. Haha.
EVERY new addition to PureBasic can produce bugs. It doesn't matter if it's syntactic stuff, new datatypes or new library functions. If you're so afraid of bugs because of new functionality, then you probably shouldn't move on to new versions of PB.
I think that's obvious. So, are there any other reasons why you're absolutely against that feature (which isn't really a feature, it should be regardet as basic functionality)?
Posted: Sun Jan 13, 2008 1:06 am
by Dare
Okay, moving away from the debate and the point scoring ...
Would this sort of thing be hard to implement? My take is no, overall, and also there are several ways it could be handled syntax-wise.
One way might be to define a linked list like we do a Stucture and then apply that to the structure definition, eg.
Code: Select all
DefineList listNameA
aString.s
EndDefineList
DefineList listNameB
myString.s
myLong.l
myWord.w
EndDefineList
DefineList nestedList
wooHoo.l
oneDeep.listNameB
EndDefineList
Structure structName
someLong.l
myListA.listNameA
myListB.listNameB
confuseUsAll.nestedList
etc.s
EndStructure
Would that be reasonable?
Regardless ..
I don't think this is above the capabilities of the PureBasic team. (Although it is a fiddly task). I don't know what priority it would have in a list of "What is best for PureBasic" though. It is not only useful for games, but also for anything with transactions involved.
Currently we can use sqlLite in-memory (pdwyer has done some eg code) to handle these things. But it would be nice as a native capability.
Posted: Sun Jan 13, 2008 1:23 pm
by Hroudtwolf
ZeHa wrote:You just said it can produce bugs. Haha.
EVERY new addition to PureBasic can produce bugs. It doesn't matter if it's syntactic stuff, new datatypes or new library functions. If you're so afraid of bugs because of new functionality, then you probably shouldn't move on to new versions of PB.
I think that's obvious. So, are there any other reasons why you're absolutely against that feature (which isn't really a feature, it should be regardet as basic functionality)?
Young man.
You should know, that syntaxchanges could produce widespread problems than new libs.
So, it is logic that I am against syntaxchanges.
This is my position.
Best regards
Wolf
PS: Please break up trolling. You should accept and respect other people opinion.
Posted: Sun Jan 13, 2008 2:23 pm
by ZeHa
Well I just think your "paranoia" is not a reason for not adding a good and needed (!) feature. You also offer an alternative for the feature, that should prove that you also understand the need for it.
I think it's possible to dislike feature requests because of a valid reason, but "fear of the bugs" is no valid reason in my opinion. Except if it's obvious that there might occur problems - which is not the case here (or do you think allowing "NewList" inside a Structure definition might cause such big problems? If so - you're welcome to tell us about that (I'm serious about this). If not, well, probably it might not be as dramatic as you're making it).
Hroudtwolf wrote:This is a discussion-forum. If you don't want discussions, your'e not right here.
Yes, probably that's a true thing. Think about it and discuss. I can't see any "discussion" from you, at least you don't answer to anything I wrote, you just keep repeating your "I don't like that"-statements.
Posted: Sun Jan 13, 2008 2:29 pm
by ZeHa
PS: Nobody forces you to use PB's beta versions. And you know that PB's beta phases are usually long enough for bug hunting.
Posted: Sun Jan 13, 2008 2:35 pm
by Hroudtwolf
I (and surely many other peoples) find continuing long time hidden compiler specific-bugs outside the beta-phases.
I don't talk about beta-phases.
but "fear of the bugs" is no valid reason in my opinion.
I don't think you have the competence to decide this. ^^
Posted: Sun Jan 13, 2008 2:40 pm
by ZeHa
I know, because I never produce bugs :roll:
Posted: Sun Jan 13, 2008 5:05 pm
by Demivec
Dare wrote:Would this sort of thing be hard to implement? My take is no, overall, and also there are several ways it could be handled syntax-wise.
One way might be to define a linked list like we do a Stucture and then apply that to the structure definition, eg.
Code: Select all
DefineList listNameA
aString.s
EndDefineList
DefineList listNameB
myString.s
myLong.l
myWord.w
EndDefineList
DefineList nestedList
wooHoo.l
oneDeep.listNameB
EndDefineList
Structure structName
someLong.l
myListA.listNameA
myListB.listNameB
confuseUsAll.nestedList
etc.s
EndStructure
Would that be reasonable?
I think using a "DefineList" be a working solution and be straight-forward also. I still think we need some parens on the names though for maintaining consistency. This approach could also work well for a pre-processor, the-provider-of-unimplement-features.
Posted: Sun Jan 13, 2008 6:10 pm
by Psychophanta
Sincerely i can not see the point of the initial request here
Posted: Sun Jan 13, 2008 6:24 pm
by ZeHa
It's just about being able to have a LinkedList as an element of a Structure. It's also possible to have arrays inside a structure, so why not a LinkedList?
Posted: Sun Jan 13, 2008 6:43 pm
by Psychophanta
But as you say, there are many workarounds to do that, and some of these workarounds are really really elegant.
So then to implement that request would be a good way to complicate PB language unfoundedly, imo. :roll:
Posted: Sun Jan 13, 2008 7:01 pm
by tinman
I'd welcome linked lists inside structures.
To add to the handbags at high noon, I can't believe no-one has suggested syntax based on the syntax of arrays within structures:
Code: Select all
Structure stuff
a.l[5] ; An array
b.l[] ; A list
EndStructure
Define.stuff mystuff
FirstItem(mystuff\b[])
; Similar to this...
NewList mylist.l()
FirstItem(mylist())
Of course, you now also need some way to initialise your list field if you create your structures dynamically. Perhaps an InitialiseList() command in the linked list library?
Code: Select all
*dynamic.stuff = AllocateMemory(SizeOf(stuff))
InitialiseList(*dynamic\b[])
It should probably give a debugger warning that the list was initialised when it was already initialised, and perform no operation with the debugger off.
Of course, it's all potentially confusing and easy to get wrong. But PB has already gone down that road with arrays within structures so we might as well use the same syntax ;)
Posted: Sun Jan 13, 2008 7:02 pm
by netmaestro
When Fred implemented static arrays inside structures he didn't use Dim and standard arrays. He had his reasons for doing so, and they are likely similar to the reasons we haven't seen this.
While I can readily see how some coders would find it useful, my opinion is that it would be a memory management nightmare and I would be surprised if they made this change.
Posted: Sun Jan 13, 2008 7:18 pm
by Psychophanta
netmaestro wrote:While I can readily see how some coders would find it useful, my opinion is that it would be a memory management nightmare and I would be surprised if they made this change.
+1
@Tinman, what you say is just that pB make that in an automatic way (and conserving the same syntax) instead of do it in an advanced programming way (changing syntax when dealing with structure fields).
It is a discutible dilemma, but my inclination is for the no automatic way to manage lists and arrays as structure fields. But a manual way. Even thinking twice there might not be a surplus to have it. :roll:
EDIT: But another point against is that for a language; the simpler the better. i.e. that 1 unique posibility way to do a thing is better than 2 or more different ways because you must to use more memory in your own brain to know the language.
Posted: Sun Jan 13, 2008 7:58 pm
by DarkDragon
netmaestro wrote:While I can readily see how some coders would find it useful, my opinion is that it would be a memory management nightmare and I would be surprised if they made this change.
No, because:
Code: Select all
Structure TestStruct
dataA.l
dataB.s
EndStructure
; The normal construction of a purebasic like linked list
Structure PB_LinkedList
*next.PB_LinkedList
*prev.PB_LinkedList
dat.TestStruct
EndStructure
; Example how Fred could do it internally without having to do a lot of memory management
Structure TestLLInStruct
*test.PB_LinkedList
EndStructure
NewList TestList.TestStruct()
Global testStructuredVar.TestLLInStruct
; Initialize the first element
AddElement(TestList())
TestList()\dataA = 42
TestList()\dataB = "Hello, World!"
testStructuredVar\test = @TestList() - 8
; Give it a second element
AddElement(TestList())
TestList()\dataA = 2
TestList()\dataB = "foobar"
; Debug everything through our variable
Debug testStructuredVar\test\dat\dataA
Debug testStructuredVar\test\dat\dataB
Debug testStructuredVar\test\next\dat\dataA
Debug testStructuredVar\test\next\dat\dataB
; So you see how it is working. You could also write the data yourself through the testStructuredVar.
; But for now: That's what PB already internally does. It works with one pointer.
; It would just be nice to have the functions AddElement etc.
; for those testStructuredVar\test pointers as it isn't much more without structure.
; So it's just ONE pointer to a LL element.
@Psychophanta:
JJJJAAAAVVVVAAAA ... CTRL+SPACE ... Windows API ... You know what I mean (MSNM).
