[fpc-pascal] modeswitch multihelpers precedence problem

Anthony Walter sysrpl at gmail.com
Tue Mar 10 14:09:12 CET 2020

An issue has been submitted here
https://bugs.freepascal.org/view.php?id=36783 under the FPC compiler with
tags "type helpers".

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.

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.

>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.

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:

  { Bring in texture asset extensions }

{ Later in code I can then access textures valid for that context using a
type helper }
Tex := Context.Textures['smiley_face'];

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.

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20200310/9dc3b5cc/attachment.html>

More information about the fpc-pascal mailing list