このサイトを正しく表示するには、最新のブラウザを使用し、Javascriptを有効化してください。

skeleton.GetAttachment and skeleton.FindSlot

jk12782187

I :heart: Spine!

...just a quick question about "naming consistency":

In the (Unity) runtime, there's these two functions (among many others):

skeleton.GetAttachment(...

skeleton.FindSlot(...

==> Why is one called Get____ and the other one Find____ ?

This regularly confuses me. I often try to use GetSlot(.... or FindAttachment(... which don't exist..

Any semantic reason for this difference? Why not make this consistent?

jk12782187

BinaryCats

(without looking into the runtimes)

I would say when it uses "Find" a key will be an argument, then it will search the skeleton for the key.. usually the name of what ever you want will be the key. Where as Get is more of getting a /thing/ from a list with the input being its position in the list.

TBH, I have read more than one style of coding in the runtimes, whether it is Nate's coding style evolving or there is more than one guy writing the codey bits (not sure of the ES team size).

Pharan

The stuff you're talking about is actually in Spine-C#.
That's all written by Nate, and the API/method names are actually taken from the mother of all Spine runtimes, Spine-libGDX (Spine-Java).

I think the semantic difference is that:
FindSlot actually does a search in a big collection (the master slot list

skeleton.slots)
GetAttachment kinda assumes you already know where the attachment is. You just need to get a reference. So you're not actually trying to "find" it. Note how those methods require you to know which slot the attachment you want belongs to.

IMO though, it's a small difference and similar terms could have been more discoverable. Makes you curious about how it works under the hood though. Thank goodness the Spine runtime is open source, right?

But at this point, an API change can mean breaking people's code. C# can handle it by retaining the methods and marking the old ones [Obsolete] but the same can't be said for other languages.

Nate

Get generally means O(1) while Find is usually O(n). In other words, find does a lot more work and probably shouldn't be used in code that runs every frame.

jk12782187

I see.

@Nate:
Thanks for pointing this convention (Get=>O(1), Find=>O(n) out.) Wasn't obvious to me.

@Pharan, yeah, I did look into the code, and look there's one override like this:

public Attachment GetAttachment (String slotName, String attachmentName) {
         return GetAttachment(data.FindSlotIndex(slotName), attachmentName);
      }

Soooo...

... it actually does use a FIND method, which does loop. I'd probably not use this "GetAttachment" function in performance critical code either way and just keep a reference to the attachment.

I realize that this is rather a minor thing, but I'd go for consistency, call both of them "Find... and mark the Get... one as "deprecated" for legacy...

Just my two cents, it's not too bad as it is after all 🙂
Keep up the osmness!

Pharan

Not all languages have features that allow marking as "deprecated" so it's really not an option.