Suppose you develop an interpreter or file system. There are objects, like variables, procedures and files in some environment. They have a name and content (variable has current value, procedure has the body of code and file has some data in its body). You can request vbl1.value, proc2.execute and file3.content to get their "values" and you can also always request the name of the current object by (vbl|proc|file).name. Suppose that you enable alias objects to given object, alias(name, target). It says that alias has it own name but somehow shares the "value" with the target. How would you design it?

The alias implementation would be strightforward if I had objects separate from their values. All aliases could share the one body then and primary object could be implemented as alias+body also.

On the other hand, primary objects are in 1-to-1 correspondence with their values and it is not wise to "prefer containtment over overriding" for them. Additionaly, most of the objects won't have the aliases and such design is a waste of memory (2 object is 2x memory wasteful in JVM). But, if do not split our objects into name+body, how do implement the aliases? As proxies? This looks like a duplication of code. You first code variable, proc, ... objects and then expand these classes with approapriate proxies. Even trice, since now objects must be interfaces which admit first-class and proxy implementation. Moreover, such splitting makes values/bodies "headless", you cannot get the name, given a body like proc1.name above. Probably that is right since body under consideretion may be accessed through any of aliases now.

I am hesitating. I admit that there can be a better approach. Which one is advised? The aliases seem to be quite in use and therefore general guidelines must exist, I am sure but cannot find anything.

  • To me this sounds like what Microsoft did with IMoniker in COM.
    – Mike
    Feb 12, 2016 at 14:30
  • I'm not sure why I see any real point in the ability to find the name of an object. If it makes implementing aliases simpler, and you don't have any particularly compelling use case for it, I'd suggest losing the .name attribute.
    – Jules
    Jul 12, 2016 at 8:45

3 Answers 3


In filesystems there are two different types of links:

  • hard links: which points to anonymous objects (e.g. inode)
  • symbolic link: which can point to the file's real name, or another symbolic link

In languages like Python, some objects like classes and functions have canonical name that you access through obj.__name__. Reasigning the object to another name, or accessing the object from the alias does not change the object's canonical name.

Many languages also have a concept of weak references, where objects are wrapped by a weak reference object, that allows the object to be deleted.

Also many languages have different notions of names. Dynamic languages consider names to be a runtime notion, and that objects have names. Static languages considers names to be compile time construct, and that name reflections are compiled to a constant string.

If your language have dynamic naming, then to me, it makes more sense that objects are anonymous or have canonical names. If your language have static naming, then you'd probably want each time objects are referenced in code to be different names.

If you want a dynamic language that have lexical names, then yes, you'd need a wrapper object everywhere.


I don't know about any general guidelines regarding the use of aliases.

My initial thought would be to use proxies, so for every type you have an alias variant that points to the real thing.

But what happens when a file that has an alias is destroyed, should the alias also be destroyed, when is known that the alias should be destroyed?

One solution for that is to use the Observer pattern. Let the original object know about its aliases and let it notify the aliases when they are destroyed. The alias can then decide to stick around, or to destroy itself.

Small example in pseudo code:

class File {
    string Name;
    string Content;
    IList<FileAlias> Aliases;
    void Destroy() {
        Aliases.each(x => x.NotifyDestroy());

class FileAlias : File {
    File originalFile;
    string Name; // overriding original
    void Destroy() { }
    void NotifyDestroy() {
        orignalFile = null;
  • In the file system, you normally have 'broken links'. In mine language, aliases always have the proxified objects in the view since you cannot delete the variables and procedures. I welcome if you have a design which admits object removal, but this is nor required. Feb 12, 2016 at 13:38

An alias is just another kind of object. It's data is a reference to some other object. QED.

The key to the Alias concept is that it is subservient to the main object. If the main object goes out of scope, the alias will no longer work.

Breaking out the data as a separate thing that both Objects and Aliases hold on to would not express this quality.

So yea, use the proxy pattern. Not because it saves memory or uses more memory (after all, the amount of memory we are talking about, compared to the size of the data, is minuscule,) but because it better expresses what an Alias is. It's not just another pointer to the same piece of data, it is necessarily less than the real thing.

  • Do you mean that I should prefer the option 2 and save the memory? Feb 12, 2016 at 13:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.