'Talking Objects' Solutions.

one of possible programming paradigms is 'object oriented programming'.

reality is modelled somehow, for example, using graphical notation as Shlaer-Mellor, UML, custom hybrid, etc ...

objects representing something are arranged in a graph data structure.

each of object has set of possible states as well as transitions between these, as well as cause(s) of these transitions.

for example:

in one of possible designs & models of 'reality', more or less 'real' or 'useful' for 'certain problem's solution'.

not every problem must be 'realistic' or 'adhere to common sense', this can be 'abstract problem', 'hypothetical problem', 'philosophical problem', 'mathematical problem', 'theoretical problem', etc ... they are useful nevertheless for certain people that think that way.

we have object: 'Cat' in 'awake' state.

'Cat' in 'awake state' can transit to 'sleeping' or 'walking' state.
'Cat' in 'sleeping' state can transit to 'awake' state.
'Cat' in 'walking state' can transit to 'awake' or 'sleeping state'.

in given state 'Cat' behaves differently, perhaps sending messages to other objects, perhaps doing something 'internal' instead or as well.


this can be modelled using finite state automatons.

perhaps in our 'surreal model of reality' cats can talk with each other by sending messages to other 'Cat' objects, or other 'Animal' objects as well, for example 'Dog' objects.

this is called 'talking objects' system design, modelling, programming, etc ...

sending 'message' from one object to another, often containing 'parameters' or 'value' can cause 'state change' in 'target object'.

for example 'Cat' can send message to 'Dog' with 'value' of 'get lost'.
or for example 'Cat' can send message to 'Dog' with 'value' of 'eat your friends'.

different 'values' can cause different 'state change(s)' in 'target object'.


different solutions use different models for different objects even if their names are the same.

there can be many possible models of 'Cat' each behaving differently, depending of what we wish to model ...

- is it 'Alley Cat Computer Game' ?
- is it 'Cat Hospital' management application ?

in each of these models 'Cat' is seen & modelled differently, has different possible states & state transition methods.

it's a different object.

everything depends on context as well.

see also, if You wish or need ... : Conversation State, Practice, Object Relationships Modelling & Analysis.

see also, if You must: 'Make friends with strange cats' on deviantART.


Request, Response, State, ...

what is request sent to computer?

it's information sent to computer, machine, that often cause certain state changes & reactions.

in certain state machine can fly in proper direction, can shoot or not,

complex state can be observed as well ...

complex state made of many states, simple or complex ... for example : 'state of flight' + 'state of shooting or not' ... etc ...

response information sent to internet web browser as response to request that is effect of mouse click in proper place is also possible, at least theoretically ...



'rotate by 13 places', sometimes hyphenated 'ROT-13' is a simple letter substitution cipher that replaces a letter with the letter 13 letters after it in the alphabet.

ROT13 is a special case of the Caesar cipher, developed in ancient Rome.

i don't guarantee if this image is not erroneous, i didn't have time to check,
... perhaps someday i will ...
... or perhaps someone will do this for us, more or less ...

Source: ROT13 on Wikipedia.


'Rotten Style' on deviantART.


Agile Transformation of Information State.

i think that clean coding & style is important part of code quality matters.

not only comments, proper naming etc ... but also simplicity & efficiency of data structure(s) are important.

combined with proper algorithms they are arguably best way of decreasing costs, as memory or processor-time use, perhaps more ...

i think that 'prettiness' of data structure can also be a sign of programmer's skill, but perhaps just a costly showoff too often ...


'Stitie Space', 3D Objects Matrix data structure, has certain unique 'convenience methods' that allow for a 'fine manipulation of objects' in 'computer memory', a space to be filled with numbers in itself, perhaps ...

these numbers belong to a usual set of {0,1} that is found in 'Computer Sciences' ... any 'number' or 'other data' can be represented with proper amount of these numbers ...

Stitie Space's 'convenience methods' include:
- MATEN functionality,
- Prism functionality,
- Finite State Objects,
- Conditionality & Events,
- Mindful Imaging functionality.
- perhaps more ...

for a potential idea to be considered for future versions, see:
- Space, Transformations & Recursion.

'Ola AH' Programming Language should use Stitie Space, therefore it should also have these 'convenience methods', with an extra of:
- 'AH' mode.

i think that 'state of information' in 'computer memory' can be manipulated that way in a quite simple, elegant & skillful way.

there are costs however, when compared to low-level programming mechanisms, for example ...

there are also benefits, perhaps, as well ...


Stitie Machine 1.1 'Sunsail' & Stitie Space should be part of 'Ola AH' Programming Language's semantics.


for Idioms, click if You wish or need, ... :

- MATEN, then Prism(s), an Idiom,
- Imaging Space in another Space, an Idiom,
- Petri Nets & Randezvous Concurrency, an Idiom,
- Strategy Execution Gate, an Idiom.

'MATEN' & 'Prism' functionalities will probably be replaced with other names in 'Ola AH' Programming Language.

for example:

   perhaps more ...

or using different, fairly terse syntax (notation), for example:

   int size = 108;

   // creating Stitie Space named mySpace1 with a proper size.
   create space mySpace1(size);

   // there can be default space size, probably of 1080 machines.
   create space mySpace2();

   // adding a form named myForm1 to Stitie Space named mySpace1.
   mySpace1 addf myForm1;

   // invoking a form named myForm1 in Stitie Space named mySpace1.
   mySpace1 ! myForm1;

   // prism named pt, with use of a coords tuple, in Stitie Space named mySpace1.
   // a tuple can be of a different size than just a 3-element tuple.
   mySpace1 -> pt, (coords1, coords2, coords3);

   // setting imager named myImager in Stitie Space named mySpace1.
   mySpace1 addi myImager;

   // perhaps more ...