FileStream next

[Brian T Rice]

On Fri, 20 Jun 2003, Paul Dufresne wrote:

> Tried the next of FileStream.
> But read: into: of flush don't exist.
> So I replace it by next: into.
>
> But now, the into: must be a Sequence:
> Slate 3> p: (FileStream newForInputNamed: 'license.txt').
> <@_:  traits collection position readLimit writeLimit file>
> Slate 4> p next.
>
> *** - <@*PRIMITIVE-CLONEABLE*: traits> is not a sequence
>
> G:\slate2\slate>slate.fas
>
> And this is a ByteArray.
> Somehow ByteArray and Array are not Sequence.
> I means, Array is: Sequence and ByteArray is: Sequence are false.
>
> Array and ByteArray "are" Sequence in the sense that:
> ByteArray traits addDelegate: #parent2 valued: Sequence traits.
>
> But I guess it is not as good as derive: would be.
>
> Hope I am clear enough.
> What should be done with that?

Well, Lee has put together a fix for a significant issue. Basically, is:
was choking on the difference between traits and normal objects, and the
fact that shared methods are defined on traits objects. So, IdentitySet is
now used for the "seen" objects in allDelegatesDo: which fixes the problem
by using identityHash which is faster and not overridden. Although it
shouldn't matter, since traits objects themselves in principle should have
= defined as == and so forth with traits.

The interpreter was also modified to make a more generic safety check for
such situations, which protects us from other errors of this kind.

However, this reveals an ultimate flaw in the use of delegate slots to
handle meta-objects, and we are indeed developing plans to make this
obsolescent without losing any expressive power. Basically we are looking
at a generative programming kind of solution. But this should not be
necessary until the bootstrap is complete, and definitely not as easily
possible.

-- 
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/