Object Orientation as supplicative programming.

How does OO relate to the other fundamental paradigms, imperative (eg procedural) programming, and declarative
eg. logic) programming?
Once you have encapsulateddata, you cannot run imperative commands on it, because the command

would just override the encapsulation. Instead, the object or server

the data is encapsulated receives a message, and acts on it, or not,

or reinterprets it: encapsulation means the encapsulaters of data

have the final say. This is true even in typical RDBMS applications,

where the structure of the data is exposed, but the encapsulater, the

database, can block or modify requests with the trigger mechanism.

Supplication is also the Achilles heel of “OO”: you can’t tell what

a call, or use of code, is doing by inspecting it: the receiver of

the request could do something inappropriate with it. No wonder

the idea of “contract” is important in OO. The client needs guarantees

that its requests will do something like what is expected.

A thought on Android: Why did the user ever have to manage memory?

Why was the responsibility of backing up data ever left to the user? Come to that, why was

it left to the application? The OS assigns and releases memory to the application anyway.

It might as well take snapshots of the apps state as it goes along. Each app then restarts

in its previoius state..indeed, the user hardly has to worry about whether an app is running.

That distinction was only ever a reflection of a hardware distinction, between “core” memrory

and mass storage, and the whole point of an OS is to abstract away such details.

Syntax without Syntax

Some complex object orientated systems amount to building one language
on top of another. For instance, in a PHP framework,
methods on objects need to be called in a particular order. They have
syntax style dependencies of possibility necessity and order. In that
sense they have syntax, but it is not defined as such explicitly. That
is what I mean by syntax without syntax. Virtually all programming languages allow
semantic extension (ie they allow new variables and functions to be defined), and
many support that flexibility with “define” keywords, type systems and the like. But the creation
of new syntax is not so supported: most languages lack constructs that enforce ordering and logical dependencies between newly defined messages and function calls (“call this function before that”).

For instance, a PHP framework might require a page to be initialised, so that there is (in effect) a rule that “The page must be initialised before any other anything else is done with it”).

It could be argued, concretely, that the initialise-first rule
could be implemented by setting some static flag mechanism. It could be argued abstractly that any other language can be implemented in a general-purpose language.(For instance, object orientation can be implemented in pure C, but with a certain amount of programmer disciple, and without convenient syntactic sugar). But we don’t
write everything in assembler! High-level languages are about combining power with safety and convenience. Adding a framework to to something like PHP, python or Ruby adds power, but there is not convenient way of adding safety, the enforcement of the syntactic rules of the higher level language, for all that there are inconvenient ones.

Shell Tips 4: Safe coding by testing exit conditions

How testing works — avoiding unnecessary $?’s
People often want to test whether a command has worked or not, which is a good
thing. You often see code that uses the $? variable, which stores the exit code,
the success or failure, of the most recent instruction.

dosomething
if [ $? -eq 0 ]
then
echo "it worked"
else
echo "it failed"
fi

However, this is somewhat back-to-front. The “if” command’s primary use is to
test for the success or failure of a command. To test an abstract, boolean
function, it has to be evaluated and turned into an exit value, which is what the ‘test’
keyword does (and its equivalent, the square brackets). Therefore the code above can be simpified
into

if dosomething
then
echo "it worked"
else
echo "it failed"
fi

4.2 There is an even more compact way of writing this kind of code (and if you are not writing code this way,
you probably should be, especially if it is to be run by root, or to run unattended).

dosomething && echo "it worked"
dosomething || exit 1

The second form — try something, and quit on fail — is the more useful. It is more useful still if, instead of
quitting just quitting, it calls a function that tidies up, deleting temporary files and so on.

dosomething || my_exit_function


4.3 A particularly useful construct, often seen in well-written scripts is

cd /somewhere | exit

Why? Suppose you have code that says

cd /somewhere
rm -r *

…and suppose /somewhere doesn’t exist. Then the “rm” will remove everything from whatever directory
the script was previously in, which might well be the root directory!

Shell Tips 2: Quote Unquote

There are three different kinds of quote: single quotes, double quote, and backticks. Single quotes

''
are true quotes and suspend all special characters except ‘ itself.

Double quote
"" suspend execution and filename expansion, but shell variables are still expanded.
Illustrating filename expansion:

MyList=*

will put a list of files in the variable $MyList, whereas

MyList="*"

will store an asterisk character in it.
If you just want to quote a common-or-garden string, always use single quotes.
Are double quotes useful? Very! If you double-quote all your variables (except
on the left of an assignment)…

"$LikeThis"

you can avoid a lot of problems.
Double quotes are useful in combination with backticks or or $() operator. The point of this gizmo is to take the
output of a command and turn it into a string. If a command produces output on multiple line, the
formatting gets lost. For instance

OutPut1=$(ls)

will store a list of files all in one line:

echo $OutPut1

produces

aFile anotherFile

whereas

OutPut2="$(ls)"

will maintain the formatting:

echo "$OutPut2"

produces

aFile
anotherFile


Shell tips 5: External programmes are being run non-interactively.

Some external programmes, such as “fsck”
will pause for user input, which means a script suingthem cannot be run unattended. There is a usually
an options (such as “-y” for “yes to everything” to override that behaviour).

Shell Tips 9: Testing $?

There is a built in shell variable $? which
gives the return value — the success or failure –
of the most recently executed command. (Functions and
builtins return such results, although we are usually interested in the
result of an executable).
Don’t do this:

someprocess someargument
if [ $? = 0 ]
then
echo "success"
fi

it can be more concisely written as:

if someprocess someargument
then
echo "success"
fi

Why? Note the lack of square brackets.
The “if” construct was originally designed to detect the
success or failure of a command, and the value for success
is 0. It was extended by the [] construct to do more
general boolean aalgebra, where 0 corresponds to false, and
non-zero to true–the other way round.
So in the first block of code, the command is retrutng
0 meaning success, which is then compared to 0 to turn it
into a boolean true or non-zer0, which is then autiomaticallly
converted back to a 0 by the left angle bracket!

Shell Tips 8: Short Form Empty File Creation

” can be used instead of cat or echo in some shells, e.g to create an empty file

> emptyfile

rather than

echo '' > emptyfile"


Shell Tips 10: The $$ Trick

The $$ temporary file trick. Writing files to /tmp has the disadvantage that it is
shared between all users and processes, leading to possuble clashed, overwrites etc.
$$ is an automatic shell variable containing the ID of the current process. If
a script creats temporary files which have its own name and process ID, the
resulting names will be highly unique. If the script is invoked more than
once, the PIDs will be different and so will the temp file names. This
is true even if it is being run simultaneously by different users or the same user.

Inconstant constants

On Feb 2, 2:49 pm, Ikke wrote:
> Hi everyone,
>
> I was wondering if there was a best practice on using constants outside
> of your code (as in datafiles, or databases). For example, consider the
> following:
>
> A program handles data on persons, using an integer variable to hold the
> gender of the person. Constants have been defined as follows:
>
> ConstGenderUndefined = 0
> ConstGenderMale = 1
> ConstGenderFemale = 2
>
> In source code, 0, 1 or 2 will never be used - that's obviously the
> reason the constants are there in the first place.
>
> However, the data itself (.ini files, table in a database, whatever) will
> of course hold the values 0/1/2.
>
> Suppose we now change the constants, so that the values for male and
> female are switched - all data now becomes invalid, unless we update it
> to the new constant values.
>
> I've been thinking of a solution for a while, but can't come up with
> anything decent or practical.
>
> Does anybody have any suggestions on how to properly handle this
> situation?
>
> Thanks in advance!
>
> Ikke

Version numbering. Wherever you have a multi-part system that lacks inherent strong binding an executable that connects to a database is a common example, it is good to have some way of makng sure they are talking the same language. In the database example, you could have
a columns somewhere with a version number: the executable queries it at start up and
flags some sort of error if it is not what it was expecting. Version numbers can also
be included in messages, DTDs, config files, etc. This doesn’t entirely solve the problem (nothing
else does either), but it is fairly simple and at least allows a class of errors to be readily detected.