blancolioni / kit Goto Github PK

Likely json.
Import should use default values for missing fields.

This is because they are the regular Set_* procedures in disguise

Given

record Base is
   key Tag : String;
end Base;

record Derived : Base;

Then the generated function Get_By_Tag in package Base will still return the subtype Base_Class, however the underlying type will now be either Base or Derived, depending on the value of Top_Record.

For example, generating [ .. ] for aggregates instead of ( ... )

If an enumeration is only used in a single record, put the declaration in that record's Db package, and make it also visible in the corresponding handle package (e.g. with subtype + functions, or a new type)

Enumerations which are used in multiple records should be placed into an enumeration package. Each Handle package which uses the enumeration should also make it visible (see above)

If we have

Handle.Set_Foo (Handle.Foo + 1).Done

The cache is invalidated by Set_Foo, but is revalidated by function Foo.

We should invalidate the cache in Done. This will need a callback, because Done is part of Db.

Given

record Climate is
    Average_Temperature : Float;
    function Is_Hot return Boolean;
end Climate;

Kit should generate the following function specification in the Climate handles package spec:

function Is_Hot (Item : Climate_Class) return Boolean;

In the package body, Kit should generate this

function Is_Hot (Item : Climate_Class) return Boolean is separate;

An implementation should be supplied, for example

separate (Handles.Climate)
function Is_Hot (Item : Climate_Class) return Boolean is
begin
   return Item.Average_Temperature > 20.0;
end Is_Hot;

The upshot of all this is that, given a variable V of type Climate_Class, we can now reference V.Average_Temperature and V.Is_Hot without worrying about whether they are properties or not. In the current version, we have to write a function Is_Hot in another package, and we can't use prefix notation on it.

For each table T and each ancestor table A, add to the T package the following function:

function Is_T (Reference : A_Reference) return Boolean

This function will return True if the record corresponding to Reference is also a record of T, i.e.

A.Get (Reference) in T_Type

Compile
[Ada] kit-notifier.adb
kit-notifier.adb:232:19: ambiguous call to "Append"
kit-notifier.adb:232:19: possible interpretation at a-convec.ads:471, instance at line 37
kit-notifier.adb:232:19: possible interpretation at a-convec.ads:483, instance at line 37
kit-notifier.adb:274:19: ambiguous call to "Append"
kit-notifier.adb:274:19: possible interpretation at a-convec.ads:471, instance at line 37
kit-notifier.adb:274:19: possible interpretation at a-convec.ads:483, instance at line 37

• most access is read-only, and should be implemented by an unlocked copy of the database record
• read/write should be explicit at the declaration, either by a separate type (then no declare Set_ procedures at all), or by a different Get function (e.g. Get_RW_ instead of Get_)
• iterators know whether they are read only or read write, so no API change there

This would prevent record updates being blocked by searches higher in the stack.

This is caused by definitions in the top level package:

• the record reference type is added
• the record type enumeration is updated

Change the record type enumeration to a private type. Move reference types to separate packages, either the public record package, or a new package. The public record package would require a heavier import to use just the reference type, and any packages which depend only on the reference would now need a recompile if, for example, a field was added (which is not the case now). It's not clear that there are many package which rely on the reference but not any of the fields.

A common idiom is to with the top level database package specification in a package spec, and with particular record packages in the body. How would this be affected?

We could generate a package for each table which declares only the reference type, the null refernce constant, and the to_string function (which should be fixed by the way).

Float => 0.0
Integer => 0
Enumeration => Enumeration'First
Handle => Empty_Table
Boolean => False
String => ""

It's waiting for a message from the notifier task, but the notifier task is sitting on a select with a terminate option.

Kit allows this:

record Has_Color is
   Red    : Float;
   Blue   : Float;
   Green  : Float;
end Has_Color

but not this:

record Has_Color is
   Red, Green, Blue : Float;
end Has_Color;

We should support the latter. Also, the error message is a little obscure:

$ sh ./kit.sh
Reading: ../../config/kit/carthage.kit
../../config/kit/carthage.kit:12:7: unknown table
../../config/kit/carthage.kit:12:7: missing ';'
../../config/kit/carthage.kit:12:7: missing TOK_END

Currently we just say that a particular package was not found. But we don't say who tried to with it.

function First return X_Handle
function Last return X_Handle

equivalent to First_By_Top_Handle and Last_By_Top_Handle

Readonly access to table.

For each record R
type R_Handle is tagged private;

For each field F of type T
function F (R : R_Handle) return T

Note that unlike the existing R_Type records, R_Handle is not limited.

The reference field of X_Handle types is currently uninitialized, which leads to an awkward initialization if we want to start with no element.

For each record R:

 type R_Update is tagged limited private;

function R (Handle : R_Handle) return R_Update;
procedure Done (R : R_Update);

for each writable field F of type T:

function F (R : R_Update; F : T) return R_Update;

This allows constructs such as

Person (P).Age (22).City (Utrecht).Done

Instead of a separate Done, we could generate for each field F of type T:

procedure F (R : R_Update; F : T)

So that the previous example would be

Person (P).Age (22).City (Utrecht)

Set_ procedures would not be generated for such a table.

Field values could be freely cached.

Field declaration is now

F : T := V

Where F is the name of the field, T is its type, and V is a default value.

If V is the special value <>, the default value is based on the type. Otherwise it should be a literal value of the type.

For table T, generate

No_Element constant T_Handle

Consider a record Massive defined as follows

record Massive is Mass : Float; end Massive;

This will generate an interface function Mass:
function Mass (Handle : Massive_Interface) return Float is abstract;

This function should not be called if Handle is empty, so add an assertion for that:

function Mass (Handle : Massive_Interface) return Float is abstract
  with Pre'Class => Handle.Has_Element;

Similar assertions should be applied to the Update functions.

The Empty_Handle function should have a post-condition.

• no Create subprograms
• no _Handle type

If the fields have the same type, we could just issue a warning and ignore the declaration in the derived field. But if they are different, it should be an error.