Remove feature to_c

Proposal

Remove feature 'to_c' from ELKS 2000.

History

Here's its specification in ELKS 1995:

   to_c: POINTER
      -- Address of actual sequence of values, 
      -- for passing to external (non-Eiffel) routines.

That's how it's already implemented by VE, which additionally offers the same feature under the name to_external. SE also uses the name to_external, and provides a few more details in the specification:

   to_external: POINTER
      --  Gives C access into the internal storage of the ARRAY.
      --  Result is pointing the element at index lower.
      --  
      --  NOTE: do not free/realloc the Result. Resizing of the array 
      --        can makes this pointer invalid. 
      require
         not empty
      ensure
         Result.is_not_null

ISE and HACT implement to_c with a result type of ANY.

An additional detail that is not directly relevant to to_c, but may have some bearing on this discussion, is that VE also offers from_c as follows:

   from_c (ptr : POINTER; cnt : INTEGER) is
      -- Creates array from its external representation
   require
      non_void_pointer : ptr /= default_pointer;
      valid_count      : cnt >= 0

In the TOOLS 99 working group's proposal, it was suggested that this feature be renamed to to_external for ELKS 2000, as follows:

   to_external: POINTER
      -- Address of the storage area containing the actual sequence
      -- of elements, to be passed to some external (non-Eiffel) routine.
      -- Keep in mind that this storage area is subject to garbage
      -- collection.

There was some discussion last year regarding the corresponding feature in STRING, in which there was support for non-ELKS solutions (such as letting the "external" clause sort it out, or adding new non-kernel "helper" classes).

Impact of proposed change

Low. Vendors may continue to support their existing implementations of to_c and to_external.

Results

The proposal was accepted.

votes cast at eGroups:

Strongly accept the proposal
                franck.arnau-@omgroup.com
Accept the proposal
                sparke-@eiffel.ie
                richie-@netlabs.net
                simonwillcock-@enterprise.net
                eric-@gobosoft.com
                tkin-@insystems.com
                gmc33-@my-deja.com
                wagne-@ti.uni-trier.de
                jweiric-@one.net
                jc-@rh.edu
                stimul-@shadow.net
                kwaxe-@aha.ru
Don't mind (happy either way)
                joachim.durchhol-@halstenbach.de
Reject the proposal
                genep-@sympatico.ca
                manu-@eiffel.com
Strongly reject the proposal
                saunder-@wchat.on.ca
Abstain (not happy either way)
                sergei_ivano-@object-tools.com
                steinma-@sco.edu

votes sent by email:

Don't mind (happy either way):
Ulrich Windl

Comments

Emmanuel Stapf (manu-@eiffel.com) writes:

The reason why I decided to vote against the proposal is because we feel
that we need `to_c' (or whatever name it has) in the standard to communicate
with the external world made of non-Eiffel software.
Unfortunately, the impact of the type of GC on `to_c' is too high to have
the same specification. The current implementation of ISE and Halstenbach
returning something of type `ANY' and then applying the `$' operator could
be easily implemented by other vendors.
So I would like to have two level of `to_c':
- to_c_low_level: returns an object of type ANY which is a direct reference
to raw data.
- to_c_high_level: as described by Alexander from Object Tools in his
message from February, 4th, I like his idea of `store_to_external'.
To summarize, I wanted to say that we cannot remove such a functionality
from a standard that needs it to be taken seriously by external people to
Eiffel.
Hope this clarifies our position