Media::duration && Media::start are Properties but are also Promises ?!?!?

Premiere Pro
,
1

Hmmm… That looks wrong.

Rule of thumb for API is that a property call need to be cheap and quick.

Having a property being async breaks that pattern (async => IO bounded => Not cheap nor fast).

It also goes against every other APIs in Premiere ( all other properties are synchornous / async member accessors are all methods - such as : AudioClipTrackItem::getDuration() / VideoClipTrackItem::getStartTime() etc…).

I would expect either those properties to be sychronous (if cheap and fast - ie: no I/O) or be async methods (ie async Media::getStart() and async Media::getDuration() )

Known design Bug ?
Design oversight ?

image
image345×104 3.14 KB

Media

Since: 25.6

Properties

Name Type Access Min Version Description
start Promise<TickTime> R 25.6 Get the media start time
duration Promise<TickTime> R 25.6 Get the media duration
1 Like
2

Hey @MarcClown,

Totally agree, the async properties are… not idiomatic to say the least, and not a favorite either. We’re actually in the process of amending this specifically and will have some updates here very soon!

3

@clegleiter
FYI, I just came across “Application::version” that has the same issue (return a promise while being a property).
May need to addess this one as well.

4

Hey @MarcClown,

That’s also one on my list to address soon. If you need current app version information I’d recommend using the UXP host object instead since it’s more easily accessible and more idiomatic to use.

5

( Yes was actually using the uxp version, I just came across this by accident and saw it was another instance of property returning a promise )

And that begs the question: why the redundancy in returning the “version”?

Do you plan to expose more info in Application::version (such as the build number for example) ?
And/or have a structured object to represent the version (where one could do version::major / version::minor / version::patch / version::buildNumber / …) instead of a string ?
Or plan to follow SemVer string representation in application ?

That should probably eventually be documented to clarify this.