Dynamic Property vs. Marker

Module Design
1

I’m just curious if there is any difference between a Marker and a Dynamic Property that has no key commands. Over the years I’ve discovered some undesirable behavior with Markers, such as their property value getting truncated after you type a comma or any non-alphanumeric character. Also, if for any reason, you subsequently decide that a Marker value should be variable, you need to convert it to a Dynamic Property. So why not just only use Dynamic Properties? This begs the question, do Markers actually have any real use?

1 Like
2

Likely related to this snippet of the Marker documentation, which effectively allows you to collapse a bunch of properties into a single Marker:

3 Likes
3

It’s a good question. I’m not sure they do - perhaps a legacy a bit like what now seems the over-the-top optimisation of stringing marker definitions together in one line ?

The one advantage I can think of is readability; Markers are simple and their definition stands out in a list of Traits. Unlike a Dynamic Property, the defined (for DP, initial) value is shown in the trait list. Also, when you see “Marker” you know it is a static value without diving further into the trait. This simplicity is why I use them.

2 Likes
4

Agree. The marker trait is simple to use when there is going to be no changes to the ‘value’. I use a lot of them in my world in flames modules.

DP’s also have their use, but for much different reasons.

1 Like
5

This sounds a lot like debating a “constant” vs. a “variable” in programming…
(Is a variable, truly a variable if it is defined once and never changes?)

(or static vs. dynamic typing)…

From my perspective, I like the clarity of being able to glance at the module and seeing what is a constant and what is a variable, without having to examine every dynamic property in detail to determine if it is truly a variable or a kludged constant.

While (IMHO) you are correct, that you could use the more flexible (but complex) construct to represent both types of expressions, having two different syntax’s reduces the cognitive complexity.

Complex code = Buggy / Hard to maintain code.

1 Like