[bitc-dev] Question for the group re: OO

[Michal Suchanek]

On 20 March 2010 06:18, Jonathan S. Shapiro <shap at eros-os.org> wrote:
> On Fri, Mar 19, 2010 at 5:50 PM, Michal Suchanek <hramrach at centrum.cz> wrote:
>> I don't see where these are defined, certainly not at
>> http://www.bitc-lang.org/docs/bitc/spec.html#ty_object
>
> Very sorry - I'm spinning back up too, and I forgot that DEFCAPSULE
> got renamed to DEFOBJECT.  So you want to look at:
>
>  http://www.bitc-lang.org/docs/bitc/spec.html#ty_object
>  http://www.bitc-lang.org/docs/bitc/spec.html#ty_method
>
> We don't currently have virtual methods, but given the way that
> objects are fabricated, it isn't immediately clear that we need them.
> What's really missing here is subtyping.
>

The object really looks like interface, it specifies the methods and
it can be applied to structures which have additional methods about
which it does not care as far as I understand.

The subtyping/merging cannot be expressed with them, though.

The question is if that is really necessary.

It does not matter if one interface is subset of other. If you want an
interface you specify what you want and are done with it.

Still I wonder how do you express extensions in terms of these BitC objects.

Take these for example:

interface Ordered [:type] {

require <=>: [:type] : :numeric

assert ( sgn(self.<=> other) == -sgn(other.<=>self) )
assert ( ((self.<=> other) == 0 ) || (self != other)

def >: [other :type] : :bool { (self.<=> other) > 0 }
def <
def <=
def >=
}

interface Enumerable [:type] {
 include Ordered
 require succ: :type
 assert ( succ > self )
}

integer {

implements Enumerable

def <=>[other:integer] { self - other}
def succ { self + 1 }

}

Here the extension feature is significant, the Enumerable would grow
significantly if replicating the Ordered code was required.

Thanks

Michal