Walnut/Distributed Computing/Naming conventions - Revision history

Kevin Reid: rvv

Kevin Reid — Thu, 21 Apr 2011 00:32:03 GMT

rvv

New page

[[Category:Walnut|3]]

===Naming conventions===

In the examples up to this point we have been using a number of naming conventions. Here are some common conventions.

'''car''' -- an object that you can treat as a [[near object]], using [[immediate call]]s or [[eventual send]]s as you wish.

'''carVow''' -- a car that will be near, available for immediate calls, once you resolve the [[vow]] inside a [[when-catch clause]].

'''carRcvr''' -- a car that must be treated as a [[remote object]], spoken to only with eventual sends, never with immediate calls, because although it might sometimes be a near car, it can also be remote, and only eventual sends are safe. As noted earlier, another way of denoting that a car may be remote is to use the ":rcvr" [[guard]].

'''getCar(licensePlate)''' -- a function or a method that returns a local car (local to the object implementing getCar)

'''getCarVow(licensePlate)''' -- a function or a method that returns a vow for a car, not the car itself. If you are calling this method on a local object, once you resolve the vow, the car is local.

'''getCarRcvr (licensePlate)''' -- This method returns a car which the author of the method has reason to believe may be a remote car. Consequently, it is a warning that you should only interact with the returned object with eventual sends.

'''getCarVow(licensePlateVow, titlePapersRcvr)''' -- this method explicitly names the parameters licensePlateVow and titlePapersRcvr. Whereas the suffixes Vow and Rcvr are ''warnings'' when used in a method or variable name (warnings to avoid the use of immediate calls), when used as parameter suffixes they are ''commitments''. In this example, the developer of the getCarVow method is making the commitment to users of the method that he will not make immediate calls on the licensePlate until he has resolved the plate in a when-catch block. And he is making the commitment that he will only interact with the titlePapers using eventual sends. In general, if at least one of the parameters for a method is either a Vow or a Rcvr, the method itself cannot return a near object: if the method must wait on eventual sends to gather the info to return an object, it cannot reasonably return the object immediately. No doubt, however, someone reading this will be the first person to invent a situation that breaks this general rule. We congratulate you in absentia.

'''makeCar (name)''' -- a carMaker that is local, can be immediately called, and makes cars that can be immediately called.

'''makeCarVow (name)''' -- an object maker like a carMaker, but which is dependent on construction that may only resolve eventually, so it can only send you a promise for the car.

'''makeCarRcvr(name) '''-- a local carMaker that may make the car on a remote system, and therefore the cars should be treated as Rcvrs.

'''carMakerRcvr(name)''' -- a carMaker that may itself be on a remote system, that should only be spoken to with eventual sends. Rather than having a very wordy term for remote Makers that make remote cars (which are local to the Maker), since such a Maker is almost always going to create cars that you must treat as Rcvrs, we use carMakerRcvr to also designate makers that we might be tempted to name "carRcvrMakerRcvr". This name, carMakerRcvr, is a first and only example you will see here of the more generalized naming convention used when constructors and authorizers and rcvrs are interrelated in a complex way. Rather than depending on a prefix that might refer to any chunk of the name, we stack up the descriptions as suffixes. Multiple levels of constructors and [[authorizer]]s play an important role in achieving '''''E''''''s security goals, so while these complicated structures are uncommon in most of the code in a system, there are likely to be a few parts in a secure system where such naming conventions play a role.

92.79.175.103: llvuIsdbNwNKFDr

92.79.175.103 — Wed, 20 Apr 2011 04:34:04 GMT

llvuIsdbNwNKFDr

←Older revision		Revision as of 04:34, 20 April 2011
Line 1:		Line 1:
-	~~[[Category:Walnut\|3]]~~	+	ynmrvR Kudos! What a neat way of tkhiinng about it.
-		+
-	~~That's way the beestst answer so far~~!	+

41.133.87.50: /* Naming conventions */

41.133.87.50 — Wed, 20 Apr 2011 03:24:43 GMT

Naming conventions

←Older revision		Revision as of 03:24, 20 April 2011
Line 1:		Line 1:
	[[Category:Walnut\|3]]		[[Category:Walnut\|3]]

-	~~===Naming conventions===~~	+	That's way the beestst answer so far!
-		+
-	~~In the examples up to this point we have been using a number of naming conventions. Here are some common conventions.~~	+
-		+
-	'~~''car''' -- an object that you can treat as a [[near object]], using [[immediate call]]~~s ~~or [[eventual send]]s as you wish.~~	+
-		+
-	~~'''carVow''' -- a car that will be near, available for immediate calls, once you resolve the [[vow]] inside a [[when-catch clause]].~~	+
-		+
-	'''carRcvr''' -- a car that must be treated as a [[remote object]], spoken to only with eventual sends, never with immediate calls, because although it might sometimes be a near car, it can also be remote, and only eventual sends are safe. As noted earlier, another way ~~of denoting that a car may be remote is to use~~ the ~~":rcvr" [[guard]].~~	+
-		+
-	~~'''getCar(licensePlate)''' -- a function or a method that returns a local car (local to the object implementing getCar)~~	+
-		+
-	~~'''getCarVow(licensePlate)''' -- a function or a method that returns a vow for a car, not the car itself. If you are calling this method on a local object, once you resolve the vow, the car is local.~~	+
-		+
-	'''getCarRcvr (licensePlate)''' -- This method returns a car which the author of the method has reason to believe may be a remote car. Consequently, it is a warning that you should only interact with the returned object with eventual sends.	+
-		+
-	'''getCarVow(licensePlateVow, titlePapersRcvr)''' -- this method explicitly names the parameters licensePlateVow and titlePapersRcvr. Whereas the suffixes Vow and Rcvr are ''warnings'' when used in a method or variable name (warnings to avoid the use of immediate calls), when used as parameter suffixes they are ''commitments''. In this example, the developer of the getCarVow method is making the commitment to users of the method that he will not make immediate calls on the licensePlate until he has resolved the plate in a when-catch block. And he is making the commitment that he will only interact with the titlePapers using eventual sends. In general, if at least one of the parameters for a method is either a Vow or a Rcvr, the method itself cannot return a near object: if the method must wait on eventual sends to gather the info to return an object, it cannot reasonably return the object immediately. No doubt, however, someone reading this will be the first person to invent a situation that breaks this general rule. We congratulate you in absentia.	+
-		+
-	~~'''makeCar (name)''' -- a carMaker that is local, can be immediately called, and makes cars that can be immediately called.~~	+
-		+
-	~~'''makeCarVow (name)''' -- an object maker like a carMaker, but which is dependent on construction that may only resolve eventually,~~ so ~~it can only send you a promise for the car.~~	+
-		+
-	~~'''makeCarRcvr(name) '''-- a local carMaker that may make the car on a remote system, and therefore the cars should be treated as Rcvrs.~~	+
-		+
-	'''carMakerRcvr(name)''' -- a carMaker that may itself be on a remote system, that should only be spoken to with eventual sends. Rather than having a very wordy term for remote Makers that make remote cars (which are local to the Maker), since such a Maker is almost always going to create cars that you must treat as Rcvrs, we use carMakerRcvr to also designate makers that we might be tempted to name "carRcvrMakerRcvr". This name, carMakerRcvr, is a first and only example you will see here of the more generalized naming convention used when constructors and authorizers and rcvrs are interrelated in a complex way. Rather than depending on a prefix that might refer to any chunk of the name, we stack up the descriptions as suffixes. Multiple levels of constructors and [[authorizer]]s play an important role in achieving '''''E''''''s security goals, so while these complicated structures are uncommon in most of the code in a system, there are likely to be a few parts in a secure system where such naming conventions play a role.	+

Ansible: section breakup - wikify

Ansible — Sun, 14 Jan 2007 04:11:50 GMT

section breakup - wikify

←Older revision

Revision as of 04:11, 14 January 2007