Bug/Feature: SearchFilter (in AssetDatabase APIs) is marked internal preventing us from using it

AssetDatabase.FindAssets is unusable without reading the source code (!) because core string arguments with magic values (that you cannot find any other way) aren't even mentioned in the docs, let alone actually defined and described - I've logged a bug for this.

However ... those string arguments are merely a facade for a much better, typesafe, OOP API that Unity has already implemented (you can see it in the source code), with public-friendly API methods and classnames, but has made "internal" for no apparent reason.

I logged a bug against that and it's been rejected as "by design":

https://issuetracker.unity3d.com/issues/searchfilter-is-inaccessible-due-to-its-protection-level

i.e. an unsafe, error-prone, (currently undocumented!) API with unnamed args and magic values ... is the "by design" ... and the compile-safe, refactorable, clearly-named, cleanly-designed API with clear method names and args ... is the "no, you can't use it ... by design".

I was told that the developers will now not fix this, and that I must instead create a forum thread and hope that someone reads it. So. Here we are!

(until Unity fixes it, I recommend using Reflection to access the full API that you should be using, instead of the undocumented, low-quality magic-strings-method that they want you to use)

 

Thanks, Lukasz. That package looks interesting, and seems to have a lot of expressive power.

On first investigation it looks like it's designed to solve a similar-but-different set of problems, around "customizing the search UI inside the editor" (my interpretation based on reading the docs - possibly very wrong!). I saw some nice stuff about making it easy to add icons and popups/buttons/interactions - which I like, but none of which are relevant when you're trying to run something from script - and I couldn't see anything around making it easy to perform an actual search?

In particular, this appears to have the same problem as the current API: access is via "magic strings" such as "me:" (which doesn't mean "self" or anything relating to the word "me", it apparently means "menu item" - I'm guessing it's "ME"nu) and "h:" (which apparently doesn't mean the standard in command-line tools - "help" - instead it means "scene contents" - I found that one particularly head-scratching, not sure how h = scene. I'm guessing it's because the team ran out of short magic strings - which is one of the major reasons I'd avoid this in API design, and perhaps decided that "h" could stand for "handle", and "handle" is a synonym for "name", but you could imagine that "name of thing in scene" is like a "handle" to a scene-object)

TL;DR: I expect I'll enjoy using the QuickSearch package in future, and it looks good for solving the problems it's targetted at, but *for this use-case* it inherits the significant problems described here, and if anything makes them worse (more magic strings! That are even harder to understand!) not better.

 

@sebastienp_unity
> The Query Language itself is made to be used from the tool. But it can be used from our C# API.
Tell me please, if dev team have publicly documented API to perform searches through code or have plans on it. Please, answer here That's the question about that