Loading ...
Sorry, an error occurred while loading the content.
 

STRING 'remake'

Expand Messages
  • Roger Browne
    Let s now consider remake , which in ELKS95 looked like this: frozen remake (n: INTEGER) -- Allocate space for at least n characters. require
    Message 1 of 6 , Apr 30, 2001
      Let's now consider 'remake', which in ELKS95 looked like this:

      frozen remake (n: INTEGER)
      -- Allocate space for at least n characters.
      require
      non_negative_size: n >= 0
      ensure
      empty_string: count = 0

      In other words, 'remake' works like 'wipe_out', but has an extra
      'capacity' argument.

      Apart from the feature name, there's no difference between 'make' and
      'remake'. But 'make' is a creation feature, and 'remake' is a public
      feature that is not available for creation - only reinitialization.

      Although the specification of 'make' and 'remake' is the same, the
      implementation of 'make' could be simpler because it can assume that all
      fields have default initialization. However, SmallEiffel does not
      implement 'remake' SE exports 'make' so that it can be used for
      reinitialization.

      Here are the current implementations. As with 'make', the current VE
      semantics differs from that of ISE/HACT (the VE postcondition is "count =
      n").

      ISE/HACT:

      remake (n: INTEGER)
      -- Allocate space for at least n characters.
      require
      non_negative_size: n >= 0
      ensure
      empty_string: count = 0;
      area_allocated: capacity >= n

      VE:

      frozen remake (n : INTEGER) is
      -- Allocate space for at least 'n' characters
      require
      non_negative_size : n >= 0
      ensure
      empty_string : count = n

      Here's how 'remake' might look if specified in a way that matches the
      recently-approved specifications of 'make' and 'wipe_out':

      30 APRIL 2001 VERSION:

      remake (suggested_capacity: INTEGER)
      -- Remove all characters.
      require
      non_negative_suggested_capacity: suggested_capacity >= 0
      ensure
      empty_string: count = 0

      Does anyone have any other solution that they would like to have
      considered?

      Regards,
      Roger
      --
      Roger Browne - roger@... - Everything Eiffel
      19 Eden Park Lancaster LA1 4SJ UK - Phone +44 1524 32428
    • Ulrich Windl
      I think we do not need remake . Other opinions? ... [...]
      Message 2 of 6 , May 1, 2001
        I think we do not need "remake". Other opinions?

        On 30 Apr 2001, at 17:38, Roger Browne wrote:

        > Let's now consider 'remake', which in ELKS95 looked like this:
        >
        > frozen remake (n: INTEGER)
        > -- Allocate space for at least n characters.
        > require
        > non_negative_size: n >= 0
        > ensure
        > empty_string: count = 0
        >
        > In other words, 'remake' works like 'wipe_out', but has an extra
        > 'capacity' argument.
        [...]
      • Simon Parker
        Good morning.Is there a way to ensure make is only available for creation? We didn t give it any preconditions and it s a public feature, so I think not.
        Message 3 of 6 , May 2, 2001
          Good morning.

          Is there a way to ensure 'make' is only available for creation? We didn't
          give it any preconditions and it's a public feature, so I think not.

          In that case, any implementation must be prepared to handle a call for an
          existing string, just like 'remake'.

          We can ensure 'remake' is not available for creation, simply by not listing
          it as a creation procedure. An implementation then has the advantage of
          knowing that the STRING's invariant holds on entry and (presumably) some
          capacity has been reserved. Can this knowledge be used to obtain some
          performance advantage?

          If so, then the extra feature is justified. Otherwise, it's not.

          By omitting it from the standard we wouldn't break existing code, but we
          would render it non-conforming.


          Regards,
          Simon

          Simon Parker +353 87 249 7859


          On Wednesday, May 02, 2001 7:23 AM, Ulrich Windl
          [SMTP:ulrich.windl@...-regensburg.de] wrote:
          > I think we do not need "remake". Other opinions?
          >
          > On 30 Apr 2001, at 17:38, Roger Browne wrote:
          >
          > > Let's now consider 'remake', which in ELKS95 looked like this:
          > >
          > > frozen remake (n: INTEGER)
          > > -- Allocate space for at least n characters.
          > > require
          > > non_negative_size: n >= 0
          > > ensure
          > > empty_string: count = 0
          > >
          > > In other words, 'remake' works like 'wipe_out', but has an extra
          > > 'capacity' argument.
          > [...]
          >
          >
          > ---------------------------
          >
          > http://www.eiffel-nice.org/
          >
          > --------------------------
          >
          > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
          >
        • Roger Browne
          ... Sure. We did this for ARRAY make . We made it a private creation feature. Presumably if remake is part of ELKS 2001 STRING, we will restrict the use of
          Message 4 of 6 , May 2, 2001
            Simon Parker wrote:

            > Is there a way to ensure 'make' is only available for creation?

            Sure. We did this for ARRAY 'make'. We made it a private creation
            feature.

            Presumably if 'remake' is part of ELKS 2001 STRING, we will restrict the
            use of 'make' to creation only.

            > We can ensure 'remake' is not available for creation, simply by not listing
            > it as a creation procedure. An implementation then has the advantage of
            > knowing that the STRING's invariant holds on entry and (presumably) some
            > capacity has been reserved. Can this knowledge be used to obtain some
            > performance advantage?

            I see that Visual Eiffel uses the same implementation for 'make' and
            'remake'. SmallEiffel exports 'make' so that it can also be used for
            reinitialization.

            ISE and HACT gain a small performance advantage for 'make' by avoiding
            the need to set 'count' to zero (because default initialization already
            guarantees this). For 'remake', ISE and HACT explicitly set 'count' to
            zero.

            > If so, then the extra feature is justified. Otherwise, it's not.

            I'm inclined to agree. The only reason for having 'make' in addition to
            'make_empty' is because of its potential for performance enhancement. If
            'make' is part of ELKS 2001, 'remake' probably should be too (and
            'resize' would complete the trio - but that's our next discussion!).

            Regards,
            Roger
            --
            Roger Browne - roger@... - Everything Eiffel
            19 Eden Park Lancaster LA1 4SJ UK - Phone +44 1524 32428
          • Arno Wagner
            ... I don t think it s necessary either. And I don t see a significant performance gain. Basically if the suggested capacity parameter has some effect, I would
            Message 5 of 6 , May 2, 2001
              On Wed, May 02, 2001 at 08:22:31AM +0200, Ulrich Windl wrote:
              > I think we do not need "remake". Other opinions?
              >
              I don't think it's necessary either. And I don't see a significant
              performance gain. Basically if the suggested capacity parameter has
              some effect, I would expect the overhead of creating a new STRING via
              "make" to be small. It is so in SE, as the run-time system will
              recycle object descriptors and keeps old unsused ones around for quick
              allocation.

              If the aim is to avoid reallocation of the storage then
              'wipe_out' surely is better, as it can leave the storage space
              entirely unchanged. And if time is critical, it would be perferrable
              not to change the STRING in any way, but just reuse the character
              positions and keep an additional, external length parameter (if
              needed). This would really be ugly, 'c' - like usage, but if speed
              is critical...

              So I don't see any need for having this feature and frankly I find
              it confusing. It takes some time to see that the only difference to
              "wipe_out" is the (possibly meaningless) suggested capacity
              parameter. I think it clutters the interface needlessly for a very
              questionable gain.

              Regards,
              Arno

              > On 30 Apr 2001, at 17:38, Roger Browne wrote:
              >
              > > Let's now consider 'remake', which in ELKS95 looked like this:
              > >
              > > frozen remake (n: INTEGER)
              > > -- Allocate space for at least n characters.
              > > require
              > > non_negative_size: n >= 0
              > > ensure
              > > empty_string: count = 0
              > >
              > > In other words, 'remake' works like 'wipe_out', but has an extra
              > > 'capacity' argument.
              > [...]
              >
              >
              > ---------------------------
              >
              > http://www.eiffel-nice.org/
              >
              > --------------------------
              >
              > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
              >

              --
              Arno Wagner Dipl. Inform. ETH Zuerich wagner@...
              GnuPG: ID: F0C049F1 FP: 8C E0 6F A5 CC B1 5A 11 ED C7 AD D2 05 5E BB 6F
              "What I saw in the Xerox PARC technology was the caveman interface, you point
              and you grunt. A massive winding down, regressing away from language, in
              order to address the technological nervousness of the user. Users wanted to
              be infantilized, to return to a pre-linguistic condition in the using of
              computers, and the Xerox PARC technology's primary advantage was that it
              allowed users to address computers in a pre-linguistic way. This was to my
              mind a terribly socially retrograde thing to do, and I have not changed my
              mind about that." Eben Moglen (http://old.law.columbia.edu for more by E.M.)
            • Berend de Boer
              ... remake is not a very clear name. And nobody is using it it seems :-) Groetjes, Berend. (-:
              Message 6 of 6 , May 4, 2001
                Roger Browne <egroups@...> writes:

                > I'm inclined to agree. The only reason for having 'make' in addition to
                > 'make_empty' is because of its potential for performance enhancement. If
                > 'make' is part of ELKS 2001, 'remake' probably should be too (and
                > 'resize' would complete the trio - but that's our next discussion!).

                remake is not a very clear name. And nobody is using it it seems :-)

                Groetjes,

                Berend. (-:
              Your message has been successfully submitted and would be delivered to recipients shortly.