-
Oct 20th, 2018, 10:27 AM
#1
[RESOLVED] Class vs Module
Other than the fact that you can instantiate a Class more than once, is there any real advantage to using a Class Module instead of a standard .bas Module?
J.A. Coutts
-
Oct 20th, 2018, 11:08 AM
#2
Re: Class vs Module
Being able to make a new instances of objects opens a new and very different world to programming.
Using only bas modules is like having only one textbox on a form, in opposite of having several textboxs, each one for a different purpose.
The difefrence is like D.O.S. versus Windows. (To work only with one window or with several)
Of course you can do, perhaps with much effort, the same work with only bas modules.
But it takes much more effort and it is much more confusing.
Having the data isolated into "instances" (objects) is more ordered and clear.
All that helps us in programming because we are humans.
Edit: I'll expand a bit why I said the last phrase "All that helps us in programming because we are humans".
Perhaps in the future, some AI (artificial intelligence) could do the same programs just using bas modules, and perhaps they would run faster, but would the humans be able to follow and understand that code?
Last edited by Eduardo-; Oct 20th, 2018 at 12:18 PM.
-
Oct 20th, 2018, 11:32 AM
#3
Re: Class vs Module
Originally Posted by couttsj
Other than the fact that you can instantiate a Class more than once, is there any real advantage to using a Class Module instead of a standard .bas Module?
J.A. Coutts
Say you have your TLS functions in a std module. How do you implement multiple TLS connections? You have to encapsulate state in a struct and require the client code to pass an instance of this struct to each function in your std module. This is what's called to make certain functionality (a module with inter-dependent functions) re-entrant.
And this is what class modules are doing behind the scene -- passing an implicit this, self or Me in VB6 as the state of the instance a method is called upon.
cheers,
</wqw>
-
Oct 20th, 2018, 01:52 PM
#4
Last edited by dz32; Apr 26th, 2019 at 11:13 AM.
-
Oct 20th, 2018, 02:00 PM
#5
Re: Class vs Module
Yeah, it's really a whole different concept. BAS modules are just for standard code. With CLS modules, you can do things like raise events, and, as you said, create many instances. For example, I have a class module that I use for dragging virtually any form around by any "gray" space, which would include any label, image, or other light-weight controls. Here's the entirety of the directions to use it:
Code:
' Some directions (mandatory):
'
' Dim oDragger As New cls_Gen_Dragger ' In module level code of a FORM.
'
' oDragger.Setup Me, True ' In Form_Activate event. If SSTab not used, it could also be in Form_Load.
' ' If put in Form_Load, put after any AlreadyActive test.
'
' Set oDragger = Nothing ' In Form_Unload. This is absolutely necessary to destroy all reference to the FORM.
'
' Optional:
'
' oDragger.ResizeEtc Me ' Possibly in Form_Resize event for resizable forms.
' ' Could also be executed at any time, for instance when a container is resized.
' ' Also, if new controls are added, executing this will fix the ZOrders so that dragging still works.
'
' oDragger.Setup Me, True, Frame1 ' Certain containers can be excluded if you like. Just list them in the ParamArray.
' ' This does nothing if bIncludeContainers is False.
I couldn't even come close to doing this with code in a standard BAS module. One of the things it does is create an array of nested classes, keeping track of every light-weight control on the form, and tracking the mouse-down, etc, events on them.
To my eyes, a CLS module has much more in common with a FRM module than a BAS module. In fact, when was it, VB4, before we had CLS modules? Actually, we did have them if we were willing to use a FRM module, and just not use it's user-interface portion. We couldn't get WithEvents, but we could get just about everything else.
Take Care,
Elroy
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
-
Oct 20th, 2018, 02:13 PM
#6
Re: Class vs Module
But hey, just to expand on my answer a bit, for me, the pendulum has swung both ways. And I think that's true in the VB6 community at large.
A few years back, it seemed like every snippet of code you saw was wrapped into a class module. However, that's no longer the case.
And, for me, once I got comfortable with CLS modules, I was the same way. I used them for everything.
However, I've very much swung back to the other direction. If I've got some general purpose function, these days, I wouldn't dare think of putting it into a CLS module.
For instance, here's a cute little function for returning the index of the selected OptionButton in a control array:
Code:
Public Function SelectedOptIndex(opt As Object) As Variant
' Returns the index number of a selected option button
' in an option button array. Returns NULL if none selected.
Dim o As OptionButton
'
For Each o In opt
If o.Value Then
SelectedOptIndex = o.Index
Exit Function
End If
Next o
SelectedOptIndex = Null
End Function
There's no way I'd consider wrapping that into a CLS module. There's just no need.
In fact, there are many instances where I have CLS modules that reach into BAS modules to get their work done. Some people have a problem with this, but I see nothing wrong with it. Sure, it means that the CLS module isn't well isolated in terms of source code portability, but that's fine with me.
Take Care,
Elroy
Any software I post in these forums written by me is provided "AS IS" without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. To all, peace and happiness.
-
Oct 20th, 2018, 02:24 PM
#7
Re: Class vs Module
The main advantage of VB6-classes is the COM-interface-oriented scheme which ensures lifetime/polymorphism/marshaling/etc.
-
Oct 20th, 2018, 04:30 PM
#8
Re: Class vs Module
depends what kind of program you are doing.
right now, for me, its better to make a bunch of modules, as i can choose what variables/udt to be public and what to be private,
i did a game awhile ago using classes and it resulted in a lot of calls and "friend" functions to able to communicate between all the classes. quite annoying after a while when i needed something new and i noticed that i needed something from class B that class E had. now, I can just make that variable/udt public and that module can use it.
right now i just use 1 class and its for the music player, as i only have a few commands to it.
-
Oct 21st, 2018, 03:24 AM
#9
Re: Class vs Module
I like 'KISS'
I use modules 98% of the time
Rob
PS Mind you in the battle about going 'OO', I was in the losing side.
-
Oct 21st, 2018, 04:33 AM
#10
Junior Member
Re: Class vs Module
Originally Posted by Bobbles
I like 'KISS'
I use modules 98% of the time
hmm .. this contradicts a bit - oo "could" ensure well arranged code and is still KISS.
i wrote could .. because i saw already some very stupid implementations - haha
But i guess the answer #7 sums already all benefits.
-
Oct 21st, 2018, 05:35 AM
#11
Re: Class vs Module
Originally Posted by Bobbles
I like 'KISS'
I use modules 98% of the time
Well - that kind of 'KISS' is then more in a category that's associated with a certain meal:
https://www.youtube.com/watch?v=i39WmNFT7uA
Olaf
-
Oct 21st, 2018, 12:01 PM
#12
Re: Class vs Module
There certainly are circumstances when a Class module suits the application (as in needing multiple instances), and WithEvents is a must for time sensitive applications such as networking, but for most applications a standard module seems to do just fine. The only reason I asked this question is because I originally developed the TLS 1.3 application using a Class. In order to produce a DLL (which was my ultimate goal), I had to convert it to a standard module. The standard module worked just as well as the Class and DLL, and although I didn't actually do a comparative test, it seemed to run quicker.
J.A. Coutts
-
Oct 22nd, 2018, 01:20 AM
#13
Re: Class vs Module
Originally Posted by couttsj
In order to produce a DLL (which was my ultimate goal), I had to convert it to a standard module.
This makes little sense to me unless you are targeting non-Ax DLL, hacking VB functions as PE exports etc.
It is possible to notice overhead with classes if you are calling utility functions (that don't access class members) in tight loops. Usually these functions are indeed better placed outside classes in a standard bas file to reduce clutter, and for performance as a nice consequence.
cheers,
</wqw>
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|