liberty-eiffel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Liberty-eiffel] bug #44278


From: Raphael Mack
Subject: Re: [Liberty-eiffel] bug #44278
Date: Sat, 02 Jan 2016 20:16:02 +0100

Hello,

I answer to the list, as this might be interesting for others.

Am Samstag, den 02.01.2016, 13:06 +0000 schrieb Laurie Moye:
> On 01/01/16 22:17, Raphael Mack wrote:
> > 4. Should we change the library class to not returning a like-Current
> > anchored type and create only instances of the written type? -> I. e.
> > should STRING_DESCENDANT.substring return an instance of
> > STRING_DESCENDANT or STRING?
> As a user, if I have a STRING_DESCENDANT which has all sorts of
> additional features and I produce a substring version of that, I would
> normally want it to have all the additional features of the original
> STRING_DESCENDANT.

Yes, this is reasonable.

> And that is what ARRAY.slice has always done. SmallEiffel 0.75, has:
> 
>    slice(min, max: INTEGER): like Current is
>       do
>          !!Result.make(lower,lower + max - min);
>          Result.storage.copy_slice(0,storage,min - lower,max - lower);
>       end;
> 
> essentially the same as in adler, but SE-0.75 would compile my code
> without a problem. So it doesn't seem to me to be slice that's wrong,
> but rather some change to the compiler since SE-0.75.

I did not check the generated code of SmallEiffel (it always segfaults
here), but as your class D, doesn't have a creation feature named make
it is only by chance, that it works, as the only possibility is, that an
instance of D is created, and the inherited feature make is called,
isn't it? So how can the D be initialized correctly?

> Also, I am concerned that the functionless fragment of code that I put
> in the original report of the bug is misleading, and not very
> informative for users reading this list.
> 
> That code deferred make, but that was actually the first thing I changed
> when examining the bug - it got into the code as I hacked it around, but
> I can't see any reason why one would want to defer make - I only need to
> rename make and define it again. So here is a better example which
> behaves in exactly the same way.
> 
> I think it may also be useful to explain why I want to use ARRAY in this
> way.

No need to explain why it is helpful to implement reuse by inheritance -
this should be self-evident for every Eiffel programmer ;-)

Anyhow, I think your example is now slightly different, as it gives
"frame_make" - the renamed make from the super class, which is
effectively the version of the ARRAY class - as creation procedure. In
this case the class ARRAY could be compilable in the adler-version, as
it is perfectly legal to create the THING_B instance with the
dynamically bound feature make in slice. This might also invalidate my
statement above... For me it looks acceptable to compile the adler code
of ARRAY.slice iff all subclasses of ARRAY have this feature
(considering renamings and redefinitions) in the list of creation
procedures.

For this case I think we have a compiler bug. How does SmallEiffel
behave? Which feature is executed (ARRAY.make, or THING_x.make) in
ARRAY.slice? (note: this might differ in boost mode / with
optimizations) I expect, that SmallEiffel did it wrong, but you program
is not affected, as ARRAY.slice / subarray is not used on these
instances.

Regards,
Rapha






reply via email to

[Prev in Thread] Current Thread [Next in Thread]