pike.git / lib / modules / Val.pmod

version» Context lines:

pike.git/lib/modules/Val.pmod:91:    }       protected string _sprintf (int flag)    {    return flag == 'O' && "Val.false";    }   }      Boolean true = True();   Boolean false = False(); - //! Objects that represents the boolean values true and false. In a + //! Objects that represent the boolean values true and false. In a   //! boolean context these evaluate to true and false, respectively.   //!   //! They produce @expr{1@} and @expr{0@}, respectively, when cast to   //! integer, and @expr{"1"@} and @expr{"0"@} when cast to string. They   //! do however not compare as equal to the integers 1 and 0, or any   //! other values. @[Val.true] only compares (and hashes) as equal with   //! other instances of @[True] (although there should be as few as   //! possible). Similarly, @[Val.false] is only considered equal to   //! other @[False] instances.   //!   //! @[Protocols.JSON] uses these objects to represent the JSON   //! literals @expr{true@} and @expr{false@}.   //!   //! @note   //! The correct way to programmatically recognize these values is   //! something like   //!   //! @code - //! if (objectp(something) && something->is_val_true) ... + //! if (objectp(something) && ([object]something)->is_val_true) ...   //! @endcode   //!   //! and   //!   //! @code - //! if (objectp(something) && something->is_val_false) ... + //! if (objectp(something) && ([object]something)->is_val_false) ...   //! @endcode   //!   //! respectively. See @[Val.null] for rationale.   //!   //! @note   //! Pike natively uses integers (zero and non-zero) as booleans. These   //! objects don't change that, and unless there's a particular reason   //! to use these objects it's better to stick to e.g. 0 and 1 for   //! boolean values - that is both more efficient and more in line with   //! existing coding practice. These objects are intended for cases
pike.git/lib/modules/Val.pmod:171:   //! and it can be told apart from an ordinary zero integer with some   //! effort, it is transient in nature (for instance, it automatically   //! becomes an ordinary zero when inserted in a mapping). That makes   //! it unsuitable for use as a reliable null value.   //!   //! @note   //! The correct way to programmatically recognize @[Val.null] is   //! something like   //!   //! @code - //! if (objectp(something) && something->is_val_null) ... + //! if (objectp(something) && ([object]something)->is_val_null) ...   //! @endcode   //!   //! That way it's possible for other code to replace it with an   //! extended class, or create their own variants which needs to behave   //! like @[Val.null].   //!   //! @fixme   //! The Oracle glue currently uses static null objects which won't be   //! affected if this object is replaced.