Is it worth having class constructors\destructors - if so how should they be designed ?

[wideofthemark]

Sorry - this is largly a stylistic question.....

I know that labview considers constructors/destructors to be 'implicit' - so the simple answer to the question is NO - unless there is some setting up or tidying up of references - eg to files/queues etc that needs to be done - perhaps a better word for these would be 'initialise, and de-initialise.

I guess what i'm really wondering is what is good practice.  I guess I have a vi - which when i have an error, it handles the error by de-initialising my classes, and then re-initialising them - to restart in a 'good' state. - so it is like a reset behaviour.

I started off using the notion of constructors and destructors - ie like 'queues' where there are some input variables in the constructor (but NO class - input) - which then passes out a initialised version of the class, and a destructor - which largely does the opposite.  The nice thing about this - is it is like the constructor and destructor 'book end' the use of the class - there are no hanging wires etc.  (and also its the sort of programming i'm used to).

I ran in to problems though - because i started using inheritance, and dynamic terminal really don't like this - since there is not a continuous wire from the beginning to the end.

Also inheritance doesn't like the idea of having 'init' vis with differing inputs for the various generations of the inheritance tree - which means they all have to be named for their specific class.

At the moment I'm on the point of re-engineering all the destructors so they are more like 'de-initialisers' - with class inputs and outputs. - But I was wondering what other people tend to do.

JP

[Mark_Yedinak]

ou can have different connector panes provided you don't use dynamic dispatch on those methods. Your code will have to explicitly use the correct instance of the child class. I actually like the concept of constructors and deconstructures. I feel that it makes the code more readable since there are explicit actions to create and destroy the instances of your objects.

[wideofthemark]

That was my thinking too.....- Though Like I say i have had a crisis of confidence recently - was just wanting to test the water before I change the paradigm

[wideofthemark]

Sorry - @Mark_Yedinak.... perhaps I'm mistaken - if you have two classes in an inheritance tree - and you have vis in each of them called the same name - then you get an error - 'this vi attempts to overide a static vi in an ancestor class... Neither vi has dynamic terminals.. - or do i need to set some setting somewhere to clear this up?

JP

[GregFreeman]

---

@wideofthemark wrote:

Sorry - @@Mark_Yedinak.... perhaps I'm mistaken - if you have two classes in an inheritance tree - and you have vis in each of them called the same name - then you get an error - 'this vi attempts to overide a static vi in an ancestor class... Neither vi has dynamic terminals.. - or do i need to set some setting somewhere to clear this up?

JP

---

You need to create dynamic terminals. If you open the VI in your parent class and right click the class on the connector pane, you can choose the option This Connection is -> Dynamic Dispatch Input (Required). Then you can override the VI (assuming you have the same connector pane on all children. By convension, I also make a create and destroy method for all my classes. My destroy methods are always created with "must call parent node" so it ensures all parent data is also destroyed.

[GregFreeman]

Also, fun fact. If you pass a child class into a parent class method like shown below, it actually will return a wire of child class type, not a child type riding on a parent wire. Notice, in context help the return type is Service, but it is actually returning a listener service This can be useful when creating "constructors" because you can call parent methods to initialize their values but still get the specific child wire returned.

[wideofthemark]

Thanks.... That makes a bit more sense. 

Just to be clear what i understand basically your paradigm is to have 'bare' constructor/destructors, with dynamic terminals, and without any other inputs?  (since if you have inputs then the connectors have to all match).  I guess they are not strictly constructors - in the sense of other languages - since you have to pass a constant to class to them.  I guess then to do any active initialisation you need dedicated class vis - with whatever other inputs necessary.

[GregFreeman]

---

@wideofthemark wrote:

Thanks.... That makes a bit more sense. 

Just to be clear what i understand basically your paradigm is to have 'bare' constructor/destructors, with dynamic terminals, and without any other inputs?  (since if you have inputs then the connectors have to all match).  I guess they are not strictly constructors - in the sense of other languages - since you have to pass a constant to class to them.  I guess then to do any active initialisation you need dedicated class vis - with whatever other inputs necessary.

---

My "destructors" are dyanmic dispatch with the only terminals being error clusters and the class itself. IMO (not from a programming background so maybe there are other cases) "destructors" shouldn't have any inputs other than the class itself. Your class being cleaned up shouldn't also be cleaning up things that aren't part of the class. Having additional terminals on the destructor implies the latter. 

My "constructors" are not dynamic dispatch so I can have different connector panes, and by convention I will call the parent "constructor" in the child's. I have also seen the dynamic dispatch method for constructors, but I haven't been sold on it, mostly because I haven't had the time to try both extensively and see which I like better. This may be one of those things where you ask 10 programmers and get 10 different answers. 

[wideofthemark]

Thanks.  I guess you are probably right about the destructors - shouldn't need inputs - although through bad design i probably do sometimes..... (I'm also a self taught programmer)

As for the constructors - in general i guess you would want inputs - otherwise you may as well just use the constants defined in the class variable as default.  I guess this is what i was calling 'initialisation' above - although at this point it is just really a case of semantics.  I think once you have other inputs on the constructor plane, you need to either make sure they are the same - or name the vi differently - ie ClassName_Constructor.vi etc.

Anyway, thanks for your advice.  I was aware as a stylistic question it might not have one 'right' answer - but was just wanting to check the pitfalls out.  I guess I just need to find another 9 programmers now!

[GregFreeman]

Mark has a CS background; he may come in here and rebut