Consider add Optional<T> as in java.util with the very same behavior and scope

[danieleteti]

A container object which may or may not contain a non-null value.If a value is present, isPresent() returns true. If novalue is present, the object is considered empty and isPresent() returns false.
Additional methods that depend on the presence or absence of a containedvalue are provided, such as orElse()(returns a default value if no value is present) and ifPresent() (performs anaction if a value is present).
This is a value-basedclass; programmers should treat instances that are equal as interchangeable and should notuse instances for synchronization, or unpredictable behavior mayoccur.

Type Parameters: the type of value
Optional is primarily intended for use as a method return type wherethere is a clear need to represent "no result," and where using null is likely to cause errors. A variable whose type is Optional should never itself be null; it should always point to an Optional instance.

[sglienke]

Isn't that exactly what Nullable is? You already have that in MVCFramework.Nullables although they are all implemented in a non-generic way for many different intrinsic types.
I am even open to considering moving Nullable<T> to its own unit in Spring to make it easier to simply refer to that (assuming you are fine with that 3rd party dependency) and promoting to use of the spring implementation instead of each 3rd party library implementing it's down nullable type more or less in a similar way.

[danieleteti]

While Optional<T> may seems the same thing of a Nullable type, at least in terms of readability, it's not so.

Check this presentation to have a reasoning about the needs of Optional.

Like Oracle guys says:
"Optional is intended to provide a limited mechanism for library method return types where there is a clear need to represent “no result,” and where using null for that is overwhelmingly likely to cause errors."

More over container some useful high-level methods which allows to deal with "absent" value like the followings (from Java 8 doc):

Method	Description
empty	Returns an empty Optional instance
filter	If the value is present and matches the given predicate, returns this Optional; otherwise returns the empty one
flatMap	If a value is present, returns the Optional resulting from the application of the provided mapping function to it; otherwise returns the empty Optional
get	Returns the value wrapped by this Optional if present; otherwise throws a NoSuchElementException
ifPresent	If a value is present, invokes the specified consumer with the value; otherwise does nothing
isPresent	Returns true if there is a value present; otherwise false
map	If a value is present, applies the provided mapping function to it
of	Returns an Optional wrapping the given value or throws a NullPointerException if this value is null
ofNullable	Returns an Optional wrapping the given value or the empty Optional if this value is null
orElse	Returns the value if present or the given default value otherwise
orElseGet	Returns the value if present or the one provided by the given Supplier otherwise
orElseThrow	Returns the value if present or throws the exception created by the given Supplier otherwise

Obviously, all these methods could be easily implemented also in the current nullable types, it is just more explicit.

The strong similarity with nullables is what stopped me so far from implement Optional<T> in dmvcframework. However could have sense, even more now with the advent of functional actions.

Note: MVCFramework.Nullables.pas is an automatically-generated unit (generated by the tasks.py in the project root). The very first version of nullables was based on generic types, however, as you know, the RTTI information were generated in any binary where that generic type was used. So, the simple comparison of:

typeinfo(rtti_from_executable.handle) = typeinfo(rtti_from_bpl.handle)

//I don't remember the exact code that was failing...

was always false, even for the very same type, if one type comes from a binary (let's say an executable) and from a bpl (as a result from function or method).
This is the reason because the nullables have been rewritten using non-generic types, altought, using a code generator.