DATA statements?

Previous topic - Next topic

AndyH

There's no DATA statement in GLB is there?  (unless I've missed them).

Would be handy to have them so I can embed some data in the code and load/create TYPE'd arrays without having to store in an external file and load it in.

Code (glbasic) Select
RESTORE -label-
READ a|a$[ , ... ]
DATA constant|constant$[ , ... ]

Albert

It's missing (to me too).
I use external files instead and READBYTE, READLONG etc...

AndyH

Yes, I would prefer to not use file all of the time.  Sometimes yes, but sometimes it would be real nice to keep it simple (stupid as the saying goes ;)).  You can initialise arrays with a list of values, so this is a similar thing.

This is the kind of thing I'd like to be able to do (any chance of an update Gernot ? ;)):

Code (glbasic) Select
TYPE tWibble
  a;b;c$
ENDTYPE

DIM test[] AS tWibble

RESTORE mylist

LOCAL t as tWibble
FOR i=1 to 3
  READ t.a, t.b, t.c$
  DIMPUSH test[], t
NEXT
// YAY- I now I have an array with three tWibbles defined with values.

mylist:
DATA 0,0,"Hello"
DATA 0,10,"World"
DATA 50,50,"Bye"
* note I may have made some typo's as I've not got GLB here at work to check.


Actually on the subject of reading from files, I've got a routine that loads in my language txt file.  I read a line at a time into a string, split it and create an array element.  I've noticed that this takes a long time, I need to look through when I have time to see what is slowing it down.  I'm working on the level editor of my game at the moment, and I'll be using the read/write BYTE commands when it comes to saving and loading the levels so I'll probably be able to see what might be causing my slowdown then.

Kitty Hello

See DIMDATA. It's much faster than the READ commands from other BASICs, but it's a tiny bit more awkward.

AndyH

Good for simple arrays, but doesn't really allow you to do the same as a READ with DATA statements which you can choose how to load+use.

PeeJay

I have to admit, I'm with Andy on this one - being able to hardcode data into a program is something I have used quite a bit in the past, and does seem quite a big omission in the language
www.peejays-remakes.co.uk
For games, remakes, and GL Basic Tutorials
Artificial Intelligence is no match for Natural Stupidity

bigsofty

"Data", use files and read em into arrays. That way no runtime memory is wasted by storing the information twice... once in the actual DATA statement, once in the actual array...

Files are not ideal but neither are DATA statements both have their plus and minuses but even if we had DATA statements, Id still stick to files because its a superior method IMHO.
Cheers,

Ian.

"It is practically impossible to teach good programming style to students that have had prior exposure to BASIC.  As potential programmers, they are mentally mutilated beyond hope of regeneration."
(E. W. Dijkstra)

AndyH

I'd still use files where they are necessary.  However I have some scenarios where it's just over kill.

For example, I have a type on my title screen sequence where I have four characters.  Each character does something and I need some values stored in the type for each one.  When the title code starts I create a type array for them, and then manually load their starting values (each is different).  A simple DATA statement would make this a little more elegant and easier to read.  Less messy code.

I also have a level editor.  I've some hotspots for mouse click and controls.  I'm loading these up into an array of my custom type and have to specify each hot spot.  While I could put this into a file its a little bit of an overkill to do so.

Having the DATA statements will be a useful feature to have for those that want to use them.  If you don't want to use them then just don't :)  But without them you've not got much choice.  I think they would be a welcome addition to GLBasic.

bigsofty

Hard coding configuration data into the game source makes editing that little bit harder IMHO, requiring a recompile each time as opposed to a little config edit. This kind of flexability can be a godsend for third party users.

Also, its a bit like GOTO, if its there there's a temptation to use it... lazyness may say just stick it in a DATA statements as opposed to more efficiently store it in an external file... or maybe that's just a reflection on my laziness! :P

I like the current command set and I'm generally opposed (Although its no killer if its added) DATA being added. Why? Well, I initially did not like DATA being missing but after using DIMDATA, INI file routines, text file and various typed files IO routines... I realise the current command set FORCES neater coding styles, DATA and code should be seperate... again though, this could just be me! ;)

One thing though I do think typed records in files, would be a valuable addition.
Cheers,

Ian.

"It is practically impossible to teach good programming style to students that have had prior exposure to BASIC.  As potential programmers, they are mentally mutilated beyond hope of regeneration."
(E. W. Dijkstra)

AndyH

I don't understand the fascination to hold GLB where it is?  If GLB didn't move forward it would still be DiNGS.  GLB is great, but it's got plenty of room to grow.

DATA is not a dirty word like GOTO (which funnily enough I see GLB supports) ;)  You don't need or see a use for READ/DATA then don't use it.

I don't need some data to be external and exposed to users to change.  Just looking for a simple method of doing a simple thing.  The reasons above are still valid in my mind.

Kitty Hello

Hmm... And then what data types? like this?
Code (glbasic) Select
RESTORE test
READ a
READ b$
READ c

test:
DATA 5, "phoo", 7

AndyH

Yes, that'd do it.  Similarly types or a single array element (fred.a or foo[4]) could be used as the destination although I'd imagine this is implied.

Code (glbasic) Select
TYPE tPhooHolder
  a
  b$
  c
ENDTYPE

GLOBAL MyPhoo AS tPhooHolder

RESTORE test
READ MyPhoo.a
READ MyPhoo.b$
READ MyPhoo.c

test:
DATA 5, "phoo", 7

bigsofty

Quote from: AndyHI don't understand the fascination to hold GLB where it is?  If GLB didn't move forward it would still be DiNGS.  GLB is great, but it's got plenty of room to grow.
I'm not trying to hold GLB where it is for the sake of it, I do believe, in this instance, that the addition of "DATA" would not be a positive one for the reasons I've already stated.

It would not be a 'disaster' for me personally for "DATA" to be added to the command set but I felt I'd express my opinion on it, like you say Andy I could still ignore it if it was added, just like GOTO.
Cheers,

Ian.

"It is practically impossible to teach good programming style to students that have had prior exposure to BASIC.  As potential programmers, they are mentally mutilated beyond hope of regeneration."
(E. W. Dijkstra)

Ian Price

I personally feel that if it helps users to have a command from days of yore, then why not include it?

You don't have to use it if you don't want to, but you never know when it might come in handy and it can make it easier for new GLB users to make the switch from another language.

Data satements can be incredibly useful, although for the most part I rarely use them, preferring arrays and external .dat files for holding my information.

I also don't think that by not having data statements that GLB is being held back though - there are alternatives and you can live without them, but their use is still valid and pretty much every language I've ever toyed with still uses them. They are yet another tool for developers.
I came. I saw. I played.

Moru

Data statements? Wow, that's ... well it's been a while since I saw them last :-) But they can come in handy for someone converting old games, they are used a lot for some reason. I myself haven't used them since I learned what arrays are. If it's fast done then by all means add it but don't put too much time into it, there are probably other things that will bring GL Basic forward with bigger steps.