Instantiation gobbly gook

[tedsmith]

Can anybody really explain in simple terms with a simple example the term "instantiation"

I thought I knew what it meant but this definition from another site has me now completely confused:-

"In programming, instantiation is the creation of a real instance or particular realization of an abstraction or template such as a class of objects or a computer process. To instantiate is to create such an instance by, for example, defining one particular variation of object within a class, giving it a name, and locating it in some physical place.

 

[strongm]

Getting rid of the academic language, it can probably be abridged to (and I suspect this is the definition you are probably familiar with):

"In programming, instantiation is the creation of a real instance ... of a class"

And, in a language such as VB, we call that instance an object - technically the object only exists when it takes up some physical memory (the "locating it in some physical place" of the definition that you provide) and there is a reference to it

 

[MajP]

Barney style without the academic goobly gook. Think of it like the class is the Ginger Bread Man cookie cutter or template. An instantiated object is a Ginger Bread Man. Therefore

"In programming, instantiation is the creation of a real instance of a Ginger Bread Man. To instantiate is to create such an instance by, for example, pushing the ginger bread cookie cutter in the one particular variation of dough, giving it a name, and putting it on the cookie sheet."

Dimensioning the object such as
dim myGingerBreadMan as objGingerBreadMan

only creates room (memory location) on the cookie sheet. This is not instantiation only dimensioning.

Set myGingerBreadMan as new objGingerBreadMan

cuts out a piece of dough making a new Ginger Bread Man and giving him the name of myGingerBreadMan.


Once instantiated you can set properties such as
myGingerBreadMan.sprinkleFlavor = "choclate"

and invoke methods such as
myGingerBreadMan.runRunAsFastAsYouCan()

 

[strongm]

>only creates room (memory location) on the cookie sheet

Nope, not in VB. It creates space for an empty object pointer (empty because no room has been created on the cookie sheet for this gingerbreadman yet)

 

[tedsmith]

Thanks for the reassurance.
I feel much better now knowing that two experienced Gingerbread cooks are also slightly confused (or at least one of them must be!)

So are you saying that Dimensioning a whole lot of variables that may or may not ever be used takes up no room in memory other then the bytes the pointer to where the memory will start?

However if you dimension a fixed variable like
GingerbreadArm as Integer or
GengerbreadBody as String * 20
I thought this also reserved a fixed amount of memory for the future data?

 

[strongm]

An object pointer takes up 4 bytes. And that 4 bytes gets reserved. It points to nothing though ...

 

[strongm]

And

>So are you saying that Dimensioning a whole lot of variables that may or may not ever be used takes up no room in memory other then the bytes the pointer to where the memory will start?

No, I'm not. Other variable types follow different rules. Space for an integer, for example, (2 bytes) is allocated and initialised to a value of 0, and your variable points to that. In the case of a fixed length string the memory is reserved and intialised to a bunch of ASCII 0s, and the variable points to it (well, actually it's a teeny bit more complicated under the bonnet where strings are concerned, but in essence this is what happens)

 

[MajP]

Ok it is a little more complicated than I said. When you dimension a Ginger Bread Man, it is the same thing as yelling out to the baker that you are going to want him to make you a ginger bread man in the future. So he pulls out an order form and tacks it on his board. He does not know yet where he will put it once he makes it, but he knows when he does make it he will write down its location on the cookie sheet on that form.

 

[strongm]

Yep.

 

[tedsmith]

But I don't think this baker has an order form or a board. She only has a cookie sheet so what happens to this cookie sheet when he takes an order?
When taking the order, she must take up some space on the cookie sheet (that would reduce the amount of cookies she could produce).
So I presume Dimensioning uses up some of the cookie sheet that later will point to the position of the start of the future gingerbread man on the sheet.
If VB6 is anything like the very old DOS basic, the size of the gingerbread is stored when the gingerbread is made, being a pointer to the end of the gingerbread. The gingerbread sits between these pointers.
But because Dimensioning also defines what sort of gingerbread man, there must be more than 4 bytes used when dimensioning.
Is this correct?

 

[strongm]

>If VB6 is anything like the very old DOS basic, the size of the gingerbread is stored when the gingerbread is made

It isn't. The only variable type that is anything like this is a variable length string

>because Dimensioning also defines what sort of gingerbread man, there must be more than 4 bytes used when dimensioning

VB maintains metadata about variables, but in a compiled program this is stored in the EXE, not dynamically allocated at runtime.

There is a good overview of how VB deals with COM objects here: How Visual Basic COM+ Objects Work Internally Mind you the first thing you'll need to get your mid around is that VB actually points to interfaces, not to objects(something that is normally hidden from VB programmers)

 

[tedsmith]

I was visualising the gingerbread man as a string.

 

[HarleyQuinn]

Is anyone else starting to feel hungry?

HarleyQuinn
---------------------------------
Carter, hand me my thinking grenades!

You can hang outside in the sun all day tossing a ball around, or you can sit at your computer and do something that matters. - Eric Cartman

Get the most out of Tek-Tips, read FAQ222-2244: How to get the best answers before posting.

http://lessthandot.com

 

[tedsmith]

Very interesting article as you suggest.

I suddenly realised I have never used a class module for anything. I always thought they were essentially a programmers convenience or another way of writing a routine.

Is there any situation that one would really have to use a class module that could not be done another way to produce the same end result?

 

[strongm]

>I suddenly realised I have never used a class module for anything

What do you think a form is? Or a usercontrol?

 

[tedsmith]

what I meant was I have never used "Add a Class Module" in projects although I have often seen other people's code that did.

Is there any situation where you HAVE to use this 'Add Class Module' facility other than to present the code in another form ?

 

[strongm]

And my point is that you have used (and probably added, if you have ever created a project with more than one form) a class module. That is what a form is, it just has a different name (and a graphical interface)

>Is there any situation where you HAVE to use this 'Add Class Module'

Well, it's the only way to create an ActiveX exe or dll in VB ...

Avoiding the above tow scenarios, do you HAVE to? No. But given that it is clear that you happily use classes and find the ones provided with VB useful why would you reject the ability to create your own?

>present the code in another form

Erm ... this is the OOP bit of VB ..., so it isn't just a different way of presenting the code, it is a different way of programming; dare I say it, a new (well, not that new anymore) paradigm. I don't really have the time to evangelise the OOP approach, but there are plenty of books that do ... what I will say is that it took me a while to get my head around it, but you suddenly have an epiphany when everything drops into place

 

[HarleyQuinn]

what I will say is that it took me a while to get my head around it, but you suddenly have an epiphany when everything drops into place

I couldn't agree more with that statement. It took me a long time to understand the principles (and probably more specifically how to apply these principles using VB6).

Once I did it though, it seemed puzzling how it had been so confusing.

HarleyQuinn
---------------------------------
Carter, hand me my thinking grenades!

You can hang outside in the sun all day tossing a ball around, or you can sit at your computer and do something that matters. - Eric Cartman

Get the most out of Tek-Tips, read FAQ222-2244: How to get the best answers before posting.

http://lessthandot.com

 

[tedsmith]

I understand what you are saying.

What I am getting at is if there is anything in VB6 that you CANT do without using a "Class Module" , ActiveX or DLL, that can be done otherwise in straighforward code not using these above methods?

I was not entering into whether it is better or more elegant to use them or not - just if you cant do something without them (apart from using other peoples routines or code that was developed in another language)

 

[dilettante]

Examples of cases where you must use classes are rare, but they exist.

One category would be APIs that require your program to implement predefined interfaces. Writing COM+ components is one place where this is required. Another is the use of MSXML's SAX parser. Others are not so common unless you are taking an OOP approach in general (polymorphism).

Another is event binding with certain types of components. One example of this is the use of a wrapper class that can be bound to the OnReadyStateChange event of XMLHTTPRequest objects. There are a number of scripting-oriented components that require this approach instead of typical VB-style event binding. It is also required in order to handle events from late-bound objects.

Another is creating controls and classes in general: for use in other VB6 or VFP6 programs, in Office application VBA code, as components of Web pages in IE, or for use in WSH scripts or classic ASP pages. The list goes on and on.

Not to mention that code in your .BAS modules is static and stays loaded for the life of your program. This could get expensive in very large programs, ballooning its memory footprint considerably.

There are a ton of examples where you don't need a class, but it makes life a lot easier.

I'm not sure how else you'd create hierarchies without a lot of fiddling. Whenever you have a need for tree-like linkages or parent-children relationships between sets of data classes are much cleaner than multidimensional Variant arrays or UDT arrays with array subscript values as links.

Then there is the issue of creating custom collections. These must be implemented as enumerable classes or else you can't use For...Each with them. Such classes can be accessed via Index or Key like the standard Collection class. Doing this with arrays and a bunch of code is a horror.

Just in general it makes coding less cumbersome. With a class you keep the code that operates upon it "next to" the data involved. You also don't need to pass so many parameters to those operations.

VB6 without Classes, UserControls, etc. would be... VB3. Or maybe (shudder) QBasic.