On 20 March 2010 06:18, Jonathan S. Shapiro <[email protected]> wrote:
> On Fri, Mar 19, 2010 at 5:50 PM, Michal Suchanek <[email protected]> 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
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
