Re: [Liberty-eiffel] bug #44278

[Raphael Mack]

Hello,

thanks Laurie for your long comment. Let me add some things inline

Am Dienstag, den 12.01.2016, 22:53 +0000 schrieb Laurie Moye:
> If I am writing time/space
> critical code, I will always be wary of using library functions, and
> will be ready to implement the function in my own code if that is more
> efficient.

I agree, that a library implementation doesn't need to care about the
last CPU cycle we squeeze out of it. Especially when we write Eiffel
code I think we should focus more on correctness, which is closely
bundled with "easy to use" and "intuitiveness". On the other side we
should not wast CPU time (or memory space) in a library with the
argumentation "the user can do a faster implementation on his own if he
wants" because finally this also restrains correctness.

> To take ARRAY.slice as an example. Let us say that I am processing image
> data stored in a 2-D array and I want to filter it with a
> finite-impulse-response filter.

Yes, but even an ARRAY.slice implementation returning ARRAY it is
possible to do this, you just have to redefine slice.

> I would be most interested to know what other users think about this. I
> am an engineer, and use Eiffel for signal-processing applications. One
> charactersitic of this is the processing of huge amounts of data.
> Perhaps this gives me a point of view not shared by other users!

We had some discussion about this, and I share your opinion about "like
Current" return value. The more interesting question is, whether we
could live with the need to provide a creation feature make in all ARRAY
subclasses... And whether this disadvantage is more important, than the
current twin-based imlpementation...

Rapha