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

dispose in small eiffel?

Expand Messages
  • Fritz Heinrichmeyer
    Is there support for finalisation in SmallEiffel (for external resources)? -- Fritz Heinrichmeyer mailto:fritz.heinrichmeyer@fernuni-hagen.de FernUniversitaet
    Message 1 of 14 , Dec 4, 1998
    • 0 Attachment
      Is there support for finalisation in SmallEiffel (for external resources)?
      --
      Fritz Heinrichmeyer mailto:fritz.heinrichmeyer@...
      FernUniversitaet Hagen, LG Elektronische Schaltungen, 58084 Hagen (Germany)
      tel:+49 2331/987-1166 fax:987-355 http://ES-sun1.fernuni-hagen.de/~jfh
      PGP fingerprint (mail for key): 160BDF84 3F2F63C0 5CA20D31 3E42D116
    • Peter Hegt
      ... Just inherit MEMORY and redefine dispose. You are right in that this facility should be used only to free external resources. Regards, Peter Hegt, drs.
      Message 2 of 14 , Dec 4, 1998
      • 0 Attachment
        >> Is there support for finalisation in SmallEiffel (for external
        >> resources)?

        Just inherit MEMORY and redefine dispose.

        You are right in that this facility should be used only to free external
        resources.

        Regards,

        Peter Hegt, drs. Informatica
        Technical Consultant
        EXA Information Technology / Solution Development
        PeterH at EXA dot NL
        Current assignment phegt at baan dot nl
        Do not send junk mail
      • Olivier Zendra
        ... No. External resources have to be finalized externally :-) -- Olivier ZENDRA E-mail: zendra@loria.fr LORIA - NANCY - FRANCE
        Message 3 of 14 , Dec 4, 1998
        • 0 Attachment
          Fritz Heinrichmeyer a écrit :
          >
          > Is there support for finalisation in SmallEiffel (for external resources)?

          No. External resources have to be finalized externally :-)

          --
          Olivier ZENDRA E-mail: zendra@...
          LORIA - NANCY - FRANCE http://www.loria.fr/SmallEiffel
        • Fritz Heinrichmeyer
          As the subject says, i already found dispose in OOSC, but it is only mentioned once in the SmallEiffel-source and a comment in memory_e states : --
          Message 4 of 14 , Dec 4, 1998
          • 0 Attachment
            As the subject says, i already found "dispose" in OOSC, but it is only
            mentioned once in the SmallEiffel-source and a comment in memory_e
            states :

            -- Finalization is not yet implemented.

            Also i think somewhere in the code it should have been referenced.

            --
            Fritz Heinrichmeyer mailto:fritz.heinrichmeyer@...
            FernUniversitaet Hagen, LG Elektronische Schaltungen, 58084 Hagen (Germany)
            tel:+49 2331/987-1166 fax:987-355 http://ES-sun1.fernuni-hagen.de/~jfh
            PGP fingerprint (mail for key): 160BDF84 3F2F63C0 5CA20D31 3E42D116
          • Olivier Zendra
            ... Yes, finalization is not implemented yet. -- Olivier ZENDRA E-mail: zendra@loria.fr LORIA - NANCY - FRANCE
            Message 5 of 14 , Dec 4, 1998
            • 0 Attachment
              Fritz Heinrichmeyer a écrit :
              >
              > As the subject says, i already found "dispose" in OOSC, but it is only
              > mentioned once in the SmallEiffel-source and a comment in memory_e
              > states :
              >
              > -- Finalization is not yet implemented.

              Yes, finalization is not implemented yet.

              --
              Olivier ZENDRA E-mail: zendra@...
              LORIA - NANCY - FRANCE http://www.loria.fr/SmallEiffel
            • Dominique Colnet
              ... Ooops ... I have just removed this comment in my working version because MEMORY.dispose is now implemented in the available latest beata release
              Message 6 of 14 , Apr 28, 1999
              • 0 Attachment
                >>>>> "Fritz" == Fritz Heinrichmeyer <fritz.heinrichmeyer@...> writes:
                > As the subject says, i already found "dispose" in OOSC, but it is only
                > mentioned once in the SmallEiffel-source and a comment in memory_e
                > states :
                > -- Finalization is not yet implemented.
                Ooops ... I have just removed this comment in my working version
                because MEMORY.dispose is now implemented in the available
                latest beata release (-0.78Beta#5).
                See :

                http://SmallEiffel.loria.fr/misc/HISTORY.html

                We know that this feature is very important for many software.
                BTW, our students are using the nice eiffel-gtk from Paul C. Janzen
                and Francois Pennaneach available at :

                http://www.primenet.com/~pcj/eiffel-gtk/

                Hope Paul C. Janzen will keep up the good work by using the very new
                MEMORY.dispose.
                This is also true for other GUI.
                Thanks to all.
                --------------------------------------------------------------
                Dominique COLNET -- UHP (Nancy 1) -- LORIA -- INRIA Lorraine
                http://SmallEiffel.loria.fr -- The GNU Eiffel Compiler
                POST: Loria, B.P. 239,54506 Vandoeuvre les Nancy Cedex, FRANCE
                EMAIL: colnet@... Voice:+33 0383593079 Fax:+33 0383413079
              • Alain Le Guennec
                ... I have a [comment/question/bug-report] about MEMORY::dispose, regarding (once again :) expanded managed object. I am wondering whether dispose should be
                Message 7 of 14 , Apr 28, 1999
                • 0 Attachment
                  Dominique Colnet <Dominique.Colnet@...> writes:

                  > Ooops ... I have just removed this comment in my working version
                  > because MEMORY.dispose is now implemented in the available
                  > latest beata release (-0.78Beta#5).

                  I have a [comment/question/bug-report] about MEMORY::dispose,
                  regarding (once again :) expanded "managed" object.
                  I am wondering whether dispose should be called
                  when such expanded objects are destroyed
                  (when the stack is unwound and they hence go out of scope.)
                  I guess the answer should be yes, but ELKS'95 is
                  a little bit ambiguous, as it refers to garbage collection
                  -- Action to be executed just before garbage collection
                  -- reclaims an object.
                  and I don't know whether simple "stack-unrolling"
                  is considered a part of the whole GC mecanism or not.

                  Anyway, here is a little test case which shows that
                  dispose is not called on reclamation of expanded objects.
                  - ---------------------------------------
                  class DUMMY
                  inherit MEMORY redefine dispose end
                  feature
                  dispose is
                  do
                  print ("Dispose was called!%N")
                  end
                  end
                  - ---------------------------------------
                  class ROOT_CLASS
                  creation make
                  feature
                  make is
                  local
                  d : dummy
                  e : expanded dummy
                  do
                  !!d
                  end
                  end
                  - ---------------------------------------
                  On execution, the string literal is printed only once :(

                  Thanks to the SE team for this new useful feature anyway!
                  Regards,
                  --
                  Alain Le Guennec, not speaking for IRISA.
                • Eric Bezault
                  ... This is my opinion as well. `dispose is an elegant means to deallocate external resources. It would be a shame if this mechanism doesn t work with
                  Message 8 of 14 , Apr 28, 1999
                  • 0 Attachment
                    > I have a [comment/question/bug-report] about MEMORY::dispose,
                    > regarding (once again :) expanded "managed" object.
                    > I am wondering whether dispose should be called
                    > when such expanded objects are destroyed
                    > (when the stack is unwound and they hence go out of scope.)
                    > I guess the answer should be yes,

                    This is my opinion as well. `dispose' is an elegant means to
                    deallocate external resources. It would be a shame if this
                    mechanism doesn't work with expanded objects. We would have
                    to use some other clumsy solution. And it would be strange
                    and error-prone to have two different finalization mechanisms
                    depending on whether an object has been declared expanded
                    or not.

                    --
                    Eric Bezault
                    mailto:ericb@...
                    http://www.gobo.demon.co.uk
                  • Olivier Zendra
                    ... Indeed. If fact, this comment is clearly not precise enough, since garbage collection seems to imply that the answer to your question should be no , but
                    Message 9 of 14 , Apr 28, 1999
                    • 0 Attachment
                      Alain Le Guennec a écrit:
                      > I am wondering whether dispose should be called
                      > when such expanded objects are destroyed
                      > (when the stack is unwound and they hence go out of scope.)
                      > I guess the answer should be yes, but ELKS'95 is
                      > a little bit ambiguous, as it refers to garbage collection
                      > -- Action to be executed just before garbage collection
                      > -- reclaims an object.

                      Indeed. If fact, this comment is clearly not precise enough, since
                      "garbage collection" seems to imply that the answer to your question
                      should be "no", but "an object" seems to also include expanded objects,
                      so the answer would be "yes"...

                      Eric Bezault a écrit :
                      > This is my opinion as well. `dispose' is an elegant means to
                      > deallocate external resources. It would be a shame if this
                      > mechanism doesn't work with expanded objects. We would have
                      > to use some other clumsy solution. And it would be strange
                      > and error-prone to have two different finalization mechanisms
                      > depending on whether an object has been declared expanded
                      > or not.

                      We agree (and thus we consider our beta5 features an incomplete dispose
                      mechanism).

                      Anyway, we'll implement dispose in the most standard way. Since ELKS'95
                      is no specific enough about this, what do other compilers do ?

                      --
                      Olivier ZENDRA E-mail: zendra@...
                      LORIA - NANCY - FRANCE http://SmallEiffel.loria.fr
                    • Alain Le Guennec
                      Re-reading what I wrote gave me an idea for another vicious test-case for finalization, for instance writing a once dispose routine... With SE, a once
                      Message 10 of 14 , Apr 28, 1999
                      • 0 Attachment
                        Re-reading what I wrote gave me an idea
                        for another "vicious" test-case for finalization,
                        for instance writing a "once" dispose routine...
                        With SE, a "once" dispose routine is not called,
                        as shown by the following test-case :
                        - -----------------------------------------
                        class DUMMY
                        inherit MEMORY redefine dispose end
                        feature
                        dispose is
                        once
                        count.set_item(count.item + 1)
                        print ("Dispose was called!%N")
                        end
                        count : INTEGER_REF is
                        once
                        !!Result
                        end
                        end
                        - -----------------------------------------
                        class ROOT_CLASS
                        creation make
                        feature
                        make is
                        local
                        d : dummy
                        do
                        !!d
                        !!d
                        !!d
                        d.full_collect
                        print (d.count.out)
                        end
                        end
                        - -----------------------------------------
                        I expected this program would print:
                        Dispose was called!
                        1

                        But it just prints 0

                        Replacing the once of dispose by a do, one obtains:
                        Dispose was called!
                        Dispose was called!
                        2Dispose was called!
                        (as expected, even if the last call to dispose
                        has undefined behavior in theory, as the I/O stuff
                        and even the 'count' could already be finalized
                        and reclaimed at that moment...)

                        I admit that this test-case is a rather contrived one,
                        but I like to investigate the possible side-effects of new features :)
                        (now I still have to find a use for a "once" dispose routine...)

                        Alain

                        Eric Bezault <ericb@...> writes:

                        > > I have a [comment/question/bug-report] about MEMORY::dispose,
                        > > regarding (once again :) expanded "managed" object.
                        > > I am wondering whether dispose should be called
                        > > when such expanded objects are destroyed
                        > > (when the stack is unwound and they hence go out of scope.)
                        > > I guess the answer should be yes,
                        >
                        > This is my opinion as well. `dispose' is an elegant means to
                        > deallocate external resources. It would be a shame if this
                        > mechanism doesn't work with expanded objects. We would have
                        > to use some other clumsy solution. And it would be strange
                        > and error-prone to have two different finalization mechanisms
                        > depending on whether an object has been declared expanded
                        > or not.
                        >
                        > --
                        > Eric Bezault
                        > mailto:ericb@...
                        > http://www.gobo.demon.co.uk
                        >
                      • Alain Le Guennec
                        ... [SNIP] ... I just made a few tests with ISE-Eiffel 4.2F and 4.3: ISE Eiffel _does_ call dispose for expanded objects _of the stack_ when they go out of
                        Message 11 of 14 , Apr 28, 1999
                        • 0 Attachment
                          Olivier Zendra <Olivier.Zendra@...> writes:

                          > > I guess the answer should be yes, but ELKS'95 is
                          > > a little bit ambiguous, as it refers to garbage collection
                          > > -- Action to be executed just before garbage collection
                          > > -- reclaims an object.
                          [SNIP]
                          > Anyway, we'll implement dispose in the most standard way. Since ELKS'95
                          > is no specific enough about this, what do other compilers do ?

                          I just made a few tests with ISE-Eiffel 4.2F and 4.3:

                          ISE Eiffel _does_ call dispose for expanded objects
                          _of the stack_ when they go out of scope.
                          However, dispose is not called for expanded attributes
                          of (enclosing) reclaimed objects.
                          But should it? I really don't know :(
                          Maybe I should send them a bug-report :)

                          Here is the example I tried with ISE Eiffel:
                          - -------------------------------------------------
                          class DUMMY
                          inherit MEMORY redefine dispose end
                          feature
                          dispose is
                          do
                          print ("Dispose of DUMMY was called!%N")
                          end
                          d2 : expanded DUMMY2
                          end
                          - -------------------------------------------------
                          class DUMMY2
                          inherit MEMORY redefine dispose end
                          feature
                          dispose is
                          do
                          print ("Dispose of DUMMY2 was called!%N")
                          end
                          i : INTEGER
                          end
                          - -------------------------------------------------
                          class ROOT_CLASS
                          creation make
                          feature
                          make is
                          local
                          d : DUMMY
                          e : expanded DUMMY
                          do
                          !!d
                          print (d.d2.i)
                          print (e.d2.i)
                          end
                          end
                          - -------------------------------------------------
                          The result I obtained was:
                          00Dispose of DUMMY was called!
                          Dispose of DUMMY was called!

                          So it seems DUMMY2::dispose is never called.

                          I think we are in a grey area of the Eiffel language definition,
                          which needs to be made clearer.
                          IMHO, DUMMY2::dispose should be called though,
                          if only for symmetry with the fact that a parameterless
                          creation routine would be called at initialization.

                          There is still the case of expanded formal parameters to consider,
                          as they involve a clone-like semantics.

                          Regards,
                          --
                          Alain Le Guennec, not speaking for IRISA.
                        • Dave E Martin XXIII
                          You may want to bring this up over on the NICE discussion list, as something to be considered. ... [...] ... I wouldn t put its (ISE compiler) current behavior
                          Message 12 of 14 , Apr 28, 1999
                          • 0 Attachment
                            You may want to bring this up over on the NICE discussion list, as something
                            to be considered.

                            Alain Le Guennec wrote:

                            > I just made a few tests with ISE-Eiffel 4.2F and 4.3:
                            >
                            > ISE Eiffel _does_ call dispose for expanded objects
                            > _of the stack_ when they go out of scope.
                            > However, dispose is not called for expanded attributes
                            > of (enclosing) reclaimed objects.
                            > But should it? I really don't know :(
                            > Maybe I should send them a bug-report :)

                            [...]

                            > I think we are in a grey area of the Eiffel language definition,
                            > which needs to be made clearer.
                            > IMHO, DUMMY2::dispose should be called though,
                            > if only for symmetry with the fact that a parameterless
                            > creation routine would be called at initialization.

                            I wouldn't put its (ISE compiler) current behavior beyond being a bug.
                            Unfortunately, because of the grey area of this particular instance, they
                            could do the "convenient" thing instead of the "correct" thing. I would
                            hope that they woudn't though. I've found several bugs in the 4.3 compiler,
                            now if they would just say *something* about them. (I have no idea if i'm
                            throwing my bug reports into the wind or not, I hope not)


                            >
                            > There is still the case of expanded formal parameters to consider,
                            > as they involve a clone-like semantics.

                            Any word on the problem with clone on expanded objects that I reported?

                            <*> -- Know Future
                            We're whalers on the moon
                          • James Graves
                            ... Well, if you are developing a class that uses external resources, you probably should be redefining `twin and `copy to also duplicate the external
                            Message 13 of 14 , Apr 28, 1999
                            • 0 Attachment
                              On Wed, 28 Apr 1999, Dave E Martin XXIII wrote:

                              > > There is still the case of expanded formal parameters to consider,
                              > > as they involve a clone-like semantics.
                              >
                              > Any word on the problem with clone on expanded objects that I reported?

                              Well, if you are developing a class that uses external resources, you
                              probably should be redefining `twin' and `copy' to also duplicate the
                              external resources. In this case, it would be proper to call `dispose'
                              after a procedure call with an expanded type parameter.

                              However, when last I was working on some code that used external
                              resources, it didn't occur to me that I should redefine `twin' and `copy'
                              to also duplicate the external resources. This notion has probably
                              slipped past some other programmers too. In that case, if `dispose' was
                              run after a procedure call with a expanded type parameter, it would
                              destroy the one and only copy of the external resource.

                              However, I don't think that implementing `dispose' for procedure calls
                              will break any existing code... how often do people use expanded types
                              for complex objects anyway? If it wasn't for INTEGER and such, I
                              wouldn't use expanded types at all.

                              So I think `dispose' should be run in those cases. After the clone, it's
                              a completely separate object, with potentially it's own life. And we'll
                              just need to remind people that if they redefine `dispose' the probably
                              should be redefining `twin' and `copy' too.

                              Later,

                              James
                              _______________________________________________________________________________
                              http://www.xnet.com/~ansible I want Dexter's Laboratory.
                            • Dominique Colnet
                              ... expanded2 := clone(expanded1); does not work, but is much better written: expanded2 := expanded1; (which does work). There is a problem only when cloning
                              Message 14 of 14 , Apr 29, 1999
                              • 0 Attachment
                                >>>>> "Dave" == Dave E Martin XXIII <xxiii@...> writes:

                                > Any word on the problem with clone on expanded objects that I reported?

                                expanded2 := clone(expanded1);

                                does not work, but is much better written:

                                expanded2 := expanded1;

                                (which does work).

                                There is a problem only when cloning generic arguments for which the
                                "expandedness" status is not known.

                                So this bug is in our to do list with a low level of priority.


                                Dominique and Olivier

                                --------------------------------------------------------------
                                Dominique COLNET -- UHP (Nancy 1) -- LORIA -- INRIA Lorraine
                                http://SmallEiffel.loria.fr -- The GNU Eiffel Compiler
                                POST: Loria, B.P. 239,54506 Vandoeuvre les Nancy Cedex, FRANCE
                                EMAIL: colnet@... Voice:+33 0383593079 Fax:+33 0383413079
                              Your message has been successfully submitted and would be delivered to recipients shortly.