Re: [Liberty-eiffel] bug #44278

[Raphael Mack]

I'd like to discuss this topic further:
In Adler we have the situation, that the class ARRAY[G] (and also others
like STRING) create objects of "like Current" type, obviously with a
specific call to a creation procedure.

Lauries example inherits from ARRAY and does not define the call
procedure as creation procedure.

What do you think about this construct:
1. Is the library class wrong, as it implicitly requires all its
subclasses to have a specific creation procedure with defined signature

Solution is to use twin instead of explicitly creating objects of "like
Current" types, which would in essence mean the compiler should warn for
create {like Current}.something

2. Should we just add a comment in the library class, that descendants
HAVE to provide a creation procedure with given signature?

3. Is the language insufficient, as there is no way to explicitly define
the creation procedure constraint from (2)?

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?

5. Should we find and fix all such cases in the library?


For me it looks like "create {like Current}.x" is evil, as it gives this
implicit constraint on subclasses and I'd like to propose that we warn
in these cases...

Regards and a happy new year,
Rapha
Am Donnerstag, den 31.12.2015, 00:29 +0100 schrieb Raphael Mack:
> Hi Laurie,
> 
> first I have to apologize for (I) responding only now after 3 days (I
> was on vacation) and (II) for not really responding since nearly one
> year on your initial report - shame on us, and thanks for pushing this
> up again.
> 
> I do not think this is a language problem but a library implementation
> issue with the slice and subarray features. ISE defines subarray with a
> return type "ARRAY[like item]", which is easy to implement basically as
> we currently do it. With this return type it should work. This would
> mean, that we'd have to remove the postcondition "same_dynamic_type" in
> ARRAYED_COLLECTION.subarray.
> 
> The other option to solve this would be to implement ARRAY.slice as:
> slice (min, max: INTEGER): like Current
>    do
>       Result := twin
> 
>       if max >= min then
>          -- Slice not empty
>          Result.remove_head(min - lower)
>          Result.reindex(lower)
>          Result.storage.slice_copy(0, storage, min - lower, max - lower)
>       else
>          Result.clear_count
>       end
>    end
> 
> With the benefit, that slice returns the same dynamic type, but with the
> drawback of being quite slow, as the complete array is copied one
> additional time.
> 
> To overcome this we could use standard_twin:
> slice (min, max: INTEGER): like Current
>    do
>       Result := standard_twin
>       Result.make(min, max)
>          
>       if max >= min then
>          -- Slice not empty
>          Result.reindex(lower)
>          Result.storage.slice_copy(0, storage, min - lower, max - lower)
>       else
>          Result.clear_count
>       end
>    end
> 
> but in this case the behavior of slice is also not so nice, as it
> doesn't copy the subclass instance of with its copy feature, so all
> subclasses would additionally need to redefined slice to do the
> necessary copying.
> 
> Currently my preference would be this last solution, but what do you
> think?
> 
> @Laurie: would you like to try this with your old code, by just patching
> the ARRAY-class in your adler installation?
> 
> Regards,
> Rapha
> 
> Am Montag, den 28.12.2015, 19:01 +0000 schrieb Laurie Moye:
> > Hi,
> > 
> > Last February, I submitted bug #22478. The problem was preventing me
> > from recompiling some old code from SmallEiffel days. I went on to other
> > things, but I would now like to get back to resurrecting this code.
> > 
> > Could someone please confirm that this is a bug, rather than some change
> > in the language that I haven't understood?
> > 
> > The code where it originally occurred has a great tangle of
> > inheritances, so I've reduced the example to something as simple as
> > possible which displays the same (rather peculiar) error message. Have I
> > reduced the code to something that wouldn't be expected to compile
> > anyway? Would it be useful to make a longer example with code that
> > actually does something sensible?
> > 
> > Best wishes,
> >              Laurie
> > 
> > 
> 
> 
>