gobo-eiffel-develop

Re: [gobo-eiffel-develop] Two wishes for Christmas

[Bernd S. <ber...@co...>]

Hi Eric,

Thanks for your answer.

On Fri, 05 Dec 2008 19:49:04 +0100, Eric Bezault <er...@go...>
wrote:
>> a) I wish that 'last_string' (of "input streams") is renamed to
>> 'read_string_buffer' (or 'last_string_buffer') and a new 'last_string'
>> returns 'read_string_buffer.twin'. I have seen too many poor souls trip
>> over this one.
>
> It has been implemented like that in Gobo to be compatible
> with EiffelBase. I agree with you that it is not intuitive.
> I'll change it when/if it is changed in EiffelBase.

I think GOBO always tried to be better than EiffelBase, fixing its
problems. All it does is to disarm a well-known trap when coding. I cannot
imagine that people are relying on the fact that 'last_string' is the
actual read buffer.

>> (now the big wish)
>>
>> b) I wish that the 'put_*' implementations of dynamic data structure
>> really start behaving dynamically, even if they are implemented using
>> static containers. They should behave the same way that 'force_*' does.
>> The current behavior of 'put_*' is renamed ot 'brittle_put_*' or
> similar.
>>
>> Both points are common pitfalls. The thing that everybody is always
> using
>> 'force_*' instead of 'put_*', just to prevent problems, is ugly and
> feels
>> strange. It also makes changing back and forth between ISE and GOBO very
>> difficult.
>
> I do use `put_*'. For what it's worth, I do believe that EiffelBase's
> usage of `put' and `force' is inconsistent. In some classes it means
> something, in other classes it means something else.

That is my main reason to use GOBO (though it has many other benefits):
that GOBO has cleaned up the meaning of features and made them consistent.
This is great and clearly has been a huge effort. I love GOBO for that.

> In Gobo I tried
> to make it more consistent through out the whole library. In particular
> it is consistent with ARRAY. I'll be happy to rename `put' to something
> else (if only you provide more attractive names than the one you
> suggested), and `force' to `put' if this is done that way as well in
> a consistent way in EiffelBase (including in ARRAY). In the meantime,
> I much prefer to keep it like it is in Gobo.

(For my understanding, a DS_ARRAYED_LIST is not an ARRAY, there is no need
for consistency. I am probably not seeing the problem.)

I accept your final word here. You have walked the way, I did not.

> Bernd, you should stop believing in Santa Claus.

I never believed in Santa Claus (the tradition in our family is different).

I probably should have opened this discussion in a different way, or just
not opened it at all. Sorry about that. I will keep my mouth shut and just
'force' my way through GOBO.

Bernd

Re: [gobo-eiffel-develop] Two wishes for Christmas

[Eric B. <er...@go...>]

Bernd Schoeller wrote:
> I think GOBO always tried to be better than EiffelBase, fixing its
> problems. All it does is to disarm a well-known trap when coding. I cannot
> imagine that people are relying on the fact that 'last_string' is the
> actual read buffer.

My experience working on large Eiffel projects involving many
developers is that people are often using things that we
would have not imaging they would rely on. So I would not be
surprised that somewhere some people rely on the fact that
`last_string' is a buffer (if only for performance reason).
So what I'll try to do in the first place is to try to identify
all usage of `last_string' in the code I have access to in order
to see the real impact of such a change.


> (For my understanding, a DS_ARRAYED_LIST is not an ARRAY, there is no need
> for consistency. I am probably not seeing the problem.)

A stack is not a list. Nevertheless stacks have `put', `item', 'remove'
etc. (instead of `push', `top', `pop'). This is for consistency of
naming across the whole library, even when there is no apparent
relation between classes. Likewise for list (be it arrayed or not)
and array and any other container.

Honestly, I don't see why it is so much of a problem to use `force'
instead of `put' when you want the `force' semantics. It's not as if
the features did not exist. Here it looks more like you don't like
the name `force' for this functionality but would prefer `put'. But
as I said, I tried to keep some naming consistency through out the
library. So your request sounds as if you wanted to be able to use
`push' on stacks. It breaks naming consistency.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Two wishes for Christmas

[Berend de B. <be...@po...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> Bernd Schoeller wrote:
    >> I think GOBO always tried to be better than EiffelBase, fixing
    >> its problems. All it does is to disarm a well-known trap when
    >> coding. I cannot imagine that people are relying on the fact that
    >> 'last_string' is the actual read buffer.

    Eric> My experience working on large Eiffel projects involving many
    Eric> developers is that people are often using things that we would
    Eric> have not imaging they would rely on. So I would not be
    Eric> surprised that somewhere some people rely on the fact that
    Eric> `last_string' is a buffer (if only for performance reason).
    Eric> So what I'll try to do in the first place is to try to
    Eric> identify all usage of `last_string' in the code I have access
    Eric> to in order to see the real impact of such a change.

The performance impact would be very ugly for some of my cases. I very
often rely on the fact that strings are not cloned.

And if this is changed, eposix has to change as well, and probably many
other libraries.

I'm afraid the situation will only further trip up students as they will
be seeing a lot of last_string_buffer in actual code because it has to
perform and use GBs of memory, and mimic that.

I think education is the goal here: don't clone your strings. The
problem is people coming from Pascal/Java backgrounds where strings have
different behaviour. No one would expect last_some_class to be a twin.

Learn to live with it.

-- 
Cheers,

Berend de Boer