On Sat, May 17, 2008 at 2:27 PM, Andreas Raab <andreas.raab at gmx.de> wrote:
> I'll think about it. The main problem with the paper is that it takes the
> triad ReadStream, WriteStream, ReadWriteStream and replaces those with
> CollectionStream and then lists a bunch of numbers that I simply cannot
> recreate. For example, how did you come up with the "number of methods" in
> Table 6? This doesn't compute for me at all - neither if I look at only
> those three classes, nor when I look at the number of inherited stream
> methods.


Please have a look at the NSMetrics class. Here, you have the methods
which generate the tables and their numbers. If you find any problem
with the algorithms, please tell me.


> Also, how do you decide whether "methods are implemented too high" in the
> hierarchy?


The algorithm is in NSMetrics too.


> For table 6, which methods did you consider to be implemented too
> high and are these counted in the total number of methods (which I doubt
> since the total number of methods is too small to include methods in
> superclasses so by definition it shouldn't count those).
>
> About FileStream, History and Decoder: Please provide a definition of
> "cleanly implement" so that I can see if a solution to the problem exists.
> FileStream and Decoder look fairly straightforward though so unless you have
> a very restricted definition of "clean" I'm pretty sure I can come up with
> something.

I have no definition of "cleanly implemented". I guess I would
consider your approach clean if you avoid methods implemented too high
and duplicated code. It is also important that you try to provide the
same features as Squeak and Nile do. The last thing I'm thinking about
right now is interface pollution: please avoid adding writing behavior
(like #nextPut) to read-only streams like Random and Decoder. The same
goes for positioning (with position:) and History.

-- 
Damien Cassou
Peter von der Ahé: «I'm beginning to see why Gilad wished us good
luck». (http://blogs.sun.com/ahe/entry/override_snafu)