Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Objectteams » Multidispatch pattern with OT/J
Multidispatch pattern with OT/J [message #514478] Mon, 15 February 2010 14:11 Go to next message
Eugene Hutorny is currently offline Eugene HutornyFriend
Messages: 110
Registered: January 2010
Senior Member
The list of OT/J patterns does not mention multidispatch.
With smart lifting OT/J can easily provide multidispatch capabilities:

public class Shape {/*...*/}

public class Square extends Shape {/*...*/}

public class Triangle extends Shape {/*...*/}

public team class Printer {
	protected class PrintableShape playedBy Shape {
		protected String print() {
			return "Shape";
		}
	}
	protected class PrintableTriangle extends PrintableShape playedBy Triangle {
		protected String print() {
			return "Triangle";
		}		
	}
	protected class PrintableSquare extends PrintableShape playedBy Square {
		protected String print() {
			return "Square";
		}		
	}
	public String print(Shape as PrintableShape shape) {
		return shape.print();
	}
}

public class TheTest {
	final Printer printer = new Printer();
	Shape triangle = new Triangle();
	Shape square = new Square();
	
	public void run() {
		System.out.println(printer.print(triangle)); // prints Triangle
		System.out.println(printer.print(square)); // prints Square
	}
 }


Re: Multidispatch pattern with OT/J [message #514535 is a reply to message #514478] Mon, 15 February 2010 17:25 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Nice example, your perfectly right. I probably should write it down as a pattern.

We could even top it by making it truely 2-dimensional:
1. dimension: shapes
2. dimension: printers

I'll just add a subclass of Printer:
public team class GermanPrinter extends Printer {
        protected class PrintableShape  {
                protected String print() {
                        return "Form";
                }
        }
        protected class PrintableTriangle  {
                protected String print() {
                        return "Dreieck";
                }               
        }
        protected class PrintableSquare {
                protected String print() {
                        return "Quadrat";
                }               
        }
}
// instantiate as
Printer printer = new GermanPrinter();


Everything else remains as you wrote it. Just now the program speaks German Smile

What'you think?
Stephan
Re: Multidispatch pattern with OT/J [message #515230 is a reply to message #514535] Thu, 18 February 2010 09:22 Go to previous messageGo to next message
Eugene Hutorny is currently offline Eugene HutornyFriend
Messages: 110
Registered: January 2010
Senior Member
Stephan Herrmann wrote on Mon, 15 February 2010 12:25
Nice example, your perfectly right. I probably should write it down as a pattern.

Everything else remains as you wrote it. Just now the program speaks German Smile

What'you think?
Stephan



I think it deserves its position among patterns.
In my practical experience lack of multiple dispatching led to boilerplate code and numerous if(instanceof)

Re: Multidispatch pattern with OT/J [message #522002 is a reply to message #515230] Fri, 19 March 2010 15:22 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
OK, I finally created this page: http://wiki.eclipse.org/OTPattern/Double_Dispatch
Feedback welcome.

Yesterday also Sven Efftinge published a reflection-based hack for multiple dispatch - and Carsten Pfeiffer already commented that OT/J would have this nicer solution.

In an email Carsten also alerted me of a potential performance issue: If roles are created for the sole purpose of performing the dispatch one might want to think of ways how the number of role instances can be reduced.

He mentioned the concept of lifting participants, asking whether that could possibly be used to force reusing a singleton role instance for all base instances of the same type. I have two comments for that:

  • The lifting participant would have to re-implement the logic of smart lifting which would reduce the elegance of the solution
  • If one role instance is re-used for several base instances it can no longer use callout bindings for forwarding to its base instance, because the base link will no longer be useful.

With these two restrictions a lifting participant would indeed be able to define a singleton policy for a role.

Normally, when I'd want to reduce the number of role instances I'd try to use static role methods, so no role would need to be created at all. However, double dispatch depends on having an instance for dispatching.

However, this would actually make for a quite simple and effective optimization behind the scenes: iff a role class does not define any fields any role creation due to lifting can be avoided, since only three pieces of information are needed: the reference to the base instance, the reference to the enclosing team and the role class that would be selected for lifting. I would think that this optimization would be easier to implement in the VM rather than by byte code transformation. However, I might just have to think harder of what the compiler could actually do here.

On a different note perhaps its not the instantiation that weighs heavy, but the caching, because all roles would remain in the team's cache as long as team and base are still alive. If cache size is an issue we could easily mark a role class as "transient", "one-way" or s.t. like that to tell the compiler that these roles never need to be stored in a cache. Again, if a role does not define state of its own, caching or not will hardly make a difference.

Let me know if either of these issues seem important to you.

cheers,
Stephan

[Updated on: Fri, 19 March 2010 15:28]

Report message to a moderator

Re: Multidispatch pattern with OT/J [message #522258 is a reply to message #522002] Sun, 21 March 2010 21:27 Go to previous message
Carsten Pfeiffer is currently offline Carsten PfeifferFriend
Messages: 34
Registered: July 2009
Member
Stephan Herrmann wrote:

> OK, I finally created this page:
> http://wiki.eclipse.org/OTPattern/Double_Dispatch Feedback welcome.

Looks good to me!

>
> The lifting participant would have to re-implement the logic of smart
> lifting which would reduce the elegance of the solution.

This is indeed not nice. I didn't look deeply into the ILiftingParticipant
API, but I had thought that it would be possible to actually let the runtime
do the lifting for the very first object of a class and then put that into
some kind of HashMap<BaseClass,RoleInstance>. Then the participant could
simply look up the singleton role instance by the base class.

> However, this would actually make for a quite simple and effective
> optimization behind the scenes: iff a role class does not define any
> fields any role creation due to lifting can be avoided, since only three
> pieces of information are needed: the reference to the base instance, the
> reference to the enclosing team and the role class that would be selected
> for lifting. I would think that this optimization would be easier to
> implement in the VM rather than by byte code transformation. However, I
> might just have to think harder of what the compiler could actually do
> here.

I wouldn't actually go that far as making this an optimization behind the
scenes (although that might be a good idea as well). What I had in mind was
an explict decision by the user to use role singletons rather than having a
role instance for every base instance.

> On a different note perhaps its not the instantiation that weighs heavy,
> but the caching, because all roles would remain in the teams cache as long
> as team and base are still alive. If cache size is an issue we could

Yes, exactly that was my concern about using this pattern: many "useless"
role instances lingering in a big internal hashmap, when dealing with many
many instances of few (base) classes.

> easily mark a role class as "transient", "one-way" or s.t. like that to
> tell the compiler that these roles never need to be stored in a cache.
> Again, if a role does not define state of its own, caching or not will
> hardly make a difference.

That would solve the memory problem in an elegant way.

Cheers,
Carsten
Re: Multidispatch pattern with OT/J [message #568340 is a reply to message #514478] Mon, 15 February 2010 17:25 Go to previous message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Nice example, your perfectly right. I probably should write it down as a pattern.

We could even top it by making it truely 2-dimensional:
1. dimension: shapes
2. dimension: printers

I'll just add a subclass of Printer:
public team class GermanPrinter extends Printer {
protected class PrintableShape {
protected String print() {
return "Form";
}
}
protected class PrintableTriangle {
protected String print() {
return "Dreieck";
}
}
protected class PrintableSquare {
protected String print() {
return "Quadrat";
}
}
}
// instantiate as
Printer printer = new GermanPrinter();


Everything else remains as you wrote it. Just now the program speaks German :)

What'you think?
Stephan
Re: Multidispatch pattern with OT/J [message #568438 is a reply to message #568340] Thu, 18 February 2010 09:22 Go to previous message
Eugene Hutorny is currently offline Eugene HutornyFriend
Messages: 110
Registered: January 2010
Senior Member
Stephan Herrmann wrote on Mon, 15 February 2010 12:25
> Nice example, your perfectly right. I probably should write it down as a pattern.
>
> Everything else remains as you wrote it. Just now the program speaks German :)
>
> What'you think?
> Stephan


I think it deserves its position among patterns.
In my practical experience lack of multiple dispatching led to boilerplate code and numerous if(instanceof)
Re: Multidispatch pattern with OT/J [message #573712 is a reply to message #568438] Fri, 19 March 2010 15:22 Go to previous message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
OK, I finally created this page: http://wiki.eclipse.org/OTPattern/Double_Dispatch
Feedback welcome.

Yesterday also http://blog.efftinge.de/2010/03/multiple-dispatch-and-poor-m ens-patter.html published a reflection-based hack for multiple dispatch - and Carsten Pfeiffer already commented that OT/J would have this nicer solution.

In an email Carsten also alerted me of a potential performance issue: If roles are created for the sole purpose of performing the dispatch one might want to think of ways how the number of role instances can be reduced.

He mentioned the concept of http://www.objectteams.org/distrib/new_in_1.4.html#liftingpa rticipant, asking whether that could possibly be used to force reusing a singleton role instance for all base instances of the same type. I have two comments for that:

The lifting participant would have to re-implement the logic of smart lifting which would reduce the elegance of the solution
If one role instance is re-used for several base instances it can no longer use callout bindings for forwarding to its base instance, because the base link will no longer be useful.

With these two restrictions a lifting participant would indeed be able to define a singleton policy for a role.

Normally, when I'd want to reduce the number of role instances I'd try to use static role methods, so no role would need to be created at all. However, double dispatch depends on having an instance for dispatching.

However, this would actually make for a quite simple and effective optimization behind the scenes: iff a role class does not define any fields any role creation due to lifting can be avoided, since only three pieces of information are needed: the reference to the base instance, the reference to the enclosing team and the role class that would be selected for lifting. I would think that this optimization would be easier to implement in the VM rather than by byte code transformation. However, I might just have to think harder of what the compiler could actually do here.

On a different note perhaps its not the instantiation that weighs heavy, but the caching, because all roles would remain in the teams cache as long as team and base are still alive. If cache size is an issue we could easily mark a role class as "transient", "one-way" or s.t. like that to tell the compiler that these roles never need to be stored in a cache. Again, if a role does not define state of its own, caching or not will hardly make a difference.

Let me know if either of these issues seem important to you.

cheers,
Stephan
Re: Multidispatch pattern with OT/J [message #573758 is a reply to message #573712] Sun, 21 March 2010 21:27 Go to previous message
Carsten Pfeiffer is currently offline Carsten PfeifferFriend
Messages: 34
Registered: July 2009
Member
Stephan Herrmann wrote:

> OK, I finally created this page:
> http://wiki.eclipse.org/OTPattern/Double_Dispatch Feedback welcome.

Looks good to me!

>
> The lifting participant would have to re-implement the logic of smart
> lifting which would reduce the elegance of the solution.

This is indeed not nice. I didn't look deeply into the ILiftingParticipant
API, but I had thought that it would be possible to actually let the runtime
do the lifting for the very first object of a class and then put that into
some kind of HashMap<BaseClass,RoleInstance>. Then the participant could
simply look up the singleton role instance by the base class.

> However, this would actually make for a quite simple and effective
> optimization behind the scenes: iff a role class does not define any
> fields any role creation due to lifting can be avoided, since only three
> pieces of information are needed: the reference to the base instance, the
> reference to the enclosing team and the role class that would be selected
> for lifting. I would think that this optimization would be easier to
> implement in the VM rather than by byte code transformation. However, I
> might just have to think harder of what the compiler could actually do
> here.

I wouldn't actually go that far as making this an optimization behind the
scenes (although that might be a good idea as well). What I had in mind was
an explict decision by the user to use role singletons rather than having a
role instance for every base instance.

> On a different note perhaps its not the instantiation that weighs heavy,
> but the caching, because all roles would remain in the teams cache as long
> as team and base are still alive. If cache size is an issue we could

Yes, exactly that was my concern about using this pattern: many "useless"
role instances lingering in a big internal hashmap, when dealing with many
many instances of few (base) classes.

> easily mark a role class as "transient", "one-way" or s.t. like that to
> tell the compiler that these roles never need to be stored in a cache.
> Again, if a role does not define state of its own, caching or not will
> hardly make a difference.

That would solve the memory problem in an elegant way.

Cheers,
Carsten
Previous Topic:OTDT 1.4.0 released
Next Topic:Presentation at GeeCON
Goto Forum:
  


Current Time: Wed Apr 24 19:12:13 GMT 2024

Powered by FUDForum. Page generated in 0.04738 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top