"Larry Wall" <[EMAIL PROTECTED]> wrote: > On Mon, Nov 25, 2002 at 07:46:57PM -0500, Bryan C. Warnock wrote: > : Should an explicit bool type be part of the language? If so, how should > : it work? C<my bool $y = (0 but true)> storing only a truth property but > : no value makes little sense in the context of the larger language. So > : does handling truth as something other than a property. > > Don't think of truth as a property--it's a predicate that can pay > attention to the property if it's defined. But if there's no property, > truth is defined by the C<true> method on the class of the object. > Again, a property is just a singleton method override.
So is it fair to say that Bool is an Interface? No concrete class, no boolean literals: but if you store a value in a variable of type Bool, then you will still have access to its c<true> and c<false> methods. If we define Boolean-ness in this way, then we can say that context is an interface. I think it is true to say that a type is a junction of interfaces -- so we could allow that context is a type. If (that's a 72 point "if") we accept the preceding, then it is natural (IMO) to employ the Null-Object pattern for the remaining special case: Void is an interface with no methods (or perhaps a junction of zero interfaces)! I think we need a strong technical definition of terms here: classes, interfaces, types, contexts and objects. Lets see: An object is a value, associated with implementations of the methods that access and/or manipulate that value. An interface is a grouping of method signatures. A class is an object, whose value is an implementation of one or more methods. A variable is a reference to an object. A Type is a set of constraints on a variable. It may define the signatures of methods that must be supported by object(s) stored in the variable; and it may impose additional constraints on the value stored. A Context defines how an object will be used. This may constrain the required methods of the object, or may provide information, which is not a mandatory constraint: for example, if the result is a list, then the context may give the "natural" length of the list to which the value will be assigned. If the result is to be assigned to a scalar variable, then the context may provide access to the object currently stored in that variable. I writing these definitions, I came to the conclusion that a context is more than a type. Others may disagree. Dave.
