Proper way to implement equals()?

[tmiranda]

I've started fooling around with the plugin to remove all dependencies when you remove a single plugin. One of the things I've discovered is when I create a List (or Set) of Objects that contain Sage Plugins, methods like .contains() do not work presumably because .equals() is not working. I know I can create some custom methods to scan a List<Object> for a specific Plugin but the better way is probably to make a proper .equals() method.

The question is how do I tell Java to use my custom .equals() method when the Object contains a Sage Plugin? I'm using Sean's sagex APIs so the Plugins are all generic Objects.

I'm probably missing something obvious.

Tom

[Fuzzy]

Could you do the matching using the plugin name instead of the plugin object itself?

[stuckless]

I'd personally, store a list of plugin ids. Using a string id for the plugin will ensure that equals and, remove, indexOf, etc, will all work without you having to do any work.

Then when you need a plugin instance, you can call, GetAvailablePluginForID(PluginID) and get a real reference, when needed.

[tmiranda]

The IDs probably are a better way to go....

I didn't do that initially because in Studio comparing two Plugins with == works as expected so I assumed (incorrectly) that means that .equals would work in Java.

[GKusnick]

You can override Object.equals() on classes you define. You can't override it for an existing class (without subclassing it). So if you're calling PluginAPI methods that return arrays of sage.Plugin, there's nothing you can do to cause those returned objects to use a different .equals() method. They'll use the one that's defined for the sage.Plugin class.

(If you're using my API wrappers, the same considerations apply. The .equals() method means whatever the underlying wrapped object says it means, and consumers of those objects don't get to redefine it.)

You may be making an unwarranted assumption that there's a one-to-one correspondence between sage.Plugin objects and PluginIDs. That's not necessarily true; a sage.Plugin object is just a container for some information about a plugin. There's no guarantee that if you ask for the same information again, you'll get back the identical (in the sense of Object.equals()) sage.Plugin object. In particular, I'm pretty sure that sage.Plugin objects obtained from GetAvailablePlugins() will not be .equals() to those obtained from GetInstalledPlugins(), even for the same PluginID.

So in the end I think you're going to have to bite the bullet and compare PluginIDs directly rather than relying on .equals() and its derivatives to detect when two different sage.Plugin objects refer to the same (conceptual) plugin.

[stuckless]

Originally Posted by tmiranda

The IDs probably are a better way to go....

I didn't do that initially because in Studio comparing two Plugins with == works as expected so I assumed (incorrectly) that means that .equals would work in Java.

Well, if you are using sagex apis, and you are working remotely, then .equals() will not work. Mainly because remotely, you never have a handle to the actual sagetv object, but rather a reference object that knows nothing about what it is referencing.

[tmiranda]

Originally Posted by stuckless

Well, if you are using sagex apis, and you are working remotely, then .equals() will not work. Mainly because remotely, you never have a handle to the actual sagetv object, but rather a reference object that knows nothing about what it is referencing.

Understood.

This Plugin is turning out to be a good review on how to write recursive methods. I wrote a recursive constructor that seems to work as I expect. Is it bad practice to use recursive contructors in Java? I want to make sure I'm not going down the wrong path.

Tom

[stuckless]

Originally Posted by tmiranda

Understood.

This Plugin is turning out to be a good review on how to write recursive methods. I wrote a recursive constructor that seems to work as I expect. Is it bad practice to use recursive contructors in Java? I want to make sure I'm not going down the wrong path.

Tom

It's all good unless you don't stop recursing

[tmiranda]

Originally Posted by stuckless

It's all good unless you don't stop recursing

My parents taught me to stop recursing when I was small