Oodles o' types

BlitzMax Forums/BlitzMax Programming/Oodles o' types

CS_TBL

(Posted 2007) [#1]

As far as I understand a type is global. Wouldn't this become a problem when using tens of libraries from other ppl, and even in big projects of your own?

Often enough I see solutions here where a lot of types are involved, even for simple things. A typical example is a type like:
TColor (with r,g,b fields)

All nice 'n stuff, but what if something creates a type like this in his own lib/include which I'm using, while *I* otoh already have a TColor with different fields/methods? (one could store RGB values from 0..255, and one could store them as floats or doubles from 0.0 .. 1.0)

If you create some unique specialist type wich such a unique name that you can safely assume there won't be another one (soon) then I can see little harm. It's different however when people start creating types that are so fundamental and generic, like TColor, TPixel, TSprite, TParticle, etc. Then interference is only a matter of time. It's almost like abducting reserved keywords.. :P

So, am I seeing things wrong here or what? :-)

ImaginaryHuman

(Posted 2007) [#2]

Use that `private/public` stuff?

tonyg

(Posted 2007) [#3]

CS_TBL, I raised the same issue before.
Maybe it's not *so* bad as many people put their functions within types although update, draw, create etc will be used often.

CS_TBL

(Posted 2007) [#4]

so, what if there are 2 includes with their own private TColor, and I create a new instance of TColor in my main file, which type will it use?

H&K	(Posted 2007) [#5]

Well... If you are worried about it, (And to be honest I am), you should really start a name space policy.

For Example I know that I have 3 different Type "Entity", SimonH's which is called (I think) TEntity, Gmans which is called Irr3DEntity and my own called MyT_Entity. If we had a namespace option, then this wouldnt be as bad. But as Im using Blide it is in some ways quite good as I can Type MyT_ and the type popupis in the middle of my types.

I do though think MiniB3D Types should be called MiniB3D_Entity (For example), but lots of ppl are happy with it atm, so not my place to complain. Also if I use framework I can select which Types are presented to the complier. Not a solution thoughif you need to include the files with BOTH the Tcolours in.

We just need to encourage the use of more prefixes

ziggy

(Posted 2007) [#6]

There's no reason to worry. you can always use:

Type TEntity
end type
Local Entity:sidesign.minib3d.TEntity 
local Entity3:TEntity
Local Entity4:othermod.whatever.Tentity

The fact that you can avoid full path to module's type is just for making things easy. But BlitzMax trates every module and modserver as namespaces.

CS_TBL

(Posted 2007) [#7]

And what if there aren't relevant modules and every type you want to use comes from an included/imported file?

H&K	(Posted 2007) [#8]

@Ziggy.

Well thats good enough for me. Thanks for the tip.

FlameDuck

(Posted 2007) [#9]

What ziggy said. Also you can use a different kind of class decoration than "T".

ziggy

(Posted 2007) [#10]

CS_TBL: Using included files won't compile, it would be the same as having a duplicate type definition on a single BMX files. include is like 'copy & paste'. Using import on a bmx file is the same as using import on a module. if the file separately compiles, it will give you no errors. If more than one included file generates the same type, I'm not sure what will happen when you instantiate this type from the main bmx file. Anyway, that's what modules are for.