OpenEuphoria

1. Ticket #937: assigning to integer destroys the object prematurely

• Posted by ChrisB (moderator) Nov 24, 2022
• 2202 views

Hi

https://openeuphoria.org/ticket/937.wc

This raised a ton of questions for me

include std/io.e  
include std/error.e  
include std/unittest.e  
  
type enum boolean T,F=0 end type  
  
boolean enable_my_close = F  
  
procedure my_close(integer fh)  
    if fh > io:STDERR then  
    	printf(io:STDERR, "Closing file %d\n", {fh})  
    	if not enable_my_close then  
    		crash("premature file closing")  
    	end if  
        close(fh)  
    end if  
end procedure  
  
integer f_debug = open("example.log", "w")  
if f_debug =-1 then  
	f_debug = open("/dev/null", "w")  
  	puts(io:STDERR, "Unable to create log file.")  
else  
    f_debug = delete_routine(f_debug, routine_id("my_close"))  
end if  
  
enable_my_close = T  
  
test_report() 
 

My interpretation of this is :

• call a routine with an integer as the first paremeter.
• the way it should work is the integer is passed (in this case f_debug), enacted, and then cleaned up afterwards
• the way the ticket implies it's working is that the integer is cleaned up straight away.
• this is beacause the integer has at some point had something called a destructor added to it
• and when this is present in this instance destroys the integer immediately on calling the routine.

Please correct me.

Is this still relevent?
Has it been fixed?
Why would anyone want to call a routine this way?

3. Re: Ticket #937: assigning to integer destroys the object prematurely

• Posted by SDPringle Nov 30, 2022
• 1420 views

In the end this was the quickest path to something that didn't just malfunction without an explanation. You're right. I was supposed to make huge changes so this would simply work in a way so that the file handle destructor wouldn't get called until the program ended and the behavior of ending the program with this error message was supposed to be temporary, like income taxes were supposed to be temporary.

The task of getting the destructors to delay themselves in this circumstance only turned out to be far too great for me in the end.

5. Re: Ticket #937: assigning to integer destroys the object prematurely

• Posted by ghaberek (admin) Nov 30, 2022
• 1375 views

Honestly I think that's too great of a challenge to try implementing anyway. I'd rather leave it as-is and then focus on a different approach to implement classes and structures which can have more "proper" destructors instead.

-Greg