Limitations of Overloading operations

[Venkat Seeth]

Hi there,

Howdy. I'm a newbie to ICE. I'd like to know how to overcome the limitations of overloading operations?

I'm implementing a VISITOR pattern and all the method names happen to have the same name. What are the suggested alternatives avaliable to me.

Thanks,
Venkat

[michi]

I'm not sure exactly what you are trying to do. For the visitor pattern, you normally don't need to overload operations. For example:

interface VisitorBase {
    void visit();
};

interface SomeType extends VisitorBase {
    // whatever operations you like; the
    // servant of SomeType implements
    // visit() for that type.
};

interface SomeOtherType extends VisitorBase {
    // whatever operations you like; the
    // servant of SomeOtherType implements
    // visit() for that type.
};

Slice does not allow you to overload operations. For example, the following is illegal:

interface Foo {
    void op(int param);
    void op(string param); // Redefinition error
};

But overloading really is only syntactic sugar -- you can achieve the same things as:

interface Foo {
    void opInt(int param);
    void opString(string param);
};

Cheers,

Michi.

[Venkat Seeth]

Hi Michi,

Thanks for the quick response.

I know its only syntactic sugar but it makes it a little easier when the class hierarchy keeps growing and I need to call only one method on the visitor by passing the current instance.

There are 2 flavors:

interface Shape {
	void accept(ShapeVisitor visitor);
}


class Circle implements Shape {
	void accept(ShapeVisitor visitor) {
		visitor.visit(this);
	}
}

class Square implements Shape {
	void accept(ShapeVisitor visitor) {
		visitor.visit(this);
	}
}

interface ShapeVisitor {
        void visit(Circle circle);
        void visit(Square square);
}

Here, I can eliminate coding the same thing by introducing a base implementation.

interface Shape {
	void accept(ShapeVisitor visitor);
}


abstract class CommonShape implements Shape {
	void accept(ShapeVisitor visitor) {
		visitor.visit(this);
	}
}

class Circle extends CommonShape {
	// no need to extend accept.
}

class Square extends CommonShape {
	// no need to extend accept.
}

interface ShapeVisitor {
        void visit(Circle circle);
        void visit(Square square);
}

Thanks again,
Venkat

[michi]

I'm sorry, but there is no way to do this. Slice does not allow overloading of operations because that would make it pretty much impossible to map Slice to languages that do not support this feature. I'm afraid you will have to use visitCircle() and visitSquare() operations.

Cheers,

Michi.

[Venkat Seeth]

Thanks again for your message.

On a related topic, I've been struggling with the architectural implications of Classes With Operations.

Say, with the example, I've a tree of Shape objects and I pass around this tree to various servers, which could interpret it in different ways. Also, add to the fact that each node has some behavior for the Visitor pattern. I'm now struck with providing client-side native code.

Can I just define Shape interface, its container and the Visitor interface in Slice and provide implementations in my choice of PL.

What’s the best/suggested way to solve this kind of a problem?

Any thoughts are appreciated.
Thanks,
Venkat

[marc]

I'm afraid I don't understand the question. What exactly is the problem? Yes, you must provide the implementation code in your client. Objects by value means that you transfer the type and state of objects, but of course you cannot transfer behavior. This is outside of the scope of the contract specified by Slice, as Slice is not a programming language, but only an interface and state description language. Your application code must make sure that the instances of objects received by value exhibit the appropriate behavior.