text:
Ada Programming/Object Orientation

Object orientation in Ada
Object oriented programming consists in building the software in terms of "objects". An "object" contains data and has a behavior. The data, normally, consists in constants and variables as seen in the rest of this book but could also, conceivably, reside outside the program entirely, i.e. on disk or on the network. The behavior consists in subprograms that operate on the data. What makes Object Orientation unique, compared to procedural programming, is not a single feature but the combination of several features:

 * encapsulation, i.e. the ability to separate the implementation of an object from its interface; this in turn separates "clients" of the object, who can only use the object in certain predefined ways, from the internals of the object, which have no knowledge of the outside clients.

 * inheritance, the ability for one type of objects to inherit the data and behavior (subprograms) of another, without necessarily needing to break encapsulation;

 * type extension, the ability for an object to add new data components and new subprograms on top of the inherited ones and to replace some inherited subprograms with its own versions; this is called overriding.

 * polymorphism, the ability for a "client" to use the services of an object without knowing the exact type of the object, i.e. in an abstract way. Indeed at run time, the actual objects can have different types from one invocation to the next.

It is possible to do object-oriented programming in any language, even assembly. However, type extension and polymorphism are very difficult to get right without language support.

In Ada, each of these concepts has a matching construct; this is why Ada supports object-oriented programming directly.

 * Packages provide encapsulation;
 * Derived types provide inheritance;
 * Record extensions, described below, provide for type extension;
 * Class-wide types, also described below, provide for polymorphism.

Ada has had encapsulation and derived types since the first version (MIL-STD-1815 in 1980), which led some to qualify the language as "object-oriented" in a very narrow sense. Record extensions and class-wide types were added in Ada 95. Ada 2005 further adds interfaces. The rest of this chapter covers these aspects.

The simplest object: the Singleton
Directory Present (Name_Pattern: String) Boolean; Visit (Full_Name, Phone_Number, Address: String;                           Stop:  Boolean); Iterate (Name_Pattern: String); Directory;

The Directory is an object consisting of data (the telephone numbers and addresses, presumably held in an external file or database) and behavior (it can look an entry up and traverse all the entries matching a Name_Pattern, calling Visit on each).

A simple package provides for encapsulation (the inner workings of the directory are hidden) and a pair of subprograms provide the behavior.

This pattern is appropriate when only one object of a certain type must exist; there is, therefore, no need for type extension or polymorphism.

Primitive operations
In Ada, methods are usually referred to by the technical term primitive subprograms of a tagged type or the equivalent term primitive operations of a tagged type. The primitive operations of a type are those that are always available wherever the type is used. For the tagged types that are used in object oriented programming, they also can be inherited by and overridden by derived types, and can be dynamically dispatched.

Primitive operations of a type need to be declared immediately within the same package as the type (not within a nested package nor a child package). For tagged types, new primitive operations and overrides of inherited primitive operations are further required to be declared before the freezing point of the type. Any subprograms declared after the freezing point will not be considered primitive, and therefore cannot be inherited and are not dynamically dispatched. Freezing points are discussed in more detail below, but the simple practice of declaring all primitive operations immediately following the initial type declaration will ensure that those subprograms are indeed recognized as primitive.

Primitive operations of type T need to have at least one parameter of type  or of type. While most object-oriented languages automatically provide a  or   pointer, Ada requires that you explicitly declare a formal parameter to receive the current object. That typically will be the first parameter in the list, which enables the  call syntax (available since Ada 2005), but it may be at any parameter position. Tagged types are always passed by reference; the parameter passing method has nothing to do with the parameter modes  and , which describe the dataflow. The parameter passing method is identical for  and.

For tagged types, no other directly dispatchable types can be used in the parameter list because Ada doesn't offer multiple dispatching. The following example is illegal.

P     A   ; B  ; Proc (This: B; That: A); P;

When additional dispatchable objects need to be passed in, the parameter list should declare them using their class-wide types,. For example:

P     A   ; B  ; Proc (This: B; That: A'Class); P;

Note, however, that this does not limit the number of parameters of the same tagged type. For example, the following definition is legal.

P     A   ; Proc (This, That: A); P;

Primitive operations of tagged types are dispatching operations. Whether a call to such a primitive operation is in effect dispatching or statically bound, depends on the context (see below). Note that in a dispatching call both actual parameters of the last example must have the same tag (i.e. the same type); Constraint_Error will be called if the tag check fails.

Derived types
Type derivation has been part of Ada since the very start.

P    T ; Create (Data: Boolean) T;      Work (Object :  T); Work (Pointer: T); Acc_T T;    Proc (Pointer: Acc_T); T     Data: Boolean; ; P;

The above example creates a type T that contains data (here just a Boolean but it could be anything) and behavior consisting of some subprograms. It also demonstrates encapsulation by placing the details of the type T in the private part of the package.

The primitive operations of T are the function Create, the overloaded procedures Work, and the predefined "=" operator; Proc is not primitive, since it has an access type on T as parameter — don't confuse this with an access parameter, as used in the second procedure Work. When deriving from T, the primitive operations are inherited.

P; Q     Derived  P.T;  Q;

The type Q.Derived has the same data and the same behavior as P.T; it inherits both the data and the subprograms. Thus it is possible to write:

Q; Main Object: Q.Derived := Q.Create (Data => False); Q.Work (Object); Main;

Inherited operations may be overridden and new operations added, but the rules (Ada 83) unfortunaltely are somewhat different from the rules for tagged types (Ada 95).

Admittedly, the reasons for writing this may seem obscure. The purpose of this kind of code is to have objects of types P.T and Q.Derived, which are not compatible:

Ob1: P.T; Ob2: Q.Derived;

Ob1 := Ob2;             -- illegal Ob1 := P.T (Ob2);       -- but convertible Ob2 := Q.Derived (Ob1); -- in both directions

This feature is not used very often (it's used e.g. for declaring types reflecting physical dimensions) but I present it here to introduce the next step: type extension.

Type extensions
Type extensions are an Ada 95 amendment.

A tagged type provides support for dynamic polymorphism and type extension. A tagged type bears a hidden tag that identifies the type at run-time. Apart from the tag, a tagged record is like any other record, so it can contain arbitrary data.

Person Object Name  : String (1 .. 10); Gender : Gender_Type; ;    Put (O : Object); Person;

As you can see, a  is an object in the sense that it has data and behavior (the procedure  ). However, this object does not hide its data; any program unit that has a  clause can read and write the data in a Person.Object directly. This breaks encapsulation and also illustrates that Ada completely separates the concepts of encapsulation and type. Here is a version of Person.Object that encapsulates its data:

Person Object ; Put (O : Object); Object Name  : String (1 .. 10); Gender : Gender_Type; ; Person;

Because the type Person.Object is tagged, it is possible to create a record extension, which is a derived type with additional data.

Person; Programmer Object  Person.Object ; Object  Person.Object Skilled_In : Language_List; ; Programmer;

The type  inherits the data and behavior, i.e. the type's primitive operations, from  ; it is thus possible to write:

Programmer; Main Me : Programmer.Object; Programmer.Put (Me); Me.Put; Main;

So the declaration of the type, as a record extension of  , implicitly declares a   that applies to a.

Like in the case of untagged types, objects of type Person and Programmer are convertible. However, where untagged objects are convertible in either direction, conversion of tagged types only works in the direction to the root. (Conversion away from the root would have to add components out of the blue.) Such a conversion is called a view conversion, because components are not lost, they only become invisible.

Extension aggregates have to be used if you go away from the root.

Overriding
Now that we have introduced tagged types, record extensions and primitive operations, it becomes possible to understand overriding. In the examples above, we introduced a type  with a primitive operation called. Here is the body of the package:

Ada.Text_IO; Person Put (O : Object) Ada.Text_IO.Put (O.Name); Ada.Text_IO.Put (" is a "); Ada.Text_IO.Put_Line (Gender_Type'Image (O.Gender)); Put; Person;

As you can see, this simple operation prints both data components of the record type to standard output. Now, remember that the record extension  has an additional data member. If we write:

Programmer; Main Me : Programmer.Object; Programmer.Put (Me); Me.Put; Main;

then the program will call the inherited primitive operation, which will print the name and gender but not the additional data. In order to provide this extra behavior, we must override the inherited procedure  like this:

Person; Programmer Object  Person.Object ; Put (O : Object); Object  Person.Object Skilled_In : Language_List; ; Programmer;

Programmer Put (O : Object) Person.Put (Person.Object (O)); Put (O.Skilled_In); Put; Programmer;

overrides ; in other words it replaces it completely. Since the intent is to extend the behavior rather than replace it,  calls   as part of its behavior. It does this by converting its parameter from the type  to its ancestor type. This construct is a view conversion; contrary to a normal type conversion, it does not create a new object and does not incur any run-time cost (and indeed, if the operand of such view conversion was actually a variable, the result can be used when an out parameter is required (eg. procedure call)). Of course, it is optional that an overriding operation call its ancestor; there are cases where the intent is indeed to replace, not extend, the inherited behavior.

(Note that also for untagged types, overriding of inherited operations is possible. The reason why it's discussed here is that derivation of untagged types is done rather seldom.)

Polymorphism, class-wide programming and dynamic dispatching
The full power of object orientation is realized by polymorphism, class-wide programming and dynamic dispatching, which are different words for the same, single concept. To explain this concept, let us extend the example from the previous sections, where we declared a base tagged type  with a primitive operation   and a record extension   with additional data and an overriding primitive operation.

Now, let us imagine a collection of persons. In the collection, some of the persons are programmers. We want to traverse the collection and call  on each person. When the person under consideration is a programmer, we want to call ; when the person is not a programmer, we want to call. This, in essence, is polymorphism, class-wide programming and dynamic dispatching.

With Ada's strong typing, ordinary calls cannot be dynamically dispatched; a call to an operation on a declared type must always be statically bound to go to the operation defined for that specific type. Dynamic dispatching (known as simply dispatching in Ada parlance) is provided through separate class-wide types that are polymorphic. Each tagged type, such as, has a corresponding class of types which is the set of types comprising the type   itself and all types that extend. In our example, this class consists of two types:

Ada 95 defines the  attribute to denote the corresponding class-wide type. In other words:

Someone : Person.Object'Class := ...; Someone.Put; ;

The declaration of Someone denotes an object that may be of either type,  or. Consequently, the call to the primitive operation  dispatches dynamically to either   or.

The only problem is that, since we don't know whether Someone is a programmer or not, we don't know how many data components Someone has, either, and therefore we don't know how many bytes Someone takes in memory. For this reason, the class-wide type  is indefinite. It is impossible to declare an object of this type without giving some constraint. It is, however, possible to:

 * declare an object of a class-wide with an initial value (as above). The object is then constrained by its initial value.
 * declare an access value to such an object (because the access value has a known size);
 * pass objects of a class-wide type as parameters to subprograms
 * assign an object of a specific type (in particular, the result of a function call) to a variable of a class-wide type.

With this knowledge, we can now build a polymorphic collection of persons; in this example we will quite simply create an array of access values to persons:

Person; Main Person_Access Person.Object'Class; Array_Of_Persons  (Positive  <>) of Person_Access; Read_From_Disk Array_Of_Persons ; Everyone : Array_Of_Persons := Read_From_Disk; K Everyone'Range Everyone (K)..Put; ; Main;

The above procedure achieves our desired goal: it traverses the array of Persons and calls the procedure  that is appropriate for each person.

Advanced topic: How dynamic dispatching works
You don't need to know how dynamic dispatching works in order to use it effectively but, in case you are curious, here is an explanation.

The first component of each object in memory is the tag; this is why objects are of a tagged type rather than plain records. The tag really is an access value to a table; there is one table for each specific type. The table contains access values to each primitive operation of the type. In our example, since there are two types  and , there are two tables, each containing a single access value. The table for  contains an access value to   and the table for   contains an access value to. When you compile your program, the compiler constructs both tables and places them in the program executable code.

Each time the program creates a new object of a specific type, it automatically sets its tag to point to the appropriate table.

Each time the program performs a dispatching call of a primitive operation, the compiler inserts object code that:

 * dereferences the tag to find the table of primitive operations for the specific type of the object at hand
 * dereferences the access value to the primitive operation
 * calls the primitive operation.

Conversely, when the program performs a call where the parameter is a view conversion to an ancestor type, the compiler performs these two dereferences at compile time rather than run time: such a call is statically bound; the compiler emits code that directly calls the primitive operation of the ancestor type specified in the view conversion.

Redispatching
Dispatching is controlled by the (hidden) tag of the object. So what happens when a primitive operation  calls another primitive operation   on the same object?

Root  ; Op1 (This: Root); Op2 (This: Root); Derived  Root  ; -- Derived inherits Op1 Op2 (This: Derived); Op1 (This: Root) ...   Op2 (This);               -- not redispatching Op2 (Root'Class (This)); -- redispatching This.Op2;                -- not redispatching (new syntax since Ada 2005) (Root'Class (This)).Op2; -- redispatching (new syntax since Ada 2005) ...  Op1; D: Derived; C: Root'Class := D; Op1 (D);  -- statically bound call Op1 (C); -- dispatching call D.Op1;   -- statically bound call (new syntax since Ada 2005) C.Op1;   -- dispatching call (new syntax since Ada 2005)

In this fragment,  is not overridden, whereas   is overridden. The body of  calls , so which   will be called if   is called for an object of type  ?

The basic rules of dispatching still apply. Calls to  will be dispatched when called using an object of a class-wide type.

The formal parameter lists for the operations specify the type of  to be a specific type, not class-wide. In fact, that parameter must be a specific type so that the operation will be dispatched for objects of that type, and to allow the operation's code to access any additional data items associated with that type. If you want redispatching, you must state that explicitly by converting the parameter of the specific type to the class-wide type again. (Remember: view conversions never lose components, they just hide them. A conversion to a class-wide type can unhide them again.) The first call  (statically bound, i.e., not dispatching) executes the inherited   — and within , the first call to   is also statically bound (there is no redispatching) because parameter   is a view conversion to specific type. However, the second call is dispatching because the parameter  is converted to the class-wide type. That call dispatches to the overriding.

Because the conventional  call is not dispatching, the call will be to   even though the object itself is of type   and the   operation is overridden. This is very different from how other OO languages behave. In other OO languages, a method is either dispatching or not. In Ada, an operation is either available for dispatching or not. Whether or not dispatching is actually used for a given call depends on the way that the object's type is specified at that call point. For programmers accustomed to other OO languages, it can come as quite a surprise that calls from a dispatchable operation to other operations on the same object are, by default, not (dynamically) dispatched.

The default of not redispatching is not an issue if all of the operations have been overridden, because they all will be operating on the expected type of object. However, it has ramifications when writing code for types that might be extended by another type sometime in the future. It's possible that the new type will not work as intended if it doesn't override all of the primitive operations that call other primitive operations. The safest policy is to use a class-wide conversion of the object to force dispatching of calls. One way to accomplish that is to define a class-wide constant in each dispatched method:

Op2 (This: Derived) This_Class: Root'Class := This;

is needed to access data items and to make any non-dispatching calls. is needed to make dispatching calls.

Less commonly encountered and perhaps less surprising, calls from a non-dispatchable (class-wide) routine for a tagged type to other routines on the same object are, by default, dispatched:

Root  ; Op1 (This: Root'Class); Op2 (This: Root); Derived  Root  ; -- Derived does not inherit Op1, rather Op1 is applicable to Derived. Op2 (This: Derived); Op1 (This: Root'Class) ...   Op2 (This);               -- dispatching Op2 (Root (This));       -- static call This.Op2;                -- dispatching (new syntax since Ada 2005) (Root (This)).Op2;       -- static call (new syntax since Ada 2005) ...  Op1; D: Derived; C: Root'Class := D; Op1 (D);  -- static call Op1 (C); -- static call D.Op1;   -- static call (new syntax since Ada 2005) C.Op1;   -- static call (new syntax since Ada 2005)

Note that calls on  are always static, since   is not inherited. Its parameter type is class-wide, so the operation is applicable to all types derived from Root. (Op2 has an entry for each type derived from  in the dispatch table. There is no such dispatch table for  ; rather there is only one such operation for all types in the class.)

Normal calls from  are dispatched because the declared type of   is class-wide. The default to dispatching usually isn't bothersome because class-wide operations are typically used to perform a script involving calls to one or more dispatched operations.

Run-time type identification
Run-time type identification allows the program to (indirectly or directly) query the tag of an object at run time to determine which type the object belongs to. This feature, obviously, makes sense only in the context of polymorphism and dynamic dispatching, so works only on tagged types.

You can determine whether an object belongs to a certain class of types, or to a specific type, by means of the membership test, like this:

Base     ; Derived  Base     ; Leaf     Derived  ; ... Explicit_Dispatch (This :  Base'Class) This Leaf  ... ;    This  Derived'Class  ... ; Explicit_Dispatch;

Thanks to the strong typing rules of Ada, run-time type identification is in fact rarely needed; the distinction between class-wide and specific types usually allows the programmer to ensure objects are of the appropriate type without resorting to this feature.

Additionally, the reference manual defines  (RM 3.9(6/2)), attribute   (RM 3.9(16,18)), and   (RM 3.9(18.2/2)), which enable direct manipulation with tags.

Creating Objects
The Language Reference Manual's section on states when an object is created, and destroyed again. This subsection illustrates how objects are created.

The LRM section starts, "Objects are created at run time and contain a value of a given type. An object can be created and initialized as part of elaborating a declaration, evaluating an allocator, aggregate, or function_call."

For example, assume a typical hierarchy of object oriented types: a top-level type , a  type derived from  , and possibly more kinds of persons. Each person has a name; assume objects to have a  component. Likewise, each  has a   component. The  type inherits the components and the operations of the  type, so   objects have a  and a   component, too. objects may have additional components specific to programmers.

Objects of a tagged type are created the same way as objects of any type. The second LRM sentence says, for example, that an object will be created when you declare a variable or a constant of a type. For the tagged type ,

P Person Text_IOPut_Line"The name is " PName

Nothing special so far. Just like any ordinary variable declaration this O-O one is elaborated. The result of elaboration is an object named of type. However,  has only default name and gender value components. These are likely not useful ones. One way of giving initial values to the object's components is to assign an aggregate.

P Person Name  "Scorsese" Gender  Male Text_IOPut_Line"The name is " PName

The parenthesized expression after := is called an aggregate .

Another way to create an object that is mentioned in the LRM paragraph is to call a function. An object will be created as the return value of a function call. Therefore, instead of using an aggregate of initial values, we might call a function returning an object.

Introducing proper O-O information hiding, we change the package containing the  type so that becomes a private type. To enable clients of the package to construct objects we declare a function that returns them. (The function may do some interesting construction work on the objects. For instance, the aggregate above will most probably raise the exception Constraint_Error depending on the name string supplied; the function can mangle the name so that it matches the declaration of the component.) We also declare a function that returns the name of  objects.

Persons Person Make Name String Sex Gender_Type Person Name P Person String Person Name   String 1  10 Gender Gender_Type Persons

Calling the  function results in an object which can be used for initialization. Since the  type is private we can no longer refer to the component of. But there is a corresponding function  declared with type  making it a socalled primitive operation. (The component and the function in this example are both named However, we can choose a different name for either if we want.)

P Person Make Name  "Orwell" Sex  Male Text_IOPut_Line"The name is " NameP

Objects can be copied into another. The target object is first destroyed. Then the component values of the source object are assigned to the corresponding components of the target object. In the following example, the default initialized  gets a copy of one of the objects created by the  calls.

P Person 2001 1984        P  Make Name  "Kubrick" Sex  Male P Make Name  "Orwell" Sex  Male Text_IOPut_Line"The name is " NameP

So far, there is no mention of the  type derived from. There is no polymorphism yet, and likewise initialization does not yet mention inheritance. Before dealing with  objects and their initialization a few words about class-wide types are in order.

More details on primitive operations
Remember what we said before about "Primitive Operations". Primitive operations are:
 * subprograms taking a parameter of the tagged type;
 * functions returning an object of the tagged type;
 * subprograms taking a parameter of an anonymous access type to the tagged type;
 * In Ada 2005 only, functions returning an anonymous access type to the tagged type;

Additionally, primitive operations must be declared before the type is frozen (the concept of freezing will be explained later):

Examples:

X     Object    ; Primitive_1 (This :     Object); Primitive_2 (That :    Object); Primitive_3 (Me  :   Object); Primitive_4 (Them : Object); Primitive_5 Object; Primitive_6 (Everyone : Boolean)  Object; X;

All of these subprograms are primitive operations.

A primitive operation can also take parameters of the same or other types; also, the controlling operand does not have to be the first parameter:

X     Object    ; Primitive_1 (This : Object; Number :  Integer); Primitive_2 (You :  Boolean; That :  Object); Primitive_3 (Me, Her :  Object); X;

The definition of primitive operations specifically excludes named access types and class-wide types as well as operations not defined immediately in the same declarative region. Counter-examples:

X     Object    ; Object_Access  Object; Object_Class_Access  Object'Class; Not_Primitive_1 (This :     Object'Class); Not_Primitive_2 (This :  Object_Access); Not_Primitive_3 (This :    Object_Class_Access); Not_Primitive_4 Object'Class; Inner Not_Primitive_5 (This : Object); Inner; X;

Advanced topic: Freezing rules
Freezing rules (ARM 13.14) are perhaps the most complex part of the Ada language definition; this is because the standard tries to describe freezing as unambiguously as possible. Also, that part of the language definition deals with freezing of all entities, including complicated situations like generics and objects reached by dereferencing access values. You can, however, get an intuitive understanding of freezing of tagged types if you understand how dynamic dispatching works. In that section, we saw that the compiler emits a table of primitive operations for each tagged type. The point in the program text where this happens is the point where the tagged type is frozen, i.e. the point where the table becomes complete. After the type is frozen, no more primitive operations can be added to it.

This point is the earliest of:
 * the end of the package spec where the tagged type is declared
 * the appearance of the first type derived from the tagged type

Example:

X    Object    ; Primitive_1 (This: Object); -- this declaration freezes Object Derived  Object   ; -- illegal: declared after Object is frozen Primitive_2 (This: Object); X;

Intuitively: at the point where Derived is declared, the compiler starts a new table of primitive operations for the derived type. This new table, initially, is equal to the table of the primitive operations of the parent type,. Hence,  must freeze.

 * the declaration of a variable of the tagged type

Example:

X    Object    ; Primitive_1 (This: Object); V: Object; -- this declaration freezes Object -- illegal: Primitive operation declared after Object is frozen Primitive_2 (This: Object); X;

Intuitively: after the declaration of, it is possible to call any of the primitive operations of the type on. Therefore, the list of primitive operations must be known and complete, i.e. frozen.

 * The completion (not the declaration, if any) of a constant of the tagged type:

X    Object    ; Primitive_1 (This: Object); -- this declaration does NOT freeze Object Deferred_Constant: Object; Primitive_2 (This : Object); -- OK   -- only the completion freezes Object Deferred_Constant: Object := ; -- illegal: declared after Object is frozen Primitive_3 (This: Object); X;

New features of Ada 2005
Ada 2005 adds overriding indicators, allows anonymous access types in more places and offers the object.method notation.

Overriding indicators
The new keyword can be used to indicate whether an operation overrides an inherited subprogram or not. Its use is optional because of upward-compatibility with Ada 95. For example:

X      Object    ; Primitive  Object; Derived_Object  Object   ; Primitive (This : Derived_Object); Primitive Derived_Object; X;

The compiler will check the desired behaviour.

This is a good programming practice because it avoids some nasty bugs like not overriding an inherited subprogram because the programmer spelt the identifier incorrectly, or because a new parameter is added later in the parent type.

It can also be used with abstract operations, with renamings, or when instantiating a generic subprogram:

Primitive_X (This : Object)  ; Primitive_Y Object  Some_Other_Subprogram; Primitive_Z (This : Object) Generic_Procedure (Element => Integer);

Object.Method notation
We have already seen this notation:

X     Object    ; Primitive (This: Object; That:  Boolean); X;

X; Main Obj : X.Object; Obj.Primitive (That => True); Main;

This notation is only available for primitive operations where the controlling parameter is the first parameter.

Abstract types
A tagged type can also be abstract (and thus can have abstract operations):

X     Object    …; One_Class_Member     (This :      Object); Another_Class_Member (This :   Object); Abstract_Class_Member Object   ; X;

An abstract operation cannot have any body, so derived types are forced to override it (unless those derived types are also abstract). See next section about interfaces for more information about this.

The difference with a non-abstract tagged type is that you cannot declare any variable of this type. However, you can declare an access to it, and use it as a parameter of a class-wide operation.

Multiple Inheritance via Interfaces
Interfaces allow for a limited form of multiple inheritance (taken from Java). On a semantic level they are similar to an "abstract tagged null record" as they may have primitive operations but cannot hold any data and thus these operations cannot have a body, they are either declared or. Abstract means the operation has to be overridden, null means the default implementation is a null body, i.e. one that does nothing.

An interface is declared with:

Printable Object ; Class_Member_1 (This :     Object)  ; Class_Member_2 (This :    Object)  ; Printable;

You implement an by adding it to a concrete class:

Person; Programmer Object  Person.Object Printable.Object Skilled_In : Language_List; ;    Class_Member_1   (This :  Object); New_Class_Member (This : Object; That : String); Programmer;

As usual, all inherited abstract operations must be overridden although null subprograms ones need not.

Such a type may implement a list of interfaces (called the progenitors), but can have only one parent. The parent may be a concrete type or also an interface.

Derived  Parent  Progenitor_1  Progenitor_2 ... ...;

Multiple Inheritance via Mix-in
Ada supports multiple inheritance of interfaces (see above), but only single inheritance of implementation. This means that a tagged type can implement multiple interfaces but can only extend a single ancestor tagged type.

This can be problematic if you want to add behavior to a type that already extends another type; for example, suppose you have

Base ; Derived Base ;

and you want to make  controlled, i.e. add the behavior that   controls its initialization, assignment and finalization. Alas you cannot write:

Derived Base  .Controlled ;

since  for historical reasons does not define interfaces   and , but abstract types.

If your base type is not limited, there is no good solution for this; you have to go back to the root of the class and make it controlled. (The reason will become obvious presently.)

For limited types however, another solutions is the use of a mix-in:

Base ; Derived; Controlled_Mix_In (Enclosing: Derived) .Limited_Controlled ; Initialize (This: Controlled_Mix_In); Finalize  (This:  Controlled_Mix_In); Derived Base Mix_In: Controlled_Mix_In (Enclosing => Derived'Access); ;

This special kind of mix-in is an object with an access discriminant that references its enclosing object (also known as Rosen trick). In the declaration of the  type, we initialize this discriminant with a special syntax:   really refers to an access value to the current instance of type. Thus the access discriminant allows the mix-in to see its enclosing object and all its components; therefore it can initialize and finalize its enclosing object:

Initialize (This: Controlled_Mix_In) Enclosing: Derived This.Enclosing.; Initialize;

and similarly for.

The reason why this does not work for non-limited types is the self-referentiality via the discriminant. Imagine you have two variables of such a non-limited type and assign one to the other:

X := Y;

In an assignment statement,  is called only after   of the target   and so cannot provide the new value of the discriminant. Thus  will inevitably reference.

Now let's further extend our hierarchy:

Further Derived ; Initialize (This: Further); Finalize  (This:  Further);

Oops, this does not work because there are no corresponding procedures for, yet – so let's quickly add them.

Base ; Derived; Controlled_Mix_In (Enclosing: Derived) .Limited_Controlled ; Initialize (This: Controlled_Mix_In); Finalize  (This:  Controlled_Mix_In); Derived Base Mix_In: Controlled_Mix_In (Enclosing => Derived'Access); ; Initialize (This:  Derived); Finalize  (This:  Derived); Further Derived ;

Initialize (This: Further); Finalize  (This:  Further);

We have of course to write  for the procedures on   because there is indeed nothing they could override. The bodies are

Initialize (This: Derived) Initialize;

Initialize (This: Controlled_Mix_In) Enclosing: Derived This.Enclosing.; Initialize (Enclosing); Initialize;

To our dismay, we have to learn that  for objects of type   will not be called, instead those for the parent. Why?

X: Further; -- Initialize (Derived (X)) is called here ; ; -- Finalize (Derived (X)) is called here

The reason is that the mix-in defines the local object  to be of type   in the renames-statement above. To cure this, we have necessarily to use the dreaded redispatch (shown in different but equivalent notations):

Initialize (This: Controlled_Mix_In) Enclosing: Derived This.Enclosing.; Initialize (Derived'Class (Enclosing)); Initialize;

Finalize (This: Controlled_Mix_In) Enclosing: Derived'Class Derived'Class (This.Enclosing.); Enclosing.Finalize; Finalize;

X: Further; -- Initialize (X) is called here ; ; -- Finalize (X) is called here

Alternatively (and presumably better still) is to write

Controlled_Mix_In (Enclosing: Derived'Class) .Limited_Controlled ;

Then we automatically get redispatch and can omit the type conversions on.

Class names
Both the class package and the class record need a name. In theory they may have the same name, but in practice this leads to nasty (because of unintuitive error messages) name clashes when you use the  clause. So over time three de facto naming standards have been commonly used.

Classes/Class
The package is named by a plural noun and the record is named by the corresponding singular form.

Persons Person Name  : String (1 .. 10); Gender : Gender_Type; ; Persons;

This convention is the usually used in Ada's built-in libraries.

Disadvantage: Some "multiples" are tricky to spell, especially for those of us who aren't native English speakers.

Class/Object
The package is named after the class, the record is just named Object.

Person Object Name  : String (1 .. 10); Gender : Gender_Type; ; Person;

Most UML and IDL code generators use this technique.

Disadvantage: You can't use the  clause on more than one such class packages at any one time. However you can always use the "type" instead of the package.

Class/Class_Type
The package is named after the class, the record is postfixed with _Type.

Person Person_Type Name  : String (1 .. 10); Gender : Gender_Type; ; Person;

Disadvantage: lots of ugly "_Type" postfixes.

Object-Oriented Ada for C++ programmers
In C++, the construct is strictly equivalent to the following in Ada:

P    C ; V (This : C); W (This : C'Class); U; P;

In C++, member functions implicitly take a parameter  which is of type. In Ada, all parameters are explicit. As a consequence, the fact that  does not take a parameter is implicit in C++ but explicit in Ada.

In C++,  is a pointer. In Ada, the explicit  parameter does not have to be a pointer; all parameters of a tagged type are implicitly passed by reference anyway.

Static dispatching
In C++, function calls dispatch statically in the following cases:

 * the target of the call is an object type
 * the member function is non-virtual

For example: both dispatch statically. In particular, the static dispatch for v may be confusing; this is because object is neither a pointer nor a reference. Ada behaves exactly the same in this respect, except that Ada calls this static binding rather than dispatching:

Object : P.C;   Object.V;     Object.W;  ;

Dynamic dispatching
In C++, a function call dispatches dynamically if the two following conditions are met simultaneously:

 * the target of the call is a pointer or a reference
 * the member function is virtual.

For example: In Ada, a primitive subprogram call dispatches (dynamically) if and only if:

 * the target object is of a class-wide type;

Note: In Ada vernacular, the term dispatching always means dynamic.

For example:

Object : P.C'Class := ...; P.V (Object); P.W (Object); P.U; ;

As can be seen there is no need for access types or pointers to do dispatching in Ada. In Ada, tagged types are always passed by-reference to subprograms without the need for explicit access values.

Also note that in C++, the class serves as:

 * the unit of encapsulation (Ada uses packages and visibility for this)
 * the type, like in Ada.

As a consequence, you call C::u in C++ because u is encapsulated in C, but P.U in Ada since U is encapsulated in the package P, not the type C.

Class-wide and specific types
The most confusing part for C++ programmers is the concept of a "class-wide type". To help you understand:

 * pointers and references in C++ are really, implicitly, class-wide;
 * object types in C++ are really specific;
 * C++ provides no way to declare the equivalent of:

C_Specific_Access C;

 * C++ provides no way to declare the equivalent of:

C_Specific_Access_One C;  C_Specific_Access_Two  C;

which, in Ada, are two different, incompatible types, possibly allocating their memory from different storage pools!

 * In Ada, you do not need access values for dynamic dispatching.
 * In Ada, you use access values for dynamic memory management (only) and class-wide types for dynamic dispatching (only).
 * In C++, you use pointers and references both for dynamic memory management and for dynamic dispatching.
 * In Ada, class-wide types are explicit (with ).
 * In C++, class-wide types are implicit (with  or  ).

Constructors
in C++, a special syntax declares a constructor: A constructor cannot be virtual. A class can have as many constructors, differentiated by their parameters, as necessary.

Ada does not have such constructors. Perhaps they were not deemed necessary since in Ada, any function that returns an object of the tagged type can serve as a kind of constructor. This is however not the same as a real constructor like the C++ one; this difference is most striking in cases of derivation trees (see Finalization below). The Ada constructor subprograms do not have to have a special name and there can be as many constructors as necessary; each function can take parameters as appropriate.

P    T is  ; Make                 T;  -- constructor To_T (From: Integer) T;  -- another constructor Make (This: T);            -- not a constructor ... P;

If an Ada constructor function is also a primitive operation (as in the example above), it becomes abstract upon derivation and has to be overridden if the derived type is not itself abstract. If you do not want this, declare such functions in a nested scope.

In C++, one idiom is the copy constructor and its cousin the assignment operator: This copy constructor is invoked implicitly on initialization, e.g. Ada provides a similar functionality by means of controlled types. A controlled type is one that extends the predefined type :

; P     T   .Controlled  ; Make T;  -- constructor T ... ;    Initialize (This:   T); Adjust    (This:   T); -- copy constructor P;

Note that Initialize is not a constructor; it resembles the C++ constructor in some way, but is also very different. Suppose you have a type T1 derived from T with an appropriate overriding of Initialize. A real constructor (like the C++ one) would automatically first construct the parent components (T), then the child components. In Ada, this is not automatic. In order to mimic this in Ada, we have to write:

Initialize (This:  T1) Initialize (T (This)); -- Don't forget this part! ... -- handle the new components here Initialize;

The compiler inserts a call to Initialize after each object of type T is allocated when no initial value is given. It also inserts a call to Adjust after each assignment to the object. Thus, the declarations:

A: T; B: T := X;

will:

 * allocate memory for A
 * call Initialize (A)
 * allocate memory for B
 * copy the contents of X to B
 * call Adjust (B)

Initialize (B) will not be called because of the explicit initialization.

So, the equivalent of a copy constructor is an overriding of Adjust.

If you would like to provide this functionality to a type that extends another, non-controlled type, see "Multiple Inheritance".

Destructors
In C++, a destructor is a member function with only the implicit  parameter: While a constructor cannot be virtual, a destructor must be virtual if the class is to be used with dynamic dispatch (has virtual methods or derives from a class with virtual methods). C++ classes do not use dynamic dispatch by default, so it can catch some programmers out and wreak havoc in their programs by simply forgetting the keyword.

In Ada, the equivalent functionality is again provided by controlled types, by overriding the procedure Finalize:

; P      T   .Controlled  ; Make T;  -- constructor T ... ;     Finalize (This:   T);  -- destructor P;

Because Finalize is a primitive operation, it is automatically "virtual"; you cannot, in Ada, forget to make a destructor virtual.

Encapsulation: public, private and protected members
In C++, the unit of encapsulation is the class; in Ada, the unit of encapsulation is the package. This has consequences on how an Ada programmer places the various components of an object type. A way to mimic this C++ class in Ada is to define a hierarchy of types, where the base type is the public part, which must be abstract so that no stand-alone objects of this base type can be defined. It looks like so:

; CPP Public_Part     -- no objects of this type A: Integer; ;   Public_Proc (This:   Public_Part); Complete_Type  Public_Part  ; -- procedure Public_Proc (This: in out Complete_Type); -- inherited, implicitly defined -- visible for children Private_Part; -- declaration stub Private_Part_Pointer  Private_Part; Private_Component  .Controlled P: Private_Part_Pointer; record; Initialize (X:  Private_Component); Adjust    (X:   Private_Component); Finalize  (X:   Private_Component); Complete_Type  Public_Part B: Integer; P: Private_Component; -- must be controlled to avoid storage leaks ;     Protected_Proc (This: Complete_Type); CPP;

The private part is defined as a stub only, its completion is hidden in the body. In order to make it a component of the complete type, we have to use a pointer since the size of the component is still unknown (the size of a pointer is known to the compiler). With pointers, unfortunately, we incur the danger of memory leaks, so we have to make the private component controlled.

For a little test, this is the body, where the subprogram bodies are provided with identifying prints:

Ada.Unchecked_Deallocation; Ada.Text_IO; CPP Public_Proc (This:  Public_Part)   -- primitive Ada.Text_IO.Put_Line ("Public_Proc" & Integer'Image (This.A)); Public_Proc; Private_Part   -- complete declaration C: Boolean; ;    Initialize (X:   Private_Component) X.P := new Private_Part'(C => True); Ada.Text_IO.Put_Line ("Initialize " & Boolean'Image (X.P.C)); Initialize; (X:  Private_Component) Ada.Text_IO.Put_Line ("Adjust " & Boolean'Image (X.P.C)); X.P := new Private_Part'(C => X.P.C); -- deep copy Adjust; Finalize (X:  Private_Component) Free  Ada.Unchecked_Deallocation (Private_Part, Private_Part_Pointer); Ada.Text_IO.Put_Line ("Finalize " & Boolean'Image (X.P.C)); Free (X.P); Finalize; Private_Proc (This:  Complete_Type)   -- not primitive Ada.Text_IO.Put_Line ("Private_Proc" & Integer'Image (This.A) & Integer'Image (This.B) & ' ' & Boolean'Image (This.P.P.C)); Private_Proc; Protected_Proc (This: Complete_Type)  -- primitive X: Complete_Type := This; Ada.Text_IO.Put_Line ("Protected_Proc" & Integer'Image (This.A) & Integer'Image (This.B)); Private_Proc (X); Protected_Proc; CPP;

We see that, due to the construction, the private procedure is not a primitive operation.

Let's define a child class so that the protected operation can be reached:

CPP.Child Do_It (X: Complete_Type); -- not primitive CPP.Child;

A child can look inside the private part of the parent and thus can see the protected procedure:

Ada.Text_IO; CPP.Child Do_It (X: Complete_Type) Ada.Text_IO.Put_Line ("Do_It" & Integer'Image (X.A) & Integer'Image (X.B)); Protected_Proc (X); Do_It; CPP.Child;

This is a simple test program, its output is shown below.

CPP.Child; CPP.Child, CPP; Test_CPP X, Y: Complete_Type; X.A := +1; Y.A := -1; Public_Proc (X); Do_It (X); Public_Proc (Y); Do_It (Y); X := Y;  Public_Proc (X);  Do_It (X); Test_CPP;

This is the commented output of the test program:

Initialize TRUE                    Test_CPP: Initialize X Initialize TRUE                                      and Y Public_Proc 1                       |  Public_Proc (X):  A=1 Do_It 1-1073746208                 |  Do_It (X):        B uninitialized Adjust TRUE                        |  |  Protected_Proc (X): Adjust local copy X of This Protected_Proc 1-1073746208        |  |  | Private_Proc 1-1073746208 TRUE     |  |  |  Private_Proc on local copy of This Finalize TRUE                      |  |  Protected_Proc (X): Finalize local copy X Public_Proc-1                       |  ditto for Y Do_It-1 65536                       |  | Adjust TRUE                        |  | Protected_Proc-1 65536             |  | Private_Proc-1 65536 TRUE          |  | Finalize TRUE                      |  | Finalize TRUE                      |  Assignment: Finalize target X.P.C Adjust TRUE                         |  |           Adjust: deep copy Public_Proc-1                      |  again for X, i.e. copy of Y Do_It-1 65536                       |  | Adjust TRUE                        |  | Protected_Proc-1 65536             |  | Private_Proc-1 65536 TRUE          |  | Finalize TRUE                      |  | Finalize TRUE                      Finalize Y Finalize TRUE                            and X

You see that a direct translation of the C++ behaviour into Ada is difficult, if feasible at all. Methinks, the primitive Ada subprograms corresponds more to virtual C++ methods (in the example, they are not). Each language has its own idiosyncrasies which have to be taken into account, so that attempts to directly translate code from one into the other may not be the best approach.

De-encapsulation: friends and stream input-output
In C++, a friend function or class can see all members of the class it is a friend of. Friends break encapsulation and are therefore to be discouraged. In Ada, since packages and not classes are the unit of encapsulation, a "friend" subprogram is simply one that is declared in the same package as the tagged type.

In C++, stream input and output are the particular case where friends are usually necessary: Ada does not need this construct because it defines stream input and output operations by default: The default implementation of the,  ,   and   attributes may be overridden (shown for   as an example). The overriding must occur before the type is frozen, i.e. (in the case of this example) in the package specification.

AdaStreams P     C        C          A B  Integer C Boolean My_Write Stream    AdaStreamsRoot_Stream_Type Item    C     C  My_Write P

By default, the  attribute sends the components to the stream in the same order as given in the declaration, i.e. A, B then C, so we change the order.

P     My_Write Stream     AdaStreamsRoot_Stream_Type Item  C        Boolean Stream ItemC Integer Stream ItemB Integer Stream ItemA My_Write P

Now  calls the overridden version of the package.

AdaText_IOText_Streams P  Main Object PC     PC AdaText_IOText_StreamsStream AdaText_IOStandard_Output Object Main

Note that the stream IO attributes are not primitive operations of the tagged type; this is also the case in C++ where the friend operators are not, in fact, member functions of the type.

Wikibook

 * Ada Programming
 * Ada Programming/Types/record
 * record
 * interface
 * tagged

Wikipedia

 * Object-oriented programming

Ada Quality and Style Guide

|OO

Programación en Ada/Tipos etiquetados

title: Ada Programming/Object Orientation


text:
lít

Etymology
, from.

Verb

 * 1) to pour
 * 2) to cast to make by pouring into a mould

Etymology
Borrowed from.

Noun

 * 1) liter/litre

source: wikimedia

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: lít


text:
Cookbook:Shortening

Shortening is a fat used in cooking. Modern shortening is a vegetable-based product that is just barely solid at room temperature. Shortening has a higher smoke point than butter and margarine (it is less flammable), leading to its use in deep-fat frying and as a pan coating to prevent baked goods from sticking. It is also sometimes used as an ingredient, when a recipe needs a flavorless fat thicker than oil but thinner than margarine. Shortening has 100% fat content, compared to 80% for butter and margarine.

Shortening is so called because it gives a "short" texture (as in shortbread). Crisco, a popular brand, was first produced in 1911. Shortening was once made from animal fat (lard).

Refrigeration is a good idea, because the pastry-like foods commonly made with shortening will turn out best if everything (ingredients, air, rolling pin, work surface, bowls, etc.) is kept cold until baking.

Until recently, shortening was almost always made of partially hydrogenated vegetable oil. Partially hydrogenated oil contains trans- fats, which have been implicated in causing heart disease. Newer products avoid trans- fats by using a mixture of unhydrogenated oil and fully hydrogenated oil. All vegetable-based shortenings are cholesterol-free.

Butter or margarine, mixed with vegetable oil to thin it, can replace shortening used to prevent baked goods from sticking or used as an ingredient. One way is to use lard or bacon grease, as was tradition. Lard is a particularly good substitute, producing the very best pastry crusts while having less saturated fat than butter.

Recipes using shortening

 * Biscuits
 * Butter tart
 * Egg Roll
 * Hard Tack
 * Oatmeal Raisin Cookies

title: Cookbook:Shortening


text:
Wikipedia:Articles for deletion/Vash (Star Trek)

The result of the debate was merge. Johnleemk | Talk 15:45, 26 March 2006 (UTC)

Vash (Star Trek)
All this information already exists at List of Star Trek: Deep Space Nine characters. Philip Stevens 21:38, 21 March 2006 (UTC)
 * Delete No need to retain this article as it is a straight lift from the above referenced page. If a researcher requires any more detail on the character then the link to Memory Alpha will suffice.  The character only appeared in three episodes, after all.   (aeropagitica)   21:50, 21 March 2006 (UTC)
 * Delete per above — Preceding unsigned comment added by Evillan (talk • contribs)
 * Merge and redirect to List of Star Trek: Deep Space Nine characters, since a number of articles link to here already. BryanG 23:12, 21 March 2006 (UTC)
 * Make that List of Star Trek characters, see the comments below. BryanG 04:16, 23 March 2006 (UTC)

 * Weak keep Does it really belong on DS9 if the charecter was introduced in The Next Generation? She's a former love of Picards. - M ask [[Image:Flag_of_Alaska.svg|20 px]] 23:15, 21 March 2006 (UTC)
 * Forgot to mention: She appeared in more TNG episodes then DS9 ones. If anything, put her on a Next Generation list. - M ask [[Image:Flag_of_Alaska.svg|20 px]] 23:16, 21 March 2006 (UTC)

 * Merge to List of Star Trek characters. In fact, I'd consider merging the other list there too. -- Grev 02:44, 22 March 2006 (UTC)
 * Merge per BryanG. Hera1187 20:14, 22 March 2006 (UTC)
 * Merge to List of Star Trek characters since she appears in more than one series. Jtmichcock 03:15, 23 March 2006 (UTC)
 * Weak keep, or merge as per AKMask; relatively minor character who appeared in more TNG episodes. Preferably, I'd actually advocate for developing a List of Star Trek: The Next Generation characters (a la dedicated DS9 list) and merging it (and other minor characters) with that: the current single list of Star Trek characters (which can link to sublists) is already somewhat long and unwieldy.  E Pluribus Anthony | talk | 12:55, 26 March 2006 (UTC)


text:
Euchrysops unigemmata

Euchrysops unigemmata is a butterfly in the family Lycaenidae. It is found in Malawi, Zambia and possibly the Democratic Republic of the Congo. The habitat consists of montane areas.

title: Euchrysops unigemmata


text:
Vincent Regeling

Vincent Regeling (born 7 May 1997) is a Dutch professional footballer who plays as a defender.

Club career
Born in Heemstede, Regeling played in the youth academies of SV Hoofddorp, HFC Haarlem and RKSV Pancratius, before joining the AZ youth system. He made his Eerste Divisie debut for Jong AZ on 1 September 2017 in a game against Jong FC Utrecht. His contract with AZ expired in the summer of 2020.

On 4 September 2020, Regeling signed a two-year contract with Telstar. He made his debut on 13 September in a 1–2 home loss to MVV, playing the full match.

Personal life
Born in the Netherlands, Regeling is of Surinamese descent.

title: Vincent Regeling


text:
Gésio Amadeu

Gésio Amadeu (14 June 1947 – 5 August 2020) was a Brazilian actor.

Death
Amadeu died from COVID-19 in São Paulo on 5 August 2020, during the COVID-19 pandemic in Brazil. He was treated for hypertension problems and contracted COVID-19 at a hospital.

title: Gésio Amadeu


text:
User:Blast/tutorial2

Next, text!

Don't groan—it's not that bad. There are some advanced uses of HTML and wikimarkup for text, but you'll learn that on your own at a later date. Right now, let's focus on the basics.

First, the most basic of text modification: bold and italic (and both).

italic text italic text

bold text bold text

bold and italic text bold and italic text

Next, there's indents. These are easy to do. Just type a : directly before any text (make sure it is the first character on that line), and type after it. You can stack these, as well, like so:

 * test
 * test

 * test
 * test
 * test

Next, page breaks. Useful for when you want to do

this

but don't want the little space in between the lines.

This is easy to do: just type

There is no closing tag for this!

Sometimes, you'll see

which is basically the same thing.

Example: text text

Don't put the  tag on the bottom of the list!

There are two list formats that will on occasion be useful to you:

The first is bullet-style, and the second is numbered. Neither of these require the  tag— they automatically do this. So just hit enter after you're done with a line, and start on a new one directly below it.

The first can be stacked, like so:

 * level 1
 * level 2
 * level 3
 * level 4

etc.

This is done with a *. For the sub-tiers, just put ** or ***, and so on, depending on the level. Stylistically speaking, it's easier on the editors if you put a space after the end * and before the actual text.

The other way to do lists is numbered (these can't be stacked, like bullets). All you type is a #, which gives a list like this:

 * 1) no. 1
 * 2) no. 2
 * 3) no. 3
 * 4) no. 4

Lastly, I want to go over something you will see everywhere. It's called wikilinking, and it works like this:

link name

The link is actually the title of the page, not the URL. So if I wanted to link to the previous page, I would put

User:Blast/tutorial1

which would give User:Blast/tutorial1.

Now, the second part of wikilinking—the name—is just what you want to appear as the text when you link to something.

Say I wanted to link to the same page as before, but I wanted it to appear as something different. I'd then put

abc

which would show up as abc.

← →

title: User:Blast/tutorial2


text:
User:Xentalion

Xentalion
I'm programmer, and have worked on a couple FOSS projects at Sourceforge

CWallpaper A frontend for feh, bsetroot, fbsetbg (which is another frontend), Esetroot, and others.

CPOINt - A SDL slideshow program written in C++.

My art page - My art page

title: User:Xentalion


text:
Talk:Tate's Hell State Forest

[Untitled]
This page has an orphaned link for the map. The new URL is http://www.floridaforestservice.com/ Gdwyer2 (talk) 22:22, 27 February 2013 (UTC)
 * Here's a more specific link. ---User:DanTD (talk) 01:43, 30 June 2021 (UTC)

Name explanation
The park obviously has a strange and striking name. Why is it not explained in the article? Jtcarpet (talk) 19:08, 9 March 2014 (UTC)

https://en.wikipedia.org/wiki/Tate%27s_Hell_State_Forest

--Done Agarikon (talk) 01:07, 9 June 2017 (UTC)

title: Talk:Tate's Hell State Forest


text:
File:Friedman-Jeffrey.jpg

Summary
Jeffrey Mark Friedman (1945-2007), mayor of Austin, Texas from 1975 to 1977. Image from Jewish Currents, v. 31, no. 6 (June 1977), pg. 4. Fair use image of a historically significant deceased individual for which no free use image exists. Digitized and digitally edited by Tim Davenport ("Carrite") for Wikipedia, no copyright claimed for the work, file released to the public domain without other restrictions in addition to those which remain attached to the original image.

Fair use rationale
1. This is an image of a historically significant deceased individual for which no free use image exists. 2. The photographer who took the photo is unspecified and unknown, so that no release can be obtained. It is probably an official campaign photograph from 1975. 3. The image is a low resolution rendition, a 96 dpi scan of a printed halftone. No damage is done to the value of the original image. 4. This image is to be used to illustrate a non-commercial encyclopedia entry specifically about the subject of the image. 5. The image is not replaceable.

title: File:Friedman-Jeffrey.jpg


text:
soakaway

Etymology
🇰🇲

Noun

 * 1)  A deep hole used for drainage, where rainwater and other wastewater drains directly into the ground, without connection to any mains drainage or sewerage pipes.

title: soakaway


text:
User:Katie Gruessing/sandbox

Article Review of "Black-Figure Pottery"
 * Questions from Week 4 Section of the Art of the Ancient Mediterranean Class
 * Is everything in the article relevant to the article topic? Is there anything that distracted you?
 * The article was defiantly relevant, it gave a little bit of background before diving into the production techniques and the oxidization in the klin.
 * Is the article neutral? Are there any claims, or frames, that appear heavily biased toward a particular position?
 * The article seem very neutral, it has a lot of sources and it divided up in a very readable way.
 * Are there viewpoints that are overrepresented, or underrepresented?
 * the Article defiantly seemed to focus on Corinth and Athens. Other than that the reviews were very well rounded.
 * Check a few citations. Do the links work? Does the source support the claims in the article?
 * All the citations are from scholarly, reliable sources or one that are well known for the time period.
 * Check out the Talk page of the article. What kinds of conversations, if any, are going on behind the scenes about how to represent this topic?
 * the article has a lot of history but the talk page comes up empty which I think is something wrong on my end.
 * How is the article rated? Is it a part of any WikiProjects?
 * We just talked about this topic in class

Pyrgoteles
Pyrgoteles (Greek: Πυργοτέλης) one of the most celebrated gem-engravers of ancient Greece, living in the latter half of the fourth century b. c. The esteem in which he was held may be inferred from an edict of Alexander the Great, which placed him on a level with Apelles and Lysippus, by naming him as the only artist who was permitted to engrave seal-rings for the king. (Plin. H. N. vii. 37. s. 38, xxxvii. 1. s. 4.)

Works
Pyrgoteles was one of the three court artists authorized to depict Alexander the Great's figure in art (the others being Apelles for painting and Lysippos for sculpture). Pliny the Elder (Natural History 37.8) adds that Alexander had issued an edict forbidding anyone to engrave his image on emeralds, and other gems, outside of Pyrgoteles.

Unfortunately, every thing else respecting Prygoteles is left to the unknown, due to the neglect of ancient writers and modern forgers, lack of remains, and so many copies coming out of that same time period. There are several works are under the name of Pyrogoteles, but of these the best known have been demonstrated by Winckelmann to be forgeries, and very few of the others have any signs to authenticity due to the mass production of pieces with the name Pyrgoteles on them of just a "P".

Despite the large impact that Pyrgoteles’ contributed to Alexander's imagery in the ancient world, we are today unable to identify all that much of his actual output. No signed pieces of his survive, or are able to be deemed authentic; however when comparing sources, this seems to be up in the air. With some sourcing speaking of his forgeries as if authentic and others only giving Prygoteles the label of gem engraver to Alexander. Various texts suggest that next to gem-engraving, Pyrgoteles was responsible for coin dies as well, and coinage was one of the main forms of propaganda and marketing of images in the ancient times. Coinage was the standard medium for diffusing royal imagery in the Hellenistic period, and allowed emperors to be remembered and altered to fit the aspects of culture in said time periods. Alexander never had his actual portrait cut on his coins during his lifetime, however after his image was highly produced in the later years after his death, though it is possible that Pyrgoteles was responsible for designing Alexander's first coin dies, which depict Herakles, Alexander's patron god, in dedication to Alexander. Following Alexander's premature death, Pyrgoteles would have most likely continued his career in the courts of his successors, which we know as Lysippos and Apelles who shows up in much of the literature pertaining to Prygoteles, and are often associated with being his disciples and predecessors

Coin Dies
In terms of work he did outside of engraving for Alexander, Pyrgoteles is often associated with the so-called Lysimachi, a long series of silver tetradrachms and gold octodrachmsm, or in other words, gold and silver coins issued by King Lysimachos of Thrace starting in 297/6 bc and made by Pyrgoteles. Lysimachos was at the time emerging victorious from the wars against his fellow-claimants of Alexander's political and territorial legacy, and he chose to illustrate his coins with a posthumous portrait of their common predecessor, giving an image of success, victory, and strong Greek values. The obverse of the coins shows the head of the deified Alexander, wearing the royal diadem and the ram's horn, a direct allusion to his being the son of the Egyptian deity of Zeus Ammon, also showing him clean shaven to show his youthfulness, and possible naive state. This paying respect to Alexander carries the implicit connotation of Lysimachos’ own regal and military qualities, admirably demonstrated through his victory at the crucial battle of Ipsos in 301 bc. As it appears on the coins, Alexander's head comes close enough to Plutarch's descriptions and the extant marble heads in the Lysippan tradition, for it to be quite possible that Pyrgoteles was responsible for the design of the Lysimachi, presumably working for the Thracian court after the dissolution of Alexander's empire, but again there is no proof of Pyrgoteles being the master mind behind these coins for King Lysimachos.

Forgeries
In modern times this famous name has been engraved as a forged signature on ancient gems; the gem cutter Allessandro Cesari (16th century) adopted the name of his famous predecessor and signed his works accordingly. The name inscription ''P. ''can be found. This is was caused much confusion when it comes to identifying authentic works of Prygoteles.

Impact
Many of these cataloged works were from the Greeks as well as the Etruscans. The Greeks inherited seal engraving, along with other accomplishments from people and travelers of the near East. Apart from the penchant for the scarab form in the sixth century, the art quickly Hellenized and became a favorite medium for virtuosity. The Greek gem cutters introduced the scarab to Italy, where is continued to be adopted to Etruria, and the Estruscans eventually tagged along as well. Gem engraving and coins were a new curated art form that, much like most Greek art, was admired and copied and taken on to show politics, mythology and historical events

title: User:Katie Gruessing/sandbox


text:
User:Ronnie Adamz/sandbox

Ronnie Adamz

Full Names. Ronald Lukwago

Spounce Joweria Nantanda Lukwago

Education School

Linkedin Account

SCM YMCA COMPREHENSIVE INSTITUTE Supply Chain Management & Procurement

In the overall supply chain process, the procurement function stops once your company has possession of the goods. For a business to make a profit the cost of procuring your goods must be less than the amount you can sell the goods for, minus whatever costs are associated with processing and selling them.

ICT Cavendish University Uganda ICT - Information and communications technology

ICT refers to technologies that provide access to information through telecommunications. It is similar to Information Technology (ICT) But focuses primarily on communication technologies. This includes the Internet, wireless networks, cell phones, and other communication mediums.

Ronnie Adamz is a Ugandan Citizen Businessman mainly carrying out business in the Middle states of Gulf. (Middle East)

BORN IN Kampala Uganda Mulago Hospital Uganda

Email Adress

Charity Organisation for helping the needy in all ways both children and Elders

title: User:Ronnie Adamz/sandbox


text:
Zelyonaya Roshcha, Rebrikhinsky District, Altai Krai

Zelyonaya Roshcha (Зелёная Роща) is a rural locality (a selo) and the administrative center of Zelenoroshchinsky Selsoviet, Rebrikhinsky District, Altai Krai, Russia. The population was 536 as of 2013. There are 10 streets.

Geography
Zelyonaya Roshcha is located 15 km east of Rebrikha (the district's administrative centre) by road. Klyuchevka is the nearest rural locality.


text:
povoação

Etymology
From, possibly corresponding to , from , and thus perhaps a.

Noun

 * 1) settlement
 * 2) settlement

title: povoação


text:
Madonna and Child (Correggio, Vienna)

Madonna and Child is a 65 by 45 cm oil on canvas painting. It dates to 1512-1514 and is attributed to Correggio but this attribution is uncertain. It was rediscovered in Hohensalzburg Castle in 1928 and given to the Kunsthistorisches Museum in Vienna, where it now hangs.

title: Madonna and Child (Correggio, Vienna)


text:
Talk:Dorothy Howell Rodham

Birth date
Can we find out exactly when she was born, given that her daughter Hillary may be the next President of the USA? Andycjp 07:53, 21 January 2007 (UTC)

 * Would be nice, but both Living History and the William Addams Reitwiesner geneology just say 1919. Wasted Time R 13:30, 8 July 2007 (UTC)

 * Now have it narrowed down to on or near June 1 of that year. Wasted Time R (talk) 01:19, 15 December 2007 (UTC)

 * ✅ Probably family info is reflected on her tombstone (in the external link) "June 4, 1919" via Find A Grave. -- AstroU (talk) 23:19, 12 June 2015 (UTC)

Notability
Does she really warrant an article? Other than being described as a homemaker the article is full of nothing but trivia. Williamgeorgefraser 15:38, 1 November 2011 (UTC) — Preceding unsigned comment added by Williamgeorgefraser (talk • contribs)
 * So are you proposing it for AFD? He's Gone Mental 16:56, 1 November 2011 (UTC)

I'm a genealogist,and I am all over this like a college student on pizza. Check out this NYT obit: http://www.nytimes.com/2011/11/02/us/dorothy-rodham-mother-of-hillary-clinton-dies-at-92.html PinkWorld (talk) 17:39, 1 November 2011 (UTC)Pink
 * Don't know if you want to reccomend AFD, but if you do, I think it should have a strong Keep. Mrs. Rodham is the mother of an important political figure and has campaigned for Secretary Clinton. V. Joe (talk) 21:09, 1 November 2011 (UTC)
 * Well if no-one else wants to recommend AfD, I'm tempted. WP:NOTINHERITED specifically states "parent notability should be established independently; notability is not inherited "up", from notable subordinate to parent". I see nothing in the article supporting notability other than Howell Rodham's notable daughter; and the large list of references appear to be in two categories: articles primarily about Hilary, and historic records (census, yearbook) which don't confer notability. EJBH (talk) 14:36, 2 November 2011 (UTC)
 * It already went to AFD a couple of years ago and survived (see the link in the box above). It will survive again.  If you look at Category:Parents of Presidents of the United States you'll see that there are already 54 articles about parents of U.S. presidents.  This article is similar to most of those except it is better sourced.  Wikipedia has a lot of problems, but the existence of these articles isn't one of them.  Wasted Time R (talk) 01:31, 3 November 2011 (UTC)

Yes, she should have an article, and no, her life was not full of trivia. If you're the parent of somebody really, really famous, you sometimes get written about a lot yourself, and thus qualify by WP guidelines. Other examples include Virginia Clinton Kelley, Ann Dunham, and Dorothy Walker Bush, or for that matter Julia Lennon. Wasted Time R (talk) 02:33, 2 November 2011 (UTC)
 * Well maybe the article should be rewritten to include some of what was written about her because at present it is nothing but trivia<IP_ADDRESS> (talk) 07:03, 2 November 2011 (UTC)
 * I've tried to add a little more about her influence on Hillary. Wasted Time R (talk) 01:31, 3 November 2011 (UTC)
 * I've added a video of President Obama discussing her life. I'm not crazy about the position on the page, but I'm not sure there is much of an alternative. Feel free to move it around. Ben (Major Bloodnok) (talk) 21:11, 3 November 2011 (UTC)
 * She will remain famous for being famous; her daughter will highlight her in her "Hillary for POTUS" speech tomorrow. Many Wikipedia readers and Google-searchers will arrive at this page this weekend. -- AstroU (talk) 23:24, 12 June 2015 (UTC)

title: Talk:Dorothy Howell Rodham


text:
Senator McCreesh

Senator McCreesh may refer to:

 * John McCreesh (1881–1959), Pennsylvania State Senate
 * Thomas McCreesh (1928–2016), Pennsylvania State Senate

title: Senator McCreesh


text:
Joel Munsell

Joel Munsell (April 14, 1808 – January 15, 1880) was an American printer, publisher and writer.

Biography
Joel Munsell was born in Northfield, Massachusetts on April 14, 1808. He established himself as a printer in Albany in 1827. He edited and published the Albany Minerva in 1828, was associate editor of the Microscope in 1834, and was publisher and editor of the New York State Mechanic from 1841 to 1843. Subsequently, he published The Lady's Magazine, the Northern Star and Freeman's Advocate, The Spectator, the Unionist, the Albany Daily State Register, the Guard, The New York Teacher, the Morning Express and Statesman, Webster's Almanac, The Daily Statesman, and for three years the New England Historical and Genealogical Register.

Munsell made a close study of the craft of printing, in its history and application, and his collection of works on the subject, the largest in America, was in part purchased by New York State for the New York State Library. His printing and publishing business was continued by his sons.

He was elected a member of the American Antiquarian Society in 1854.

He died at his home in Albany on January 15, 1880.

Publications
He contributed papers to the Transactions of the Albany Institute, of which he was a founder, and published: Among his contributions to American historical literature was the "Historical Series" (10 vols., Albany, 1850–58) that he edited and annotated mostly himself. In 1872, he published a catalogue of all the books and pamphlets he had printed down to that date (8vo, 191 pp.).
 * 'Outline of the History of Printing (1839)
 * Annals of Albany (1849–59)
 * The Typographical Miscellany (1850)
 * Chronology of Paper and Paper-Making (1857; enlarged 1870)
 * Every-Day Book of History and Chronology (1858, 1st edition)
 * Manual of the First Lutheran Church of Albany, 1670-1870 (1871)
 * Woodworth's Reminiscences of the City of Troy

title: Joel Munsell


text:
Talk:Domingos Paciência

External links modified
Hello fellow Wikipedians,

I have just modified 2 one external links on Domingos Paciência. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added tag to http://www.record.xl.pt/interior.aspx?content_id=301235
 * Added archive https://web.archive.org/web/20160303215323/http://www.apoelfc.com.cy/nqcontent.cfm?a_id=13099&tt=graphic&lang=l1 to http://www.apoelfc.com.cy/nqcontent.cfm?a_id=13099&tt=graphic&lang=l1
 * Added archive https://web.archive.org/web/20160304192423/http://apoelfc.com.cy/nqcontent.cfm?a_id=13938&tt=graphic&lang=l1 to http://apoelfc.com.cy/nqcontent.cfm?a_id=13938&tt=graphic&lang=l1

Cheers.— InternetArchiveBot  (Report bug) 00:08, 15 December 2016 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified one external link on Domingos Paciência. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20120403220951/http://www.cmjornal.xl.pt/detalhe/noticias/sport/sporting/domingos-e-o-treinador-de-godinho-lopes to http://www.cmjornal.xl.pt/detalhe/noticias/sport/sporting/domingos-e-o-treinador-de-godinho-lopes

Cheers.— InternetArchiveBot  (Report bug) 13:52, 3 December 2017 (UTC)

Move discussion in progress
There is a move discussion in progress on Talk:Domingos (name) which affects this page. Please participate on that page and not in this talk page section. Thank you. —RMCD bot 18:11, 28 March 2022 (UTC)

title: Talk:Domingos Paciência


text:
Talk:Domenico Cefalù

External links modified
Hello fellow Wikipedians,

I have just modified 2 one external links on Domenico Cefalù. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20121022121035/http://www.nypost.com/p/news/regional/item_2AcnHy0eRihAp8yfZNLplO to http://www.nypost.com/p/news/regional/item_2AcnHy0eRihAp8yfZNLplO;jsessionid=F9E2517F161480F3B06551C9679F3A2B
 * Added archive https://web.archive.org/web/20100125050927/http://gangstersinc.tripod.com:80/Gambino.html to http://gangstersinc.tripod.com/Gambino.html

Cheers.— InternetArchiveBot  (Report bug) 22:44, 14 December 2016 (UTC)

title: Talk:Domenico Cefalù


text:
Category:Binghamton University alumni

This category is for alumni (graduates) of Binghamton University, also known as the State University of New York at Binghamton. This category also contains graduates who attended the university when it was known as Triple Cities College or Harpur College.

title: Category:Binghamton University alumni


text:
Haddina Kannu

Haddina Kannu is a 1980 Indian Kannada-language film directed by A. V. Seshagiri Rao and produced by P. Krishna Raj. The film stars Shankar Nag, Srinath, Lokesh and Manjula. The film was scripted and presented by L. S. Iyer.

Cast

 * Shankar Nag as Vikram
 * Manjula as Benne Bhagya
 * Srinath as Vinod
 * Lokesh as Rudra
 * Dwarakish as Dose Damodara
 * Sundar Krishna Urs as Prathap
 * Musuri Krishnamurthy as Constable Kariyanna
 * Tiger Prabhakar
 * Jayamalini
 * Vajramuni as Bhadrappa
 * K. S. Ashwath as Dharmappa
 * Jyothi Lakshmi
 * Pramila Joshai as Chenni
 * M. Jayashree

Soundtrack
The music of the film was composed by Satyam with lyrics penned by Chi. Udaya Shankar.

title: Haddina Kannu


text:
ripristinare

Etymology
From.

Verb

 * 1) to restore, to revert
 * 2) to reactivate
 * 3) to reestablish

title: ripristinare


text:
Talk:Latin/Lesson 3-Passive

Untitled
See (external) for a table of the passive voice.

(Please feel free to use Google when this textbook doesn't cover something.)

See also: (external--sister project) for usage of the passive voice.

Now let's discuss the Wikipedia entry: "When the subject is the agent or actor of the verb, the verb is said to be in the active voice. When the subject is patient, target or undergoer of the action, it is said to be in the passive voice. For example, "The cat ate the mouse" is active, but "The mouse was eaten by the cat" is passive.

In a passive voice sentence, the subject and the direct object switch places. The direct object is promoted to subject, and the subject is demoted to a complement (that may be left out).

In English, the passive voice is a periphrastic construction, i .e. it's modelled using an ad hoc phrase structure with a different word order, an auxiliary verb and a participle of the main verb. In other languages, such as Latin, the passive voice is simply marked on the verb as an inflection."

Always form words in the passive voice based on the present_stem, and then inflect it using the personal ending. Memorize the infinitives first, starting with the 3rd conjugation.

What is meant by the usage of "inflect" (I know it's a verb)?
In a Slashdot article, it was commented that using Wikipedia, and by extension Wikibooks requires "Wikipedia thinking"--in other words, concepts may be introduced in several different ways, by several different people--some more trustworthy than others.

In this instance, inflect is the generic verb for either conjugating a verb or declining a noun. In this chapter, we discuss conjugating verbs into the passive voice, because to conjugate is to work with infinitives. Conjugating into the passive voice uses a different set of infinitives.

Exercise # 1: Change active infinitives to passive infinitives.  Exercise # 2: List personal endings 10 times for sureity. Exercise # 3: See whether you can conjugate. Check your answers, and ask for help on the reference desk if you need it.

title: Talk:Latin/Lesson 3-Passive


text:
River Tolka

The River Tolka (An Tulcha, "the flood"), also once spelled Tolga, is one of Dublin's three main rivers, flowing from County Meath to Fingal within the old County Dublin, and through the north of Dublin city, Ireland (the other main rivers are the Liffey and the Dodder). By flow of water, the Tolka is the second largest river in Dublin, following the Liffey, but runs more slowly than the Dodder.

Course and system
The Tolka rises east of Dunshaughlin, County Meath, and by-passes Dunboyne, from where it receives the Castle Stream tributary. From Clonee, where it is joined by the Clonee Stream at the eastern end of the village, it flows into County Dublin.

The river continues through Damastown and Mulhuddart, Blanchardstown, and Ashtown (southwest of Finglas), and the southern edges of Finglas itself, and then the north Dublin suburban districts of Glasnevin and Drumcondra where it comes closest to the Royal Canal near Binn's Bridge. At the southern side of Tolka Park it forms the border between Ballybough and Fairview, Fairview and North Strand, before entering Dublin Bay between East Wall and Clontarf.

Tributaries
The Tolka has many tributaries, the first major one being the Castle Stream at Dunboyne, then it's the Clonee Stream East of Clonee, which both fall within the borders of County Meath. There are at least fourteen infalls within Dublin City boundaries (the count is complicated by connections with the Wad River system).

Fingal County Council area tributaries include the East and West Pinkeen Streams, and another waterway in semi-rural Dublin. While Dublin City Council area tributaries include the Scribblestown Stream (visible from Abbotstown to past Dunsink), the Finglaswood (or Mount Olivat) Stream from around Cappagh, the Finglas River (joined by a stream from St. Margaret's Road), the Claremont Stream which joins the Tolka near Bon Secours Hospital, the Cemetery Drain (so-called as it runs near Glasnevin Cemetery) before joining the Tolka just past the Botanic Gardens, the Hamstead Stream (from the area now occupied by Hamstead Park and DCU), inflowing somewhat downstream of Mobhi Bridge, and a small stream from around St. Patrick's Teacher Training College, Drumcondra.

The last few tributaries connect to the tidal part of the Tolka, or its estuary, but have been confused by the merging of natural watercourses and city drainage lines. There are at least four such watercourses, including the multi-branched water sometimes called the "Grace Park Stream", another sometimes "Middle Arch Stream" and the Marino Stream.

Wad River connections
The Wad River system, coming from north Ballymun, interconnects with the Tolka, most notably via a link with the Claremont Stream, and with the Wad River Diversion, which flows along Ballymun Road and Glasnevin Avenue (the Wad's main outfall to the sea is at Clontarf, not far east from the Tolka's mouth).

Parks and green spaces
The path of the river through Dublin takes it through a number of parks. It passes initially through the Tolka Valley Linear Park near Blanchardstown, then between trees north of River Road, then along the southern edge of the Tolka Valley Park in the western City Council area, where it receives a tributary which provides the source of water for a pond featuring considerable birdlife, including swans, ducks and herons. A large landscaped pitch and putt facility operated by Dublin City Council is situated on the southern side of the park, just south of the meandering river.

The river then flows past the tree-lined recreational areas adjacent to Glasnevin Woods and Violet Hill and forms the northern boundary of Glasnevin (Prospect) Cemetery before meeting the National Botanic Gardens. The river forms the northern border of the Botanic Gardens except for the beautiful Rose Gardens situated on the northern side and accessed via a bridge. Thereafter it passes Glasnevin village and flows into Griffith Park where it forms a major feature of the park. Continuing on past Our Lady's Park, Drumcondra and under Frank Flood Bridge (previously known as 'Drumcondra Bridge'), the river runs behind housing, and the green spaces at the Archbishop's Palace and Clonliffe College, before coming to Ballybough. Below Annesley Bridge at Fairview, around which was originally the river mouth, before reclamation, it runs beyond one last green space, Fairview Park, and turns to reach the sea between East Wall and western Clontarf.

Flooding
The river floods infrequently but with occasional severity. It is not "flashy" like the Dodder but builds up over a period. Notable floods occurred in October 1880, December 1954, November 1965, August 1986 (Hurricane Charley), November 2000, November 2002, January and April 2005, August 2008 and October 2011; those of 1954 and 2002 were the most severe.

1954 floods
In early December 1954, the River Tolka flooded areas in Glasnevin, Drumcondra, Fairview, Ballybough, North Strand and East Wall. North Strand was particularly badly hit, and it became known as the Great North Strand Flood. The heavy rainfall began on 8 December 1954, with the emergency services deploying boats to rescue residents from Botanic Avenue, the Richmond Road, Grace Park Avenue, and the wider North Strand area. The spring tide happened at 12:40am on the morning of 9 December, seeing the River burst its banks at 1:30am and led to the Great National Railroads Bridge railway bridge which served the Belfast line at East Wall Road being swept away at 4:30am. The debris from the collapsed bridge blocked the river and exacerbated the local flooding. There were 2 fatalities: one elderly woman died in her flooded home in St Bridget's Cottages, and another died of a heart attack 4 days after her rescue from her home. Fairview Park was completely flooded. In the North Strand area, the flood water was up to 4 feet deep. 400 residents were evacuated. The Irish Press called it "the worst day following the worst night in memory". A number of animals died as a result of the flooding, including 12 cows, a donkey, a pig, and pups and poultry.

As a result, the mouth of the River Tolka was widened east of Annesley Bridge a number of years later. This helped to restore the flow of the river which had been affected by the reclamation of the sloblands. The railway bridge was eventually replaced with a Bailey Bridge.

2002 floods
In November 2002, flooding caused extensive damage to residential areas along the Tolka banks. After this, much work was done to strengthen the river's flood defences, and following heavy flooding in 2005, major works to deepen and widen the river were carried out on a number of stretches most notably at Glasnevin Woods and at Drumcondra Bridge. Controversially, the small natural waterfall at Glasnevin Woods was replaced by an artificial stepped fall.

Analysis of the hydrological conditions giving rise to the 2002 flood showed that the classic conditions for a severe flood in the Tolka occurred, these being winter conditions with heavy rain in the previous days and weeks leading to saturated conditions followed by sustained severe rain over around 48 hours.

Fauna
On 28 September 2011, it was reported in the press that salmon have returned to spawn in the River Tolka for the first time in over 100 years.

It was reported in 2013 that an Irish Wildlife Trust survey found otters living along the Tolka. On 22 July 2014, it was reported that a pollution incident had led to a major fish kill on the river. Others of note are regular sightings of kingfisher, bats and grey heron. The river holds a large stock of small wild brown trout, this is topped up a few times a year by the angling club for competitions.

title: River Tolka


text:
1918 Kansas Jayhawks football team

The 1918 Kansas Jayhawks football team represented the University of Kansas as a member of the Missouri Valley Conference (MVC) during the 1918 college football season. In their first and only season under head coach Jay Bond, the Jayhawks compiled a record of 2–2 record and were outscored by opponents by a combined total of 66 to 33. Due to events related to World War I and the 1918 flu pandemic, the Missouri Valley Conference did not schedule any official conference games, recorded no standings, and awarded no title for 1918. The 1918 Kansas team played its home games at McCook Field in Lawrence, Kansas. Lewis Foster was the team captain.

Schedule
Season was shortened due to the Spanish flu pandemic.

title: 1918 Kansas Jayhawks football team


text:
Mosseruds GF

Mosseruds GF is a sports club in Karlstad, Sweden, established on 8 September 1938. In 2010, the men's bandy team qualified for the Swedish second division.

title: Mosseruds GF


text:
File:Dulles-sign-11aug06.jpg

Summary
Signs such as this one appeared at Washington Dulles International Airport on August 11, 2006 after a plot was uncovered to denotate ten airliners over the Atlantic Ocean.

Taken by User:Tariqabjotu. --  tariq abjotu  (joturner) 20:49, 11 August 2006 (UTC)

authors: ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ

title: File:Dulles-sign-11aug06.jpg


text:
Wikipedia talk:Deletion review/Log/2020 August 11

 * RoySmith, please restore the page to draft. Corwin of Amber (talk) 06:41, 19 August 2020 (UTC)


text:
Wikipedia:Articles for deletion/CallingTab

The result was Speedy delete. --MelanieN (talk) 22:17, 12 February 2015 (UTC)

CallingTab

 * – ( View AfD View log  Stats )

Simply refers to a specific product, may not be notable smileguy91talk 02:37, 11 February 2015 (UTC)
 * Note: This debate has been included in the list of Business-related deletion discussions. • Gene93k (talk) 21:24, 11 February 2015 (UTC)
 * Note: This debate has been included in the list of Technology-related deletion discussions. • Gene93k (talk) 21:24, 11 February 2015 (UTC)


text:
User:AkashJain0900

User:AkashJain0900 is from South Asia, in India, from Banglore Contact info : akashjain.0900@gmail.com

title: User:AkashJain0900


text:
Wiktionary:Votes/bt-2007-11/User:Tbot for bot status

User:Tbot for bot status

 * Nomination: I hereby request the Bot flag for User:Tbot for the following purposes:
 * Update existing templates, changing t to t- or t+ as needed.
 * Add the t template to entries where useful.
 * Documentation at User:Tbot
 * Robert Ullmann 08:50, 5 November 2007 (UTC)

 * Vote ends: 12 November 2007 23:59 UTC
 * Vote started: 08:50, 5 November 2007 (UTC)

 * Discussion:
 * [[Image:Wikt rei-artur3.svg|20px]] WT:GP
 * [[Image:Wikt rei-artur3.svg|20px]] User talk:Tbot
 * You may note Tbot creating some translation entries. This is experimental; all such entries are in Category:Tbot entries. This function is not part of the present vote. When I have something reasonable set up to look at, it can be discussed and then voted on separately. Robert Ullmann 01:26, 9 November 2007 (UTC)

Support

 * 1) [[Image:Symbol support vote.svg|20px]] Support —Ruakh TALK 15:48, 5 November 2007 (UTC)
 * 2) [[Image:Symbol support vote.svg|20px]] Support Connel MacKenzie 20:23, 5 November 2007 (UTC)  --Connel MacKenzie 20:23, 5 November 2007 (UTC)
 * 3) [[Image:Symbol support vote.svg|20px]] Support Robert Ullmann 23:11, 5 November 2007 (UTC)
 * 4) [[Image:Symbol support vote.svg|20px]] Support \Mike 18:53, 6 November 2007 (UTC)
 * 5) [[Image:Symbol support vote.svg|20px]] Support — [ ric | opiaterein ] — 16:47, 7 November 2007 (UTC) yay
 * 6) [[Image:Symbol support vote.svg|20px]] Support Conrad.Irwin 23:34, 7 November 2007 (UTC)
 * 7) [[Image:Symbol support vote.svg|20px]] Support DAVilla 03:25, 8 November 2007 (UTC) Yea!
 * 8) [[Image:Symbol support vote.svg|20px]] Support. bd2412 T 00:28, 12 November 2007 (UTC)
 * 9) [[Image:Symbol support vote.svg|20px]] Support EncycloPetey 02:05, 12 November 2007 (UTC) For the record, I think it's a bad idea for a bot to create translational entries, even though this is not part of the present vote.
 * It would be a bad idea for a bot to create entries that went unchecked; if they just appeared as "normal" entries some of the oddities might persist for a long time. (Some are quite amusing: Noun אסלה (aslá) f. 1. throne (lavatory or toilet) ... ;-). Creating entries that someone can then look at and expand is useful. It may depend largely on who is working on the language. Robert Ullmann 04:17, 12 November 2007 (UTC)
 * 1) [[Image:Symbol support vote.svg|20px]] Support Rod (A. Smith) 01:25, 14 November 2007 (UTC)
 * 2) [[Image:Symbol support vote.svg|20px]] Support Jyril 09:37, 17 November 2007 (UTC)
 * 3) [[Image:Symbol support vote.svg|20px]] Support Cynewulf 18:20, 20 November 2007 (UTC) Even though it's already past the deadline.

Abstain

 * 1) [[Image:Symbol abstain vote.svg|20px]] Abstain —SaltmarshTalk 15:14, 6 November 2007 (UTC) I would be inclined to vote for this but since all implications of the vote might be over my head I will just abstain.

Decision

 * Passes 9-0-1 with 3 late votes also in support. DAVilla 03:39, 21 November 2007 (UTC)