YetAnotherForum
Welcome Guest Search | Active Topics | Log In | Register

Constructors & destructors
ats
#1 Posted : Saturday, April 5, 2008 12:12:38 PM(UTC)
Rank: Member

Groups: Registered
Joined: 1/17/2007(UTC)
Posts: 132

Thanks: 0 times
Was thanked: 2 time(s) in 2 post(s)

Here is some feedback relating to object construction:

1 - Constructors of base classes are not called automatically. I think it's quite natural for an instance of a derived class to call the appropriate base class ctor (one without args, if there is one):

class A {
constructor(){ println("A::constructor") }
}

class B extends A {

constructor(){ println("B::constructor") }
}

Instantiating B, I only get this message:

B::constructor


Shouldn't a base constructor (without args) be applied automatically here?


2 - Destructors. I find the whole concept of automatic invocation of constructors and destructor very useful for things beyond memory management. Things like automatic lockers, local option holder are possible then and gives a lot more safety than manually undoing an action.

Consider if we momentarily want to swap from case sensitive to case insenstive comparisons in a local scope. We have a flag:

g_case_sensitive <- true // Global flag

And inside a compare function:

function ComparableClass::_cmp( other ){
if( g_case_sensitive )
return // case sensitive cmp
else
return // case insensitive cmp
}

Then, if we have an 'option holder' class

class OptionHolder {
constructor( name, tmp_val ){
m_old_val = getroottable(name)
m_name = name
getroottable(name) = tmp_val
}
destructor( ){
getroottable(m_name) = m_old_val

}
m_name = null
m_old_val = null
}

we can do this:

{
local opt_cis = OptionHolder( "g_case_sensitive", false )
// Use ComparableClass::_cmp or any other func that
// depends on g_case_sensitive
}
// Back to normal / previous value automatically here


Regards
// ATS
fagiano
#2 Posted : Sunday, April 6, 2008 10:43:44 AM(UTC)
Rank: Advanced Member

Groups: Registered, Administrators
Joined: 6/11/2005(UTC)
Posts: 1,056

Thanks: 0 times
Was thanked: 78 time(s) in 60 post(s)
Hi, here's why

1. what happens if the base and the derived contructors have different number of parameters? if you find me a vieable solution this can be added. I've been thinking about it for a long time. The fact that a language as mature as python has the same "problem", tells me there isn't a more elegant solution than calling the contructor explicitly.

2. this a quite tricky problem implementation wise because in a ref counted/gc language the application could resurrect the object, this drags in endless problems. That's why only the C++ side can be notified about destruction of a class(after the class has already been deleted).

ciao
Alberto
Follow me on Twitter @squirrellang
ats
#3 Posted : Sunday, April 6, 2008 5:30:37 PM(UTC)
Rank: Member

Groups: Registered
Joined: 1/17/2007(UTC)
Posts: 132

Thanks: 0 times
Was thanked: 2 time(s) in 2 post(s)
Hello,

OK, that's a bit of explanation. Some thoughts:

1 - Use the base class constructor without args (provided it exists). That's how C++ does it.


2 - I see, if, from the destructor, one gives away a ref to 'this' it gets tricky. Idea:
- Destructor called when ref cnt goes to 0
- Some other object / function makes a ref to the object (not what we wanted)
- On completing the destructor function, object is:
--- recycled into free mem heap if ref cnt==0
--- changes type to null (or zombie) if there are refs around.

I see that 2 could complicate things a bit.


Regards
// ATS.
Kelvin
#4 Posted : Tuesday, June 7, 2016 1:28:23 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 3/26/2015(UTC)
Posts: 46
Man
Location: VA

Thanks: 2 times
Was thanked: 0 time(s) in 0 post(s)
For the destructor, I just have a function called del(), and when I want to delete an instance, I call that instead of using
Code:
delete object
. Then, in the del() function, I take care of everything a destructor would need to do, and just put "delete this" at the end.

I do like the idea of changing the type to null, and then anything pointing to that object could just have a check like
Code:
if(typeof obj != "null")
absence
#5 Posted : Saturday, June 11, 2016 1:01:41 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 8/23/2014(UTC)
Posts: 109
Man
Location: Northern Germany & Lincolnshire, U.K.

Thanks: 1 times
Was thanked: 10 time(s) in 10 post(s)
I fiddled around with destructors for years, and I managed to do it _almost_ properly.
It's quite complicated, unfortunately, and still has some downsides.

Destructors probably are THE most evil issue in Squirrel. After years I still don't know if it's perfectly doable at all.
(I'm a perfectionist, any solution MUST fit every aspect perfectly. Be sure If I ever find a way, I'll propose it to Alberto and it's then likely to make it into Squirrel itself)

Main issues left are runtime errors and exceptions within the destructor itself. Squirrel is a dynamic type language with automatic reference memory management. This requires that any destructor MUST NOT FAIL or at least throws a proper exception. And that, Ladies and Gentlemen, deems unfeasible without inventing a new language.


Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Clean Slate theme by Jaben Cargman (Tiny Gecko)
Powered by YAF 1.9.4 | YAF © 2003-2010, Yet Another Forum.NET
This page was generated in 0.143 seconds.