## ARRAY:subarray spec

Expand Messages
• I was looking at this last night and wondered why I had written code which assumed subarray (min, max: INTEGER): like Current rather than subarray (min, max:
Message 1 of 6 , Mar 13, 2002
I was looking at this last night and wondered why I had written code
which assumed
subarray (min, max: INTEGER): like Current
rather than
subarray (min, max: INTEGER): ARRAY [G]

Apart from the name, why should the result not be anchored to Current?
--
Peter Horan School of Computing and Mathematics
peter@... Deakin University
+61-3-5227 1234 (Voice) Geelong, Victoria 3217, AUSTRALIA
+61-3-5227 2028 (FAX) http://www.cm.deakin.edu.au/~peter

-- The Eiffel guarantee: From specification to implementation
• ... Because subARRAY is supposed to be an ARRAY. Current might not be an ARRAY anymore. Also the parameters min, max might not be enough to determine a
Message 2 of 6 , Mar 14, 2002
On Thu, Mar 14, 2002 at 11:34:42AM +1100, Peter Horan wrote:
> I was looking at this last night and wondered why I had written code
> which assumed
> subarray (min, max: INTEGER): like Current
> rather than
> subarray (min, max: INTEGER): ARRAY [G]
>
> Apart from the name, why should the result not be anchored to Current?

Because subARRAY is supposed to be an ARRAY. Current might not be an
ARRAY anymore. Also the parameters min, max might not be enough to
determine a subpart of Current but will allways be enough to determine
a subarray of Current viewed as/abstracted to an ARRAY.

Of course a part of current that when viewed as an array is the
subarray in question would do the job in most cases. But with the
name subARRAY, that specifies the result type, a developer should not
non-ARRAY properties under this operation. In fact the additional
properties might become worthless as they are not specified with ARRAY
and properties that behave arbitrarily are better not to have at all.

My view would be that a function with a type name A in its name should
always return an object of type A. If it is further implied that the
object type the function is called on (lets call it B) has a specific
type, the the function should behave excatly as if it was called on
Current abstracted to type B, i.e.

C.<operation_on_B>_<with_resulttype_A>

should fists abstract/convert C to B and then return an A
as if it was called on the B. (I am mixing types and objects here,
but I think it gets the point across.) One huge benefit is that
these operations do not need to be reimplemented in a child class!

On a related issue, I don't remember whether I argued against
"substring" in STRING returning a Current (which I think is wrong).
This is just a thing that might have been too longstanding to change.

My view would be that "substring" must return a STRING (no harm in the
present situation, except that implementors of subclasses have to make
arbitrary decision, reimplement the feature and possible
inefficiencies may arise) and that an operation that returns a Current
should be called subcurrent or here subsequence or sub<Type of
Current> (e.g. subcoloredstring).

With ARRAY it is somewhat easier, as an ARRAY is usually not
supposed to have additional properties that are not tied
to individual elements and elements are free with regard to
their type (given a general enough type parameter).

Overall my position is that if a function implies a result and/or
argument type it must operate and return these types, abstracting a
more general argument if needed before executing the operation.

Arno
--
Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@...
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F

A modern US Navy cruiser now requires 26 tons of manuals. This is enough to
affect the vessel's performance. -- New Scientist on the paperless office
• ... Ooh ooh! I know! (he said, waving his hand in the air like a fool.) What if you ve subclassed from ARRAY, say ARRAY_WITH_FISHING_POLE? Then in the second
Message 3 of 6 , Mar 14, 2002
>
> I was looking at this last night and wondered why I had written code
> which assumed
> subarray (min, max: INTEGER): like Current
> rather than
> subarray (min, max: INTEGER): ARRAY [G]
>
> Apart from the name, why should the result not be anchored to Current?

Ooh ooh! I know! (he said, waving his hand in the air like a fool.) What
if you've subclassed from ARRAY, say ARRAY_WITH_FISHING_POLE? Then in the
second case, shouldn't subarray return an ARRAY_WITH_FISHING_POLE type? So
the function should be anchored to Current, right?

Greg

=====
http://www.geocities.com/gmc444/gregs.html
Apologies for the stupid Yahoo ad below.

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/
• ... Ha, ha! (Another fool here!) But what if (min,max) is not enough to specify the part of the FISHING_POLE? Or if a FISHING_POLE makes the concept of a
Message 4 of 6 , Mar 14, 2002
On Thu, Mar 14, 2002 at 09:52:28AM -0800, Greg C wrote:
> >
> > I was looking at this last night and wondered why I had written code
> > which assumed
> > subarray (min, max: INTEGER): like Current
> > rather than
> > subarray (min, max: INTEGER): ARRAY [G]
> >
> > Apart from the name, why should the result not be anchored to Current?
>
> Ooh ooh! I know! (he said, waving his hand in the air like a fool.) What
> if you've subclassed from ARRAY, say ARRAY_WITH_FISHING_POLE? Then in the
> second case, shouldn't subarray return an ARRAY_WITH_FISHING_POLE type? So
> the function should be anchored to Current, right?

Ha, ha! (Another fool here!) But what if (min,max) is not enough to
specify the part of the FISHING_POLE? Or if a FISHING_POLE makes the
concept of a sub-ARRAY_WITH_FISHING_POLE completely meaningless
because a part of a FISHING_POLE is not a FISHING_POLE anymore? (As
everybody can see by breaking a fishing pole into parts...) If you
ignore the FISHING_POLE the subarraying still works!

Arno
--
Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@...
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F

A modern US Navy cruiser now requires 26 tons of manuals. This is enough to
affect the vessel's performance. -- New Scientist on the paperless office
• Hi, I m back now, and will aim to address all outstanding issues raised in this group (eventually). After that, I ll need to hand over to someone else because
Message 5 of 6 , Mar 21, 2002
Hi, I'm back now, and will aim to address all outstanding issues raised
in this group (eventually).

After that, I'll need to hand over to someone else because I'm about to
start on a new project that will be very demanding.

On 14 March, Peter Horan wrote:

> I ... wondered why I had written code which assumed
> subarray (min, max: INTEGER): like Current
> rather than
> subarray (min, max: INTEGER): ARRAY [G]
>
> Apart from the name, why should the result not be anchored to Current?

The confusion is my fault, because I have not managed to keep all the web
pages up-to-date.

Last year, we carefully went through the result types of all functions in
STRING and ARRAY, and changed several of them to "like Current",
including the result type of 'subarray'.

The details of this proposal, and the vote, are here:

http://www.eiffel-nice.org/standards/wip/array/elks2002changes.html

However, not all of those changes have yet been applied to the "Draft
ELKS 2002 ARRAY" page, which is here:

http://www.eiffel-nice.org/standards/wip/array/array2002proposal.txt

I'll apply all the outstanding changes in the next few days, and post a

Following Peter's comment of March 14, some discussion ensued. Arno
posted a carefully-argued case for having a signature of "ARRAY[G]", but
I won't quote it in this message because it's summarised by the following
exchange between Greg and Arno.

Greg C wrote:

> Ooh ooh! I know! (he said, waving his hand in the air like a fool.) What
> if you've subclassed from ARRAY, say ARRAY_WITH_FISHING_POLE? Then in the
> second case, shouldn't subarray return an ARRAY_WITH_FISHING_POLE type? So
> the function should be anchored to Current, right?

Arno Wagner replied:

> Ha, ha! (Another fool here!) But what if (min,max) is not enough to
> specify the part of the FISHING_POLE? Or if a FISHING_POLE makes the
> concept of a sub-ARRAY_WITH_FISHING_POLE completely meaningless
> because a part of a FISHING_POLE is not a FISHING_POLE anymore? (As
> everybody can see by breaking a fishing pole into parts...) If you
> ignore the FISHING_POLE the subarraying still works!

When we discussed this (prior to the September 2001 vote), both of these
situations were considered.

A subclass of ARRAY or STRING might add a new attribute. There are two
possibilities:

(P1) The new attribute is a single object or value that relates to the
entire ARRAY or STRING sequence

(P2) The new attribute is itself a data structure with multiple
components each of which relates to some part of the ARRAY or STRING
sequence

Suppose we have a descendant of STRING. If that descendant adds a
belongs, then we have an example of (P1). If, on the other hand, the
descendant adds an ARRAY[FONT] to indicate the FONT to be used for each
CHARACTER, then we have an example of (P2).

In last year's discussions it was decided that case (P1) is likely to be
much more common than case (P2), and that we should design ARRAY and
STRING so that the minimum of redefinition is required in case (P1).
Furthermore, we felt that a general solution was available for (P1), but
not for (P2).

the functions 'string' and 'array' to classes STRING and ARRAY
respectively. When inherited into a proper descendant of STRING or ARRAY,
these functions return the ARRAY or STRING sequence as an object of type
STRING or ARRAY (and therefore without any attributes added by the
descendant).

So, to recap. Peter Horan was assuming this signature:

subarray (min, max: INTEGER): like Current

and this is what is intended for ELKS 2002 ARRAY. Arno preferred this
signature:

subarray (min, max: INTEGER): ARRAY [G]

and can achieve the same effect in ELKS 2002 ARRAY by calling
"foo.array.subarray(min, max)" instead of "foo.subarray(min, max)".

This might all seem rather arbitrary ("Nero fiddling while Rome burns,
etc"). But the driving force behind the September 2001 changes was not to
fiddle with the signatures. It was to make descendants of STRING and
ARRAY usable. The mixture of signatures in ELKS95 was unworkable in
descendants, as many postconditions failed in the descendant classes. We
_had_ to make the signatures consistent, and as part of that process we
had to decide whether to choose a solution that facilitated (P1) or (P2)
above. We chose the solution that facilitated (P1).

This stuff is buried in the archives, and it is not easy to reconstuct
the historical train-of-thought. Ideally, someone will write an
"Annotated ELKS" document that explains all the design decisions. But
that will be a big job.

Regards,
Roger
--
Roger Browne - roger@... - Everything Eiffel
19 Eden Park Lancaster LA1 4SJ UK - Phone +44 1524 32428
• ... [...] ... [...] ... Actually I did not remember we discussed it already. If P1 is really more, likely a result of Current is indeed more useful. Let s
Message 6 of 6 , Mar 22, 2002
On Thu, Mar 21, 2002 at 09:26:40PM +0000, Roger Browne wrote:
> Hi, I'm back now, and will aim to address all outstanding issues raised
> in this group (eventually).
[...]
> Greg C wrote:
>
> > Ooh ooh! I know! (he said, waving his hand in the air like a fool.) What
> > if you've subclassed from ARRAY, say ARRAY_WITH_FISHING_POLE? Then in the
> > second case, shouldn't subarray return an ARRAY_WITH_FISHING_POLE type? So
> > the function should be anchored to Current, right?
>
> Arno Wagner replied:
>
> > Ha, ha! (Another fool here!) But what if (min,max) is not enough to
> > specify the part of the FISHING_POLE? Or if a FISHING_POLE makes the
> > concept of a sub-ARRAY_WITH_FISHING_POLE completely meaningless
> > because a part of a FISHING_POLE is not a FISHING_POLE anymore? (As
> > everybody can see by breaking a fishing pole into parts...) If you
> > ignore the FISHING_POLE the subarraying still works!
>
> When we discussed this (prior to the September 2001 vote), both of these
> situations were considered.
>
> A subclass of ARRAY or STRING might add a new attribute. There are two
> possibilities:
>
> (P1) The new attribute is a single object or value that relates to the
> entire ARRAY or STRING sequence
>
> (P2) The new attribute is itself a data structure with multiple
> components each of which relates to some part of the ARRAY or STRING
> sequence
[...]
> This might all seem rather arbitrary ("Nero fiddling while Rome burns,
> etc"). But the driving force behind the September 2001 changes was not to
> fiddle with the signatures. It was to make descendants of STRING and
> ARRAY usable. The mixture of signatures in ELKS95 was unworkable in
> descendants, as many postconditions failed in the descendant classes. We
> _had_ to make the signatures consistent, and as part of that process we
> had to decide whether to choose a solution that facilitated (P1) or (P2)
> above. We chose the solution that facilitated (P1).
>
> This stuff is buried in the archives, and it is not easy to reconstuct
> the historical train-of-thought. Ideally, someone will write an
> "Annotated ELKS" document that explains all the design decisions. But
> that will be a big job.

Actually I did not remember we discussed it already.
If P1 is really more, likely a result of Current is
indeed more useful.

Let's revisit this for ELKS2010 though!

Regards,
Arno

--
Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@...
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F

A modern US Navy cruiser now requires 26 tons of manuals. This is enough to
affect the vessel's performance. -- New Scientist on the paperless office
Your message has been successfully submitted and would be delivered to recipients shortly.