Mark,
Firstly, congratulations on a thriving community and I really do like the advances you have made with Blitz Max over previous version.
Now, I understand your dilemma. I thought dmoc had the right idea suggesting CType, rather than just Type. So there is a clear distinction with regards to it's construction and implementation. Typical users do not have to use it.
I'd suggest that even the syntax in code be different for accessing the members (fields), such as "->".. This makes it obvious all throughout the code that this is a different type.
e.g.
My day job involves development primarily with C and C++, to a lesser degree Delphi and sporadically .Net (but this is increasing). I disagree that C/C++ is the only language that is perfect for this, as all the languages I previously mentioned provide some form of data structure that maps directly to its layout in memory. I've written code that allows them all to interoperate.
I think a form of 'struct' is a fundamental requirement of any modern programming environment, BMax included, whether it be for interoperating or not.
Lacking a means to create a complex data structure a-la 'struct', will require additional work for your developers to represent this in code. It will require complex peeks/pokes and data manipulation, creating messy and difficult to maintain code.
You will see benefits in performance, as these structs can be allocated as single blocks of memory.
With much of BMax's functionality developed as modules, which in turn interoperate with external libraries, OpenGL being the primary example, I think you are already "commiting" yourself to providing a fairly standard 'struct' type. I use "committing" loosely, because obviously you decide what language features go in to BMax :)
I notice that FASM even allows declaration of 'C' style structures, so perhaps you can leverage this?
Look forward to your thoughts,
Cheers,
Stu
Firstly, congratulations on a thriving community and I really do like the advances you have made with Blitz Max over previous version.
Now, I understand your dilemma. I thought dmoc had the right idea suggesting CType, rather than just Type. So there is a clear distinction with regards to it's construction and implementation. Typical users do not have to use it.
I'd suggest that even the syntax in code be different for accessing the members (fields), such as "->".. This makes it obvious all throughout the code that this is a different type.
e.g.
CType colourargb Field a:Byte Field b:Byte Field g:Byte Field r:Byte End CType CType vert3 Field x:Double Field y:Double Field z:Double Field normal:Double Field colour:colourargb End CType Local myvertar[100]:vert3 myvertar[0]->x = 5 myvertar[0]->colour->a = 255 etc...
My day job involves development primarily with C and C++, to a lesser degree Delphi and sporadically .Net (but this is increasing). I disagree that C/C++ is the only language that is perfect for this, as all the languages I previously mentioned provide some form of data structure that maps directly to its layout in memory. I've written code that allows them all to interoperate.
I think a form of 'struct' is a fundamental requirement of any modern programming environment, BMax included, whether it be for interoperating or not.
Lacking a means to create a complex data structure a-la 'struct', will require additional work for your developers to represent this in code. It will require complex peeks/pokes and data manipulation, creating messy and difficult to maintain code.
You will see benefits in performance, as these structs can be allocated as single blocks of memory.
With much of BMax's functionality developed as modules, which in turn interoperate with external libraries, OpenGL being the primary example, I think you are already "commiting" yourself to providing a fairly standard 'struct' type. I use "committing" loosely, because obviously you decide what language features go in to BMax :)
I notice that FASM even allows declaration of 'C' style structures, so perhaps you can leverage this?
Look forward to your thoughts,
Cheers,
Stu