Home All Groups Group Topic Archive Search About

Sub .... or Private Sub....

Author
6 Jun 2009 2:02 PM
MM
I am optimising the code.

In a module (.frm, .bas) what is the difference between:

Sub Whatever
........code
End Sub

And:

Private Sub Whatever
........code
End Sub

given that the sub is only called within the same module?

MM

Author
6 Jun 2009 2:11 PM
Bob Butler
Show quote Hide quote
"MM" <kylix***@yahoo.co.uk> wrote in message
news:kjtk25df4s6beuafnlng2eu5t3mqbgvk6j@4ax.com...
>I am optimising the code.
>
> In a module (.frm, .bas) what is the difference between:
>
> Sub Whatever
> .......code
> End Sub
>
> And:
>
> Private Sub Whatever
> .......code
> End Sub
>
> given that the sub is only called within the same module?

Is the default 'Public' or 'Private'?  IMO, if you don't remember offhand,
or if you want to be sure than anybody reading the code knows the difference
and your intent, then it is best to specify the one you want.  There's no
functional difference between specifying the default and omitting it.
Author
6 Jun 2009 3:07 PM
MM
Show quote Hide quote
On Sat, 6 Jun 2009 07:11:50 -0700, "Bob Butler" <noway@nospam.ever>
wrote:

>
>"MM" <kylix***@yahoo.co.uk> wrote in message
>news:kjtk25df4s6beuafnlng2eu5t3mqbgvk6j@4ax.com...
>>I am optimising the code.
>>
>> In a module (.frm, .bas) what is the difference between:
>>
>> Sub Whatever
>> .......code
>> End Sub
>>
>> And:
>>
>> Private Sub Whatever
>> .......code
>> End Sub
>>
>> given that the sub is only called within the same module?
>
>Is the default 'Public' or 'Private'?  IMO, if you don't remember offhand,
>or if you want to be sure than anybody reading the code knows the difference
>and your intent, then it is best to specify the one you want.  There's no
>functional difference between specifying the default and omitting it.

My aim is to eventually release the entire source code to the PD so I
want it to look (and behave!) as right as possible.

My gut feeling is that one should always attempt to restrict scope as
much as possible, so as to come away from the old QuickBASIC mindset
of Global everything.

So... don't make anything Public that doesn't need to be, and so on.

But also I do wonder whether VB behind the scenes sets up a procedure
or function differently depending on whether it is declared as Private
or not. VB itself always specifies Private, as in: Private Sub
Command1_Click() when you whack a command button to to a form.

It could be that when a procedure/function is declared Public that VB
sets up additional internal information, and if Public wasn't
necessary in the first place, that extra effort (by VB) is
wasted/pointless.

MM
Author
6 Jun 2009 3:28 PM
Bob Butler
"MM" <kylix***@yahoo.co.uk> wrote in message
news:t41l25l0q1nm9mlkpjqip62raq8gblmorl@4ax.com...
<cut>
> It could be that when a procedure/function is declared Public that VB
> sets up additional internal information, and if Public wasn't
> necessary in the first place, that extra effort (by VB) is
> wasted/pointless.

I think you are overthinking things.  The compiler creates Private, Public,
or Friend scope depending on the text of the source code.  If you don't
specify then it defaults to one of them.  The simplest and safest option is
to just be as explicit as possible.
Author
6 Jun 2009 4:25 PM
Ralph
"MM" <kylix***@yahoo.co.uk> wrote in message
news:t41l25l0q1nm9mlkpjqip62raq8gblmorl@4ax.com...

>
> It could be that when a procedure/function is declared Public that VB
> sets up additional internal information, and if Public wasn't
> necessary in the first place, that extra effort (by VB) is
> wasted/pointless.
>

Follow Bob's advice (which in itself always good advice) - if you intend to
use something 'outside' a module make it Public, if your intentions are that
it should only be used inside a module, make it Private. This helps you, and
anyone else that comes behind you. That is a simple rule that is applicable
for all modules, Form, Class, or Basic, ie, don't over-think it and you will
be fine.

Your concern to avoid additonal internal information being added is correct
for Forms and Classes. But has no effect on Bas modules.

Whether a Private or Public variable in a Bas module is within scope is
determined by the VB parser at the time you use it during development - it
is not something that translates to compiled code.

However, declaring a variable Public in a Form or Class module does add some
additional code. They are changed to Properties behind the scenes and become
part of the default or public interface for that object. You can consider
that "additional, unnecessary" code if you declared something Public that
you don't intend to be used outside the module - but again Bob's sage advice
holds - if you need it be Public you get it, if you don't, you don't.
<smile>

Note: That is also why added events are declared 'Private' in Form modules -
not for 'scope' reasons as much as they are not part of the Form's Public or
default interface. (The same with events captured in a class module using
WithEvents.)

-ralph
Author
7 Jun 2009 7:35 AM
MM
Show quote Hide quote
On Sat, 6 Jun 2009 11:25:28 -0500, "Ralph" <nt_consultin***@yahoo.com>
wrote:

>
>"MM" <kylix***@yahoo.co.uk> wrote in message
>news:t41l25l0q1nm9mlkpjqip62raq8gblmorl@4ax.com...
>
>>
>> It could be that when a procedure/function is declared Public that VB
>> sets up additional internal information, and if Public wasn't
>> necessary in the first place, that extra effort (by VB) is
>> wasted/pointless.
>>
>
>Follow Bob's advice (which in itself always good advice) - if you intend to
>use something 'outside' a module make it Public, if your intentions are that
>it should only be used inside a module, make it Private. This helps you, and
>anyone else that comes behind you. That is a simple rule that is applicable
>for all modules, Form, Class, or Basic, ie, don't over-think it and you will
>be fine.
>
>Your concern to avoid additonal internal information being added is correct
>for Forms and Classes. But has no effect on Bas modules.
>
>Whether a Private or Public variable in a Bas module is within scope is
>determined by the VB parser at the time you use it during development - it
>is not something that translates to compiled code.
>
>However, declaring a variable Public in a Form or Class module does add some
>additional code. They are changed to Properties behind the scenes and become
>part of the default or public interface for that object.

Ah, I wuz right in my supposition! How do you KNOW these things?!! ;)
Where is the story told? Or is it just the grapevine?

> You can consider
>that "additional, unnecessary" code if you declared something Public that
>you don't intend to be used outside the module - but again Bob's sage advice
>holds - if you need it be Public you get it, if you don't, you don't.
><smile>
>
>Note: That is also why added events are declared 'Private' in Form modules -
>not for 'scope' reasons as much as they are not part of the Form's Public or
>default interface. (The same with events captured in a class module using
>WithEvents.)
>
>-ralph

Thanks. Very useful.

MM
Author
7 Jun 2009 12:15 PM
Bob Riemersma
"MM" <kylix***@yahoo.co.uk> wrote in message
news:c9rm25dkuuifkqrffrrmj84voe7h1q4can@4ax.com...
> On Sat, 6 Jun 2009 11:25:28 -0500, "Ralph" <nt_consultin***@yahoo.com>
> wrote:

>>However, declaring a variable Public in a Form or Class module does add
>>some
>>additional code. They are changed to Properties behind the scenes and
>>become
>>part of the default or public interface for that object.
>
> Ah, I wuz right in my supposition! How do you KNOW these things?!! ;)
> Where is the story told? Or is it just the grapevine?

It isn't so much that "they are changed to Properties" as "this is the
syntax for creating Properties with default, compiler generated
getter/setter procedures."  In other words this isn't an accident, this is
by design.

While I can't cite a specific page covering this I'm almost certain this is
described in the VB6 documentation in one or more places.

There is even an "Option Private Module" defined that has no meaning in VB6
but is used in hosted VBA (as in Excel, etc.) for project-level isolation.
I mention this because you can't really get a full picture of things without
having read the entire set of VB documentation.  While the docs are not
perfectly complete nor infallible there is a wealth of information in them.
Author
7 Jun 2009 3:36 PM
Ralph
Show quote Hide quote
"Bob Riemersma" <nospam@nil.net> wrote in message
news:O3hpbm25JHA.1420@TK2MSFTNGP04.phx.gbl...
> "MM" <kylix***@yahoo.co.uk> wrote in message
> news:c9rm25dkuuifkqrffrrmj84voe7h1q4can@4ax.com...
> > On Sat, 6 Jun 2009 11:25:28 -0500, "Ralph" <nt_consultin***@yahoo.com>
> > wrote:
>
> >>However, declaring a variable Public in a Form or Class module does add
> >>some
> >>additional code. They are changed to Properties behind the scenes and
> >>become
> >>part of the default or public interface for that object.
> >
> > Ah, I wuz right in my supposition! How do you KNOW these things?!! ;)
> > Where is the story told? Or is it just the grapevine?
>
> It isn't so much that "they are changed to Properties" as "this is the
> syntax for creating Properties with default, compiler generated
> getter/setter procedures."  In other words this isn't an accident, this is
> by design.
>

I might have used the word "converted" instead of "changed", but I fail to
see the distinction between "they (declared Public variables) are changed to
Properties" and "this is syntax for creating (default) Properties".

If you type the following in the VBEditor within a Form or Class module.
     Public Junk As Long
The parser immediately converts that high-level statement into the
lower-level opcode representation for a VB Property. Thus you may think you
have a simple declaration but you have more lines of hidden code than if
that statement was written in a Bas module. Or if you had declared it
Private.

You can see this clearly by this simple test.
Create an class with a Public variable
' CJunk
   Private Refuse As Long
   Public Junk As Long
   Public Trash As Class1    ' an object reference
' end

Now open another class or form and implement it
' CTest
     Implements CJunk
' end

At the top of the edit window in the Object dropdown select CJunk.
Then dropdown the Procedure list ... what you will see is
      Junk [PropertyGet]
      Junk [PropertyLet]
      Trash [PropertyGet]
      Trash [PropertySet]

And of course Refuse is nowhere to be seen.

-ralph
Author
6 Jun 2009 2:32 PM
Nobody
The default is Public for Sub/Function, and Private for Dim(when used in the
general section).

While on the subject, here is a break down of the visibility of
Private/Friend/Public:

- Private does not allow the method to be seen in other modules in the
project nor outside the project.
- Friend allows the method to be seen in all modules in the project, but not
outside the project.
- Public allows the method to be seen in all modules in the project and
outside the project(Except standard EXE).

Sometimes when you have a standard EXE project, the compiler objects to
using "Public" in certain situations(in class modules), so in these cases
use "Friend" instead.
Author
6 Jun 2009 4:54 PM
Ivar
Surely you jest when you ask a question like this :-)

The easiest way to find the answer is try it yourself, Just write Sub MySub
in your module and see if you can call MySub from another module. Takes a
few seconds!

The next easist way is to look in MSDN where you would find:
"If not explicitly specified using either Public or Private, Sub procedures
are public by default, that is, they are visible to all other procedures in
your script. The value of local variables in a Sub procedure is not
preserved between calls to the procedure."
Took me about a minute to find it.

How long did it take you to write and post the question then wait for
replies?
Author
6 Jun 2009 5:18 PM
MM
On Sat, 6 Jun 2009 17:54:30 +0100, "Ivar"
<Ivar.ekstromer***@ntlworld.com> wrote:

Show quoteHide quote
>Surely you jest when you ask a question like this :-)
>
>The easiest way to find the answer is try it yourself, Just write Sub MySub
>in your module and see if you can call MySub from another module. Takes a
>few seconds!
>
>The next easist way is to look in MSDN where you would find:
>"If not explicitly specified using either Public or Private, Sub procedures
>are public by default, that is, they are visible to all other procedures in
>your script. The value of local variables in a Sub procedure is not
>preserved between calls to the procedure."
>Took me about a minute to find it.
>
>How long did it take you to write and post the question then wait for
>replies?

Thirty seconds!

Thanks!

MM