Re: [gobo-eiffel-develop] Binary search tree

[Daniel T. <dan...@gm...>]

Colin Adams wrote:
> There area a load of empty feature clauses and a dummy invariant in at
> least one
> class.
>   
Done.
> Then I dislike the absence of a blank line after create and inherit.
>   
Done.
> Also I dislike seeing local variables with names that might class with
> attributes (and so forcing unnecessary renames in descendants).
> I personally now write all argument names as a_*, and all local names
> as either a single chanaracter or l_*. I am converting my existing
> code on a piecemeal basis.
>   
I like that suggestion and will do it like this.


Colin Adams wrote:
> On 24/04/2008, Daniel Tuser <dan...@gm...> wrote:
>
>
>   
>>> Some of the routines are too long to read on the screen.
>>>       
>> I don't like that as well. Those are the algorithms that could also be
>> implemented as recursive features. I will see what I can do to improve that.
>> But I will not make them recursive.
>> A splitting into more features is also not easy as some features would
>> require about 4 or 5 arguments. I was already working on that but stopped
>> because the resulting code was not more readable. It could be done using
>> attributes. But it would take some time.
>>  Do you think that has to be changed?
>>     
>
> I would say yes, provided there is no significant performance impact.
>
> I don't think passing 5 arguments is a reason not to do it, as the
> routines receiving 5 arguments are all secret.
>   
5 arguments are no reason, I share that point of view. At the end it has 
to be readable and understandable. I am just not sure if that is 
achieved by splitting the features. But I will certainly try it.

In the Gobo documentation "author" is used in the indexing clause, but 
most Gobo classes do not have it. So I won't use it.

I have several multi-line "description"s in the indexing clause that are 
enclosed in "[ ]". Should I use % as seen e.g. in DS_SPARSE_TABLE?