Forums

by johnmunro >> Tue, 27 May 2003 14:18:46 GMT

If a method updates properties on the receiver, it must be updating. Why?

If a method does not update properties on the receiver, it should not be updating. Why? Is there some sort of performance implication?

Why can I call an updating method on one object from a non-updating method on another object, but I can't call an updating method on an object from a non-updating method on the same object?

John Munro

Synergist Limited - Home of FileVisionT
The Bioscience Innovation Centre
Cowley Road, Cambridge, UK
CB4 0DS
Telephone: +44 (0) 1223 478200
Fax: +44 (0) 1223 477969
Email: john.munro@filevision.com
Web: http://www.filevision.com

The contents of this communication are confidential and are only intended to be read by the addressee. We apologize if you receive this communication in error and ask that you contact Synergist Limited immediately to arrange for its return. The use of any information contained in this communication by an unauthorized person is strictly prohibited. Synergist Limited cannot accept responsibility for the accuracy or completeness of this communication as it is being transmitted over a public network. If you suspect this message may have been intercepted or amended, please inform Synergist Limited.

by allistar >> Tue, 27 May 2003 18:22:39 GMT

"updating" means "this method will chage a property on this object". You can call an updating method on one object from a non-updating method on another if the non-updating method does not change any properties on the "self" object.

As far as I can tell it's a compile time check only. The reason I say that is baceuase you can have a mapping method that sets a proprty on the self object when "set = false". I.e. when you retrieve the value of the property the mapping methods wil actually alter another property. The getting of the mapping method prperty need not be in an updating method. If the check was at runtime I would expetct this situation to raise an exception, but it does not.

I find "updating" useful because I can tell straight away whether I should be locking the object before calling the method. Our rule is that whenever you call an updating method on one from from outside that object, you must lock the object first. (This ensures no one else updates it at the same time and also that we have the latest copy of the object in cache). I have a feeling that "lockReceiver" does the same thing.

It is possible that there are runtime optimisations on updating methods, but I don't know what they are.

Regards,
Allistar.

------------------------------------------------------------------
Allistar Melville
Software Developer, Analyst allistar@silvermoon.co.nz
Auckland, NEW ZEALAND

Silvermoon Software
Specialising in JADE development and consulting
Visit us at: http://www.silvermoon.co.nz
*NEW* Simple web access to Jade at: www.silvermoon.co.nz/jhp.html ------------------------------------------------------------------

by johnmunro >> Fri, 20 Jun 2003 12:33:24 GMT

Something just ocurred to me - if a method which modifies properties on the receiver must be updating and one which does not must not be updating, why isn't this maintained by Jade itself? Since there isn't a developer-modifiable aspect to this, why involve the developer unneccesarily? At compile-time it currently detects whether a method should be updating or not (because of the error message you get if it is not updating and should be), so why does it not simply set the "updating" flag itself? The same thing applies in reverse - if it compiled a method which did not need to be updating it would clear the flag...


--
John Munro

Synergist Limited - Home of FileVision(TM)
The Bioscience Innovation Centre
Cowley Road, Cambridge, UK
CB4 0DS
Telephone: +44 (0) 1223 478200
Fax: +44 (0) 1223 477969
Email: john.munro@filevision.com
Web: http://www.filevision.com

The contents of this communication are confidential and are only intended to be read by the addressee. We apologize if you receive this communication in error and ask that you contact Synergist Limited immediately to arrange for its return. The use of any information contained in this communication by an unauthorized person is strictly prohibited. Synergist Limited cannot accept responsibility for the accuracy or completeness of this communication as it is being transmitted over a public network. If you suspect this message may have been intercepted or amended, please inform Synergist Limited.

by allistar >> Fri, 20 Jun 2003 19:16:36 GMT

I think form a development point of view it's healthy to know whether your methods are updating or not. Having that changed without you knowing may not be a good thing. On the other hand having Jade ask whether you would like to add (or remove) the updating modifier would be a good idea.

What of inheritance? A method may be updating not because it actually updates the self object but because a reimplementation (or superclass version) is updating.

Allistar.

------------------------------------------------------------------
Allistar Melville
Software Developer, Analyst allistar@silvermoon.co.nz
Auckland, NEW ZEALAND

Silvermoon Software
Specialising in JADE development and consulting
Visit us at: http://www.silvermoon.co.nz
*NEW* Simple web access to Jade at: www.silvermoon.co.nz/jhp.html ------------------------------------------------------------------

by cnwjhp1 >> Mon, 23 Jun 2003 1:43:01 GMT

I thought this feature was just so developers could identify non-updating methods within their signature. If you don't want to use the feature, just declare them all to be upating. -- jp

by allistar >> Mon, 23 Jun 2003 9:49:07 GMT


Just like everything should be public eh?

I find the "updating" modifier quite useful (it lets me know if I need to exclusively lock an object before calling a method on it). Just like the "protected" method modifier the "updating" modifier isn't explicitely enforced (that is to say that it is valid for no methods to be protected and all methods to be updating, regardless of whether or not they should be). I'm sure Jade code would be more easy to follow if things (methods, properties and classes) were updating/protected/read only/abstract/transient as they should be (instead of the lazy way of making everything public).

Just my 2c.

Allistar.

------------------------------------------------------------------
Allistar Melville
Software Developer, Analyst allistar@silvermoon.co.nz
Auckland, NEW ZEALAND

Silvermoon Software
Specialising in JADE development and consulting
Visit us at: http://www.silvermoon.co.nz
*NEW* Simple web access to Jade at: www.silvermoon.co.nz/jhp.html ------------------------------------------------------------------