Question : Naming package variables for clarity

General
,
1

I have a package detailing some helper functions in Vulkan.
I then have a variable under this package called Physical_Device which is exactly what it sounds like, the physical handle to the GPU.

When I assign that variable, I don’t do anything special. But what I would like to do is to somehow make it clearer that it is a ‘package level’ or ‘global’ variable when I assign it without adding _Package or _Global to the name.

As I’ve heard onewingedshark say, “use the type system to define your problem space, and then use that to solve your problem”. The only thing that seems to stand out to me for this is to not use a prefix or a suffix for globals, but to use a record type with the globals inside so I would do Globals.Physical_Device or Handles.Physical_Device when I assign it. This is the closest to anything that I’ve been able to figure out.

Am I searching for a unicorn solution that doesn’t exist in the language itself, did I find the closest equivalent, or is this just something that I’ll have to put in my style guide? Yet another noob question from yours truly.

2

I don’t see the point with your record. Even if you use your package somewhere else in your program, you can still reference your global variable with the complete reference if you want to, like My_Package.Physical_Device.

3

Well, I’m not entirely sure why you’re needing globals to describe things, sure some things need a global state, and some things need a shared and/or local state, but often you don’t need [active/dynamic] state to describe the values & operations (ie the type) that you’ll use to solve the problem. Tiny/toy examples:

  1. Percentage:
    Type Percent is range 0..100;
    As you can see, it is constraining the values to range 0..100, perfectly describing percentages,
  2. Color:
    Type Pixel is record R,G,B,A : Byte; end record;
    Here, too, we’re describing the RGBA pixel-format of four bytes.
  3. State-machine:
Type Event      is (Eject, Stop, Pause, Play, Rec);
Type State      is (Empty, Loaded, Playing, Recording);
Type Transition is Array(State, Event) of State;
Type State_Machine(Map : not null access Transition) is
   Current : State := Empty;
end record;

Procedure Do_Event (Object : in out State_Machine; Trigger : in    Event ) is
Begin
  -- Pre transition stuff
  Object.Current:= Object.Map.All(@, Trigger);
  -- Post transition stuff.
End Do_Event;

Here we describe a state-machine, as what is a transition-table plus a current-state, with an operation that takes a triggering event, thus modeling and constraining the state machine to only values (of State) within the StatexEvent space. (Though for this formulation you would need a Transitions table.)

None of these require a state to define the behaviors, see? (That is, an actual instance of the object.)
I’ve not used Vulkan, so I can’t tell you how it “plays” with your design, it could force things in a way you’d rather not accommodate, but it might be fine.

1 Like