[Prev][Next][Index][Thread]

Re: 'indefinite' element types

In article <B598BCEC.86E8%ptw@callitrope.com>, P T Withington 
<ptw@callitrope.com> wrote:

> Dustin Voss d_voss@uswest.net on  2000-07-16 23:15 wrote:
> 
> > In article <B595F582.854E%ptw@callitrope.com>, P T Withington
> > <ptw@callitrope.com> wrote:
> > 
> >> Dustin Voss d_voss@uswest.net on  2000-07-15 01:15 wrote:
> >> 
> >>> There is nothing stopping you from defining a subclass of 
> >>> <collection> whose element type is indefinite <= <mytzlplck>, so 
> >>> long as <object> is somewhere in its ancestry -- and <object> is 
> >>> in everything's ancestry.
> >> 
> >> I must be missing something.  What would the Dylan code be to define
> >> a such a subclass?
> > 
> > How about...
> > 
> > define class <my-collection> (<collection>)
> > ...
> > end class <my-collection>
> > 
> > ...with functions defined on <my-collection> and <mytzlplck>?
> > 
> > Perhaps I am missing something?
> 
> Which functions?  Are you suggesting that I would need to write 
> methods for every generic function that applies to a <collection>?  I 
> suppose that would work, but it's clearly not as concise as using 
> 'limited'.  And it's unclear to me the compiler could make any 
> inferences from such a "distributed" solution.

Your original question was:

> Q2. Is there a way to construct new subtypes of collection that have 
> 'indefinite' element types, but whose type is a subtype of something 
> other than <object>?  This would seem like a useful facility that 
> would give some compile time type checking (the element type must be 
> more specific than <object>) but escape the straight-jacket of strict 
> co- and contra-variance on the element getter and setter.

If you want to create a whole new subclass of <collection>, then of 
course you need to write the corresponding methods, and they can have 
whatever element type you want.

If you want to create a new subclass of one of the existing subclasses 
of <collection> (e.g. <sequence>) which will have an element type of 
"<whatever>", then you can create a limited collection type.

If you want to create a new subclass of one of the existing subclasses 
of <collection> (e.g. <sequence>) which will have an element type of 
"indefinite <= <whatever>", then...you can create a new subclass of 
<sequence>.  According to the standard, such a sub-class can have an 
element type of "<whatever>" or "indefinite <= <whatever>".

In researching this, however, I have come to believe that the 
distinction between indefinite and definite types exists only to aid the 
definition of "limited".

Look at <simple-object-vector>.  Its element type is "<object>", but you 
can set and get elements of any type -- not just <object>.  In what way 
is that different from <simple-vector>, whose element type is 
"indefinite <= <object>"?

The only difference I can see is that "limited" is defined on 
collections of indefinite type but not on collections of definite type.

What you were looking for, in your original question, was a way to 
restrict a collection's elements to a certain type at compile-time, 
rather than run-time.  Rather than mucking about with 
definite/indefinite collections, try this:

-------------------8<----------------------
define class <my-sequence> (<sequence>)
end class <my-sequence>;

define method element-setter (element :: <restricted-type>,
                              seq :: <my-sequence>)
  next-method();
end method element-setter;
-------------------8<----------------------

There, now the type is checked at compile-time whenever you add an 
element.  Of course, it is the same old implementation of <sequence> 
underneath, with none of the presumed efficiency of a limited 
collection.  But since you cannot define you own limited types, it'll 
have to do.
Follow-Ups: References: