I suggest "finder" or "loader". Thoughts?

Comments

eclipsegc’s picture

eclipsegc commented

I REALLY like discovery still. Is there a good dx reason to change this?

effulgentsia’s picture

effulgentsia commented

Possibly not. It strikes me as a little unusual: I don't have any familiarity with "discovery" as an object or class name from any other system or design pattern, whereas finders, loaders, locators, etc. are well established concepts. Anyone else have an opinion?

effulgentsia’s picture

effulgentsia commented

Also, what is $this->discovery? Is it an object that itself is a discovery? No. It's something that finds/loads/discovers things, or assists with the process of discovery, but that's not really clear from the name.

neclimdul’s picture

neclimdul
He/Him
commented

I'm not sure what your last comment about $this->discovery is saying.

I'm not familiar with finders/locators as a pattern. Loaders would seem mismatched with what is happening. If there is a documented pattern that matches what we're doing we should definitely use it though. Do you have any links or something I could read?

effulgentsia’s picture

effulgentsia commented

In some ways, a service locator pattern is similar to what we're calling a plugin type, in that it typically provides a single object point of access for both finding and instantiating. At least if I'm understanding http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceLocator.... correctly.

At a simplistic level, if someone new to the plugin system asked me what it is, I'd say something like "It's a system for creating plugin types. A plugin type is an object that's responsible for finding the plugins available for it, loading their definitions, and instantiating them. A plugin type can be made easily by composing a discovery object for finding plugins and loading their definitions, and a factory object for instantiating them." (I'm ignoring mappers for now in this explanation)

While I think the above 3 sentences are reasonably good for getting across the gist, I wonder if there's a way we can make it even easier, and if "discovery" is an extraneous bit of terminology that can be removed.

I'm not sure what your last comment about $this->discovery is saying.

From http://www.thefreedictionary.com/discovery:

1. the act, process, or an instance of discovering
2. a person, place, or thing that has been discovered

$this->discovery doesn't fit either of those definitions. $this->discoverer would be more accurate, but sounds awkward.

neclimdul’s picture

neclimdul
He/Him
commented

I think that definition downplays something important about the plugin system. Definitions in it seem like a side note which beg the question "why don't we just use a service locator alone." Plugins really are about definitions and the UI that is able to support. And therefore despite being nested inside, "discovery" is the most important port. Types are just there to provide an API designer a common interface to their consumers.

I guess you're right about discovery being a verb rather then a noun though which is a bit frustrating.

effulgentsia’s picture

effulgentsia commented

How about "registry"? I think that captures the concept of "an object that can retrieve a list of named things and important information about those things" with a commonplace software engineering term.

oadaeh’s picture

oadaeh commented

Isn't there already the idea of a registry in Drupal? Wouldn't that just create a different confusion in different area (unless the idea was to merge the two, but I don't recall seeing that mentioned in any of these threads)?

Also, I think "loader" is more closely representative of what the factory does.

I would say "finder" might work, but that reminds me too much of the Mac OS.

For simply converting a verb to a noun, "discoverer" is correct, but is, as @effulgentsia points out, difficult and awkward.

"locater" (or "locator") is another option.

eclipsegc’s picture

eclipsegc commented

I would not freak out about locator, but I still far prefer discovery. fwiw.

Eclipse