Welcome Guest Search | Active Topics | Log In | Register

Constructors & destructors
#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:


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
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

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

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

Thanks: 0 times
Was thanked: 82 time(s) in 63 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).

Follow me on Twitter @squirrellang
#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)

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.

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

Groups: Registered, Moderator
Joined: 3/26/2015(UTC)
Posts: 66
Location: Georgia

Thanks: 3 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
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
if(typeof obj != "null")
#5 Posted : Saturday, June 11, 2016 1:01:41 PM(UTC)
Rank: Advanced Member

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

Thanks: 3 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
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.045 seconds.