Encapsulation, inheritance and polymorphism

[Lipska the Kat]

On 18/07/12 01:46, Andrew Cooper wrote:
> On 17/07/2012 19:36, Lipska the Kat wrote:
>> On 17/07/12 19:18, Mark Lawrence wrote:
>>> On 17/07/2012 18:29, Ethan Furman wrote:
>>>> Terry Reedy wrote:
>>>>> On 7/17/2012 10:23 AM, Lipska the Kat wrote:
>>>>>

snip

>
> Take for example a Linux system call handler.  The general form looks a
> little like (substituting C for python style pseudocode)
>
> if not (you are permitted to do this):
>      return -EPERM
> if not (you've given me some valid data):
>      return -EFAULT
> if not (you've given me some sensible data):
>      return -EINVAL
> return actually_try_to_do_something_with(data)
>
> How would you program this sort of logic with a single return statement?
>   This is very common logic for all routines for which there is even the
> remotest possibility that some data has come from an untrusted source.

Eeek! well if you insist (type bound)

someType -EPERM
someType -EFAULT
sometype -EINVAL
someType -EDOSOMETHING

//method
someType checkSomething(data){

someType result = -EINVAL //or your most likely or 'safest' result

if not (you are permitted to do this):
       result = -EPERM
if not (you've given me some valid data):
       result = -EFAULT
if not (you've given me some sensible data):
       result = -EINVAL
else
       result = -EDSOMETHING
	
       return result
}
//cohesive, encapsulated, reusable and easy to read

//later

if(checkSomething(data) == EDOSOMETHING){

	actually_try_to_do_something_with(data)
}
else{
	//who knows
}

What do you think ?

>
> ~Andrew
>
> P.S. like the sig.

thanks


-- 
Lipska the Kat: Troll hunter, Sandbox destroyer
and Farscape dreamer of Aeryn Sun.