[Prev][Next][Index][Thread]
Re: 'indefinite' element types
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.
Follow-Ups:
References: