Best practice for naming an argument that can mean 3 different things

Question

Consider this... I am writing a class named Cache which will accept either a path to a file/url or a string. I am going to use PHP's functions such as parse_url() and is_file() to determine which input I am receiving.

here is my example, in PHP

class Cache {
    public function __construct($pathUriOrString) {

    }
}

What is the best practice for naming this argument? Is this even a valid way of creating an class, or should this be a base class and have separate classes that extend it?

I got this idea from php image where the construct either receives one argument (a path) or 2 arguments (a width and height).

So, am I on the right track, and if so, what is best practice for naming an argument which takes different inputs (and won't confuse another developer down the track?)

Answer 1

In some places, the prefix "e" is used for "variable type".

# eArg can be one of 3 things:
# 1. ...
# 2. ...
# 3. ...
function somethign($eArg)
{


}

Answer 2

Could you possibly call the variable $resourcelocation and document it accordingly, i.e. it should take a file path, uri path or a string. I don't think it's good practice to call a variable aOrB, it should be generic.

You could possibly improve this by checking the input to the function as to what type it is, and whether it is valid. If it matches neither of the supported argument types then you should throw an error for an illegal parameter.

The class declaration is fine (but missing an opening bracket) btw...

Answer 3

Hmm, do you mean that the class will cache the contents of the resource that the file/URL references, OR the value of a string? I'd be concerned about intending to cache a string, that looks like a file or URL. Or intending to cache a file/URL that is malformed, and it being treated as a generic string.

I think in general, getting one parameter to do two jobs is a design practice that may make life difficult in the future.

Personally, I'd be inclined to add a second parameter that indicates what the first parameter is. Or sub-class.

Answer 4

Better to subclass it twice, once for strings and another for urls. And if the user is entering one or the other, refactor so they must specify. (If not, then presumably your app knows which it's dealing with - pass through explicitly what it knows.) Try to design out this kind of ambiguity.

I hate to ask, but what's the third thing it could mean?