Questions or comments

[Brian Rice]

>You asked for it, so I have some comments from quickly browsing through
>your sources. I have also taken a quick look at Armin Rigo's Bazar code
>in Python. I have been discussing some stuff with a friend and I am
>thinking if I should also post something to the Tunes list.
>
>Anyway:
>
>While using '->' as a selector might be a problem, you could have '=>'
>(though I see you used '>=' and '<=' and that might cause some
>confusion).

My current working set now uses '->' and I think that I can live with 
that. Other external sugarings like @ and => I have kept for the use 
of the programmer. This release will make it out in another week or 
less.

>-----------------
>You mention:
>
>   Notice that ArrowGraph extends Arrow, so it has a head and tail.
>
>But the code says it is a subclass of ArrowStub. Later you talk about
>the apexArrow in a way that made me think this comment was about some
>previous implementation.

Indeed it does. I changed inheritance from Arrow (which made identity 
problems difficult by making the relationship between Arrows and 
ArrowGraphs less flexible) to delegation to apexArrow. FrameGraph is 
going to handle the relation between the two. I will fix this 
comment. Thanks.

>-----------------
>In Arrow>>head:tail: is didn't get this
>....
>         self become: newArrow.
>         head _ Reference to: headArrow.
>         tail _ Reference to: tailArrow.
>         self become: newArrow.                                         
>....
>
>Given that newArrow has nil in its instance variables, wouldn't this
>work? :
>
>        newArrow head: headArrow tail: tailArrow
>
>The "recursive" call to head:tail: would take care of the "Reference
>to:" stuff, right?

I was having a lot of problems with initialization of Arrows, and 
this snapshot shows some of the conceptual confusion that resulted. 
The next release should be less confusing. I already have a different 
set-up for initialization which is nicely robust and a little clearer.
But now that you mention it, I really should put a better comment in 
there to explain what's going on and why.

>-----------------
>Comments like in here
>
>!Arrow methodsFor: 'testing' stamp: 'btr 3/18/2001 01:42'!
>isCompositionOf: anArrow1 with: anArrow2
>         "Answers whether the receiver is a valid composition result of
>the
>         arguments in either order."
>         "^ anArrow1 coincidesWith: anArrow2 coords: 1@2"
>         ^ self == (anArrow1 ++ anArrow2) | self == (anArrow2 ++
>anArrow1)! !
>
>don't seem to agree with the definition of Arrow>>at: (since it seems
>to imply a 1 based indexing scheme while at: implements a 0 based one),
>but it is likely that I misunderstood something.

Nope, you found a mistake of mine. #coincidesWith:At: was added after 
much of everything else, and I was using the arrow logic texts as a 
guide, without checking for consistency. I fixed this just now. 
Thanks.

>-----------------
>There is a SmartRefStream method (around line 1940) that probably
>shouldn't be there.

That's a changeset problem (I think). I'll make sure to condense my 
changes for the next posts.

>-----------------
>
>Sorry that I am unable to make higher level comments than these...
>-- Jecel

That's fine, most of the methods right now are basic utilities. I am 
cooking up some factories with lots of large-scale patterns right 
now, and they should indicate the desired characteristics of the 
system at large. Also the more useful routines will make it explicit 
when we are using a categorial nature or a strictly informatic 
nature. Also the SmalltalkMOP routines are unusable as is.

Thanks,
~