Line continuation ?
Blitz3D Forums/Blitz3D Programming/Line continuation ?
| ||
| Hi, is there a line continuation option in blitz3d? |
| ||
| No. Use a smaller font and/or shorter variable names. |
| ||
| Blimey, a bit silly really, even COBOL '74 has a line continuation option... |
| ||
| You probably do actually need it in COBOL tho. Whereas most people have survived without it in Blitz for several years. I think I would like the option at least, more for clarity than anything else, but whats done is done. |
| ||
| Is that an IDE matter? |
| ||
| Ross C, well yes... |
| ||
| It could be resolved with an IDE modification, but it'd have to parse your code, restructure it to single lines, then compile that. It'd be far safer and tidier to do it via the compiler itself. |
| ||
| In the name of God, Sending Virus in my email account won't solve things. Cya |
| ||
| is Gfx the ide creator? is Litobyte on this planet? will I ever see a line continuation option? |
| ||
| 1. No 2. *shrugs* 3. Not likely with the current incarnation of Blitz |
| ||
| It'd be far safer and tidier to do it via the compiler itself. This is basically a direct result of the Blitz language. Mark has no "line end" identifiers so the rule must exist that every statement be on one line. People bitch about having to end every statement in C++ with a semi-colon, but there's a reason for that ya know. ;) |
| ||
| Very true, however lets look at the language. Blitz3D commands are highly concatenated, and the language is pretty sleek. Situations which require multiple lines in any seriousness don't crop up that often. I would prefer language enhancements, such as x+1 automatically becoming x=x+1. It makes a lot of sense when you use types and so forth. Multiple lines and wrapping leads to code thats harder to visualise IMHO. |
| ||
| The only time I hit this problem is with massive home baked functions... my particle system for example has a function: spawn_particle(x#,y#,z#,delx#,dely#,delz#,start_rot,rot#,life,start_scale#,end_scale#,gravity#,graphic,fx$,sound=0,name$="") Which tends to get a little long, espically when you're doing entityx(thingy),entityy(thingy) etc etc. But it's only a slight annoyance every so often. |
| ||
| Hehehehe, i thought i was doing something wrong in my part system. Good to see someone else with a huge statement like that. i got: make_emittor(x ,y,z,pattern, dest_x, dest_y, dest_z, pspeedy,pspeedx,pspeedz,rotx,roty,rotz,p_type,parent,spread,g_rate,speed,alpha_pattern,max no. parts,weight, size, life_time, p_life_time) |
| ||
| Things can get long when you're nesting For... Next loops, etc. I mean, still short, but over-running the right-hand side, out of view due to indentation. Doesn't bother me too much though... |
| ||
| The only thing I really miss is that arrays are so limited. Sometimes I prefer them over types. 1. I cannot pass arrays to functions and return them. 2. I cannot do this easy: myNewArray = myOldArray, to copy an array to the new variable name 3. Array sorting, merging, etc. And...perhaps BlitzMax would be better off with a different syntax...more standard. Like: for ($a=1;$a<100;$a++) { yo(); } The language is so powerful, the syntax seems too...well...let's say it "fell behind" |
| ||
| You don't need to pass an array to a function as arrays are global, a function will see it anyway. |
| ||
| Not quite right Dr Av: if you could pass them to a function, then the function wouldn't need to know the array it's working on, and could thus be used on any array. As it is now, the function code would be tided with the array. Take java by example: arrays are plain objects, so you can pass them to functions, and return them just like any other object. |
| ||
| exactly. I'd like to pass an array to a function of my choice. Now the function uses an hardcoded array, which makes a "function" pretty useless. |
   |