<div dir="ltr">An issue has been submitted here <a href="https://bugs.freepascal.org/view.php?id=36783" target="_blank">https://bugs.freepascal.org/view.php?id=36783</a> under the FPC compiler with tags "type helpers".<div><br></div><div>I just want to take a moment and thank you guys for your work and explain for a moment my STRONG support for multiple type helpers. Multiple type helpers have been a big savior to me, allowing me to elegantly solve a long standing design problem I've had with one of my projects. If you guys could take a little time and consider the problem I am about to describe I hope you can think about it and see why and how multiple type helpers have made a big difference to me.</div><div><br></div><div>Previously I have always had a disconcerting problem of how to handle assets in my game engine. An asset is an unknowable concept until such a time as when you come up with an idea for data and the code to use it when writing a game. Examples of assets are things like textures, sounds, shader programs, 3D models, and can be other things you invent, such as game levels, ai scripts, animation paths, or longs lines of dialog in text form. The point is you never know as a developer what kind of asset you might need for a particular game or project and always can invent new ones.</div><div><br></div><div>From a development point of view things "never know" issue presents an issue. I do know I want a universal class to search for and manage assets, but I always often need to tie those assets to a context, for example both textures, shaders, and also 3D models, need to be aware of an OpenGL context in order generate and use assets correctly belong to a specific current context correctly.</div><div><br></div><div>Multiple type helpers have helper me solve this problem in an elegant manner. Any unit I write with my framework which needs to implement an asset type adds a type helper to a the TContext class. Then if I need to use an asset type in another unit I simply include that asset unit in my uses I have access to those assets managed and catalogs by the current context. Consider this snippet of code:</div><div><br></div><div>uses</div><div>  { Bring in texture asset extensions }</div><div>  Codebot.Render.Textures </div><div><br></div><div>{ Later in code I can then access textures valid for that context using a type helper }</div><div>Tex := Context.Textures['smiley_face'];<br></div><div><br></div><div>Multiple type helpers allow other units to define their own assets and attach them directly to a context. Now with multiple type helpers many units can share assets belonging to a single context. In my case I've made all assets derive from a TContextManagedObject giving each asset type an owning context and a name to fit into a particular slot on on a context. Other type helpers for TContext in other units define extensions such as Context.Shaders[], Context.Models[], and Context.Fonts[]. In my opinion when presented with my asset problem, multiple type helpers is the ultimate solution to this "never know" issue.</div><div><br></div><div>Thanks again for those of you who took the time to read and consider my use case. I know there are a multitude of other design approaches to handling this problem, but for my work habits multiple type helpers brings in the most optimal way of handling things, and again this is in my opinion.</div><div><br></div><div>Anthony</div><div><br></div><div><br></div></div>