Page 1 of 1

Question concerning Object::sendMsg

Posted: Tue Sep 22, 2009 10:20 am
by davidmellow
Hi

Regarding Object::sendMsg (and sendMsgWithParams etc.). Something I haven't utilised but I'm sure lots of others may have (in fact I suspect it one of the intended uses of these methods) is to use them in a similar way to passing a delegate to a method in say C#. (My question is at the end of this post.)

In other words if Class1 has a method something like aMethod::(pObject : Object ; pMethod : String)

And we have some other class that has a "delegate" method, say...
Class2::aDelegateMethod(pObject : SomeClass) : Boolean

... and somewhere in code it calls...
aClass1Instance.aMethod(self,"aDelegateMethod")

Then that Class1::aMethod(pObject : Object ; pMethod : String) can do something like...
foreach x in SomeClass.instances do
result := pObject.sendMsgWithIOParams(pMethod,x);
if result then
// do whatever
endif;
endforeach;

In other words this method is calling a "delegate" method of the calling object (sorry, my terminology doesn't quite sound right).

In terms of result, it's kind of similar to what I'd do quite a lot in C#, but my question is... given the method name is passed as a string (unlike passing a C# delegate that is strongly-typed) there must be some kind of reflection going on, and in a loop like that I am wondering about overhead (how significant would it be). And to some extent I'm asking, is this whole methodology a bad idea or something that is in fact widely used by others?

Cheers
David

Re: Question concerning Object::sendMsg

Posted: Tue Sep 22, 2009 9:59 pm
by Dino
There's nothing fundamentally wrong with using getPropertyValue, sendMsg, sendMsgWithParams, etc so long as they're genuinely required for what you need to do. In general, if you can achieve something easily using direct property access and/or direct method calls, then that's probably the way to go. But when writing generic frameworks and/or reusable components, indirect access (like sendMsg, etc) can be very useful. Interfaces (introduced in JADE 6.2) give you another way of doing things that you might previously have done only with indirect method access.

You're right that there is a performance overhead when making the method call. The Object Manager first has to call the sendMsg, etc method itself which then does an in-memory dynamic bind of the actual method you want to invoke, before calling it. This is slower than calling the method directly. Here's a quick test of three JadeScripts using 6.3.4 in single-user mode.

Code: Select all

vars i, n : Integer; begin foreach i in 1 to 100000 do n := self.edition; endforeach; end;
Times for three runs: 0.062s, 0.062s, 0.062s

Code: Select all

vars i, n : Integer; begin foreach i in 1 to 100000 do n := self.sendMsg("edition").Integer; endforeach; end;
Times for three runs: 0.156s, 0.172s, 0.171s

Code: Select all

vars i, n : Integer; begin foreach i in 1 to 100000 do n := self.sendMsg(Object::edition.name).Integer; endforeach; end;
Times for three runs: 0.172s, 0.172s, 0.171s

So across these tests, calling the edition method via sendMsg is 2.77 times slower than calling it directly.

Dean.

Re: Question concerning Object::sendMsg

Posted: Wed Sep 23, 2009 9:08 am
by davidmellow
Cheers, thanks Dino.

One of those things I might think about doing in certain circumstances, the obvious one being when a generic function doing some kind of processing on a collection is potentially going to be filtering which members to include differently with each implementation, a kind of filter. Etc.

Thanks for taking time to do that speed test, that overhead incurred by late-binding doesn't seem too bad if a given situation warranted that kind of approach.

And an aside regarding your comment on interfaces, I was recommended a very good book recently on architecting systems (aimed a bit more at .NET but applicable to any system really) and I was surprised the degree to which interfaces figured in the author's thinking. A damned interesting read actually.

Thanks again Dean
David

Re: Question concerning Object::sendMsg

Posted: Wed Sep 23, 2009 9:30 am
by ghosttie
Depending on what you're doing with those collections, the pseudo-types MemberType, KeyType etc. could be useful

Other than speed of execution, the big drawback of sendMsg is that it won't show up if you get a list of references to a method

Re: Question concerning Object::sendMsg

Posted: Wed Sep 23, 2009 9:37 am
by BeeJay
It will show up on the references if you use meta-data notation instead of a string literal. eg:

Code: Select all

someObject.sendMsg( SomeObjectClass::someMethod.name );
This also has the advantage of being automatically maintained should someone rename the method etc.

Cheers,
BeeJay.

Re: Question concerning Object::sendMsg

Posted: Wed Sep 23, 2009 10:11 am
by Simon B
I was recommended a very good book recently on architecting systems (aimed a bit more at .NET but applicable to any system really) and I was surprised the degree to which interfaces figured in the author's thinking.
Title ?

Re: Question concerning Object::sendMsg

Posted: Wed Sep 23, 2009 10:14 am
by Simon B
It will show up on the references if you use meta-data notation instead of a string literal. eg:

Code: Select all

someObject.sendMsg( SomeObjectClass::someMethod.name );
This also has the advantage of being automatically maintained should someone rename the method etc.
Yeah - in general "red literals" are to be avoided. Meta-data notation is useful even for one-off datafix JadeScripts, for the referencability / auto-rename if the method changes reasons, IMHO.

Re: Question concerning Object::sendMsg

Posted: Wed Sep 23, 2009 12:25 pm
by davidmellow
I was recommended a very good book recently on architecting systems (aimed a bit more at .NET but applicable to any system really) and I was surprised the degree to which interfaces figured in the author's thinking.
Title ?
It's "Microsoft .NET: Architecting Applications for the Enterprise" by Dino Esposito and Andrea Salterello (to cut relative shipping cost I also threw in "ASP.NET and AJAX: Architecting Web Applications" by Espisito, looks good but haven't delved into it so much). All of the customer reviews on Amazon were 5 star and although it is perhaps aimed primarily at .NET solutions I found it a pretty good insight into design principles in general.