Mutating Programming Language?

Question

For fun I was thinking about how a programming paradigm could differ from OOP and came up with this concept. I don't have a strong foundation in computer science so it might be common place without me knowing it (more likely it's just a stupid idea :)

I apologize in advance for this somewhat rambling question, anyways here goes:

In normal OOP methods and classes are variant only upon parameters, meaning if two different classes/methods call the same method they get the same output.

My, perhaps crazy idea, is that the calling method and class could be an "invisible" part of it's signature and the response could vary depending on who call's an method.

Say that we have a Window object with a Break() method, now anyone (who has access) could call this method on Window with the same result.

Now say that we have two different objects, Hammer and SledgeHammer. If Break need to produce different results based on these we'd pass them as parameters Break(IBluntObject bluntObject)

With a mutating programming language (mpl) the operating objects on the method would be visible to the Break Method without begin explicitly defined and it could adopt itself based on them). So if SledgeHammer calls Window.Break() it would generate vastly different results than if Hammer did so.

If classes are black boxes then mutating classes are black boxes that knows who's (trying) to push it's buttons and can adapt their behavior accordingly.

You could also have different permission sets on methods depending who's calling them rather than having absolute permissions like public and private.

Does this have any advantage over OOP? Or perhaps I should say, would it add anything to it since you should be able to simply add this aspect to methods (just give access to a CallingMethod and CallingClass variable in context)

I'm not sure, might be to hard to wrap one's head around, it would be kinda interesting to have classes that adopted themselves to who uses them though. Still it's an interesting concept, what do you think, is it viable?

Here's some potential dummy code from a game where a player has is damaged by something. In normal OOP most things would instead be passed as parameters to the method whereas here Damage "pulls" the properties it uses. Different? yes, better? perhaps not :)

Class Player
{
    [AccessableBy:Terrain,Player]
    void Damage
    {
        if (#CallingClass has property HitPoints)
        {
            this.health -= #CallingClass.HitPoints;
        }

        if (this.health < 0 && #CallingClass is Terrain)
        {
            ShowMessage("was killed by the environment");
        }
        else if (health < 0 && #CallingClass is Player &&  #CallingMethod is RocketLauncher)
        {
            ShowMessage("was killed with a rocketlauncher by player" + #CallingClass.PlayerName);
        }

    }
}

To reduce if-else statements you could have method overrides based on caller methods and classes

Answer 1

Let me see if I understand what you're getting at.

In traditional OOP languages like C++ or C#, the action of a method depends on the runtime type of the receiver:

Window w1 = new GlassWindow();
Window w2 = new PlexiglassWindow();
w1.Break(new Brick());
w2.Break(new Brick());

Which method is actually invoked depends on the runtime type, not the compile time type, of the receiver, provided that Break is "virtual".

Languages which have this property are called "single virtual dispatch" languages.

Your proposal is that the action of Break depend also upon the runtime type of the argument. Suppose Break takes an Object:

w1.Break(new Hammer());
w1.Break(new Pillow());
w2.Break(new Hammer());
w2.Break(new Pillow());

and now perhaps four different things happen depending on the runtime types.

This sort of double dispatch operation is very common in things like games, where you want to have different logic for every possible kind of collision: player with laser, laser with laser, laser with player, player with wall, laser with wall...

Languages that have this property are called "double dispatch" languages; languages that can do more than double dispatch are said to be "multiple dispatch".

This is a pretty well-studied area; do a web search on "visitor pattern" to learn more about simulating double dispatch in a single dispatch language.

Answer 2

This sounds pretty much like what S4 is doing in R : defining a generic method and then dispatching to a method based on the signature of the arguments, i.e. :

setGeneric("sum", function(x,y) standardGeneric("sum")) 

# method for numeric object with a numeric argument
setMethod("sum", 
          signature=c("numeric","numeric"), 
          function {
             return(x+y)
})

# method for a numeric object with a character argument
setMethod("sum", 
          signature=c("numeric","character"), 
          function {
             return(paste(x,y))
})

# method for a numeric object with all the rest
setMethod("sum",
          signature=c("numeric","ANY"), 
          function {
             return(x)
})

Or I must have misunderstood you completely. In this code the function "sum" will match the given arguments (what you call the caller (first argument) and the callee (second argument) with the signature of the functions. If it can't match, it will match the one where the signature says "ANY".

PS : this is a trivial example, obviously

Answer 3

You might want to look into Subject-Oriented Programming, as e.g. implemented in the Us Programming Language (by the same people who also did a very nice implementation of Object-Oriented Programming in the Self Programming Language).

In Subject-Oriented Programming, the shape of an object is subjective from the point of view of its caller. I.e. to every caller the object looks different.

This idea was even more generalized in the idea of Context-Oriented Programming in the Korz Programming Language, which has been presented a couple of times this year.

Answer 4

One of main rules in life is not to add extra complexity unless it's needed. The caller in OOP can always pass some parameter that would tell the callee, how exactly the callee must behave. What you want to do is just add an implicit parameter (class/method signature). And what the purpose is?

If some method should react on what the caller is, then just pass the caller's class name / type / whatever explicitly and that's all. With good RTTI this can be done in a handy way - you pass a reference to the caller's object to a callee and callee inspects the type info of the caller object.

Answer 5

I think what you are suggesting completely breaks the concept of abstraction all together. A function should not have logic based on what function or object called it. The is an implicit dependency there that would be a maintenance nightmare.

Answer 6

You can already do this (i.e. finding out who the calling class/method is) in any JVM language by looking at the stack trace. You should have a look at the documentation for the method "getStackTrace" in the Thread class. What you want can be implemented in just a few lines.

Answer 7

Sounds like extension methods.

Except extension methods can only live on static classes. You just want the same idea (a this parameter modifier) for any method.

Answer 8

Your idea sounds similar to:

• Dynamically scoped languages
• Scala's implicit parameters
• Playing with the Kernel#caller method in Ruby
• Creating an Exception in Java (or Scala or any other JVM language), filling in and reading the stack trace (which is slow).

It turns out that you may not even need implicit parameters for what you're trying to do.

Answer 9

This sounds a lot like typeclasses, or, as @Ken Bloom points out, Scala's implicit parameters (which are basically Scala's object-oriented interpretation of typeclasses).