dim myObject as Object versus dim myObject as myProject.class1 
Author Message
 dim myObject as Object versus dim myObject as myProject.class1

The compiler will generate very different code in the two cases - case 1
is late-bound and requires the code treat everything it sees as a
surprise; case 2 is early-bound and the compiler can use all techniques
to optimize references.  Case 1 carries significant overhead burdens, of
course; how central to your app is that class, and what percentage of
processing will it be involved in?  OTOH, if myproject.class1 is likely
to evolve while the app remains static, your case 1 allows you to
distribute new versions of that dll without re-compiling and
re-distributing the main exe (tho 'Implements' and typelibs - more
honored in the telling than in the implementation - can provide the same
'feature' in case 2.)

One thing is sure: Whatever you decide, you will find reason to regret
it!



Sun, 09 Feb 2003 03:00:00 GMT  
 dim myObject as Object versus dim myObject as myProject.class1

Hi there;
I have a question regarding declaring of object variables. We are writing a
multi thier application with the second thier being inside the MTS.
Currently we use this syntax for our object variables:

Dim myObject as object
set myObject = createobject("myProject.class1")

This means we do not need a reference to myProject in our client
application. In various books I have seen following

dim myObject as myProject.class1
set myObject = createobject("myProject.class1")

This only works when we specify the reference to myProject in the client
application. What are the advantages and disadvantages in using different
syntax.

One disadvantage of using the first one is, that there is no syntax
checking. Are there any disadvantes when using the second one regarding
performance or size of the compiled dll or exe file? I would appreciate your
answer or any tips of books that cover this subject!

Thanks

Thomas Born




Mon, 10 Feb 2003 09:12:36 GMT  
 dim myObject as Object versus dim myObject as myProject.class1
Thanks for the response!
I always had the impression when using MTS case 1 is better. Less overhead
sounds always good, which means I will favour case 2!

Will also have a look into typelibs to avoid to much recompiling!


Quote:
> The compiler will generate very different code in the two cases - case 1
> is late-bound and requires the code treat everything it sees as a
> surprise; case 2 is early-bound and the compiler can use all techniques
> to optimize references.  Case 1 carries significant overhead burdens, of
> course; how central to your app is that class, and what percentage of
> processing will it be involved in?  OTOH, if myproject.class1 is likely
> to evolve while the app remains static, your case 1 allows you to
> distribute new versions of that dll without re-compiling and
> re-distributing the main exe (tho 'Implements' and typelibs - more
> honored in the telling than in the implementation - can provide the same
> 'feature' in case 2.)

> One thing is sure: Whatever you decide, you will find reason to regret
> it!



Mon, 10 Feb 2003 10:06:53 GMT  
 dim myObject as Object versus dim myObject as myProject.class1

Quote:

> Hi there;
> I have a question regarding declaring of object variables. We are writing
a
> multi thier application with the second thier being inside the MTS.
> Currently we use this syntax for our object variables:

> Dim myObject as object
> set myObject = createobject("myProject.class1")

CreateObject is normally used with VBScript on ASP pages (because all
variables are Variants), and I use it in VB when it's possible that
"myProject.class1" won't be on the system.  There's probably other uses, but
the other method is probably faster.

Quote:

> This means we do not need a reference to myProject in our client
> application. In various books I have seen following

> dim myObject as myProject.class1
> set myObject = createobject("myProject.class1")

I can't think of any books that use that method.  What is common is:

  dim myObject as myProject.class1
  set myObject = New myProject.class1

This method is supposed to be faster than your first because the binding is
done earlier than when using a generic type (ie. As Object, As Control,
etc.), but I've never timed the two to find out if it's a big or small
difference.

Hope this helps...
- Tony



Mon, 10 Feb 2003 10:16:35 GMT  
 dim myObject as Object versus dim myObject as myProject.class1

Egads, this misunderstanding just will not die!  As soon as one includes the
typelib and says:

  Dim myObject As myProject.class1

or for that matter, where the project qualification isn't needed to scope
the class name:

  Dim myObject As class1

it is early binding.  End of story.  How you then retrieve an object to
assign to that reference does not affect the binding.  All of the following
allocations are still early binding, giving the above declarations of
myObject:

  Set myObject = New class1
  Set myObject = New myProject.class1
  Set myObject = CreateObject("myProject.class1")
  Set myObject = MyMethod( )

where the latter returns a newly created or already existing "class1"
object.

Not to jump on you in particular Tony, but this misunderstanding seems to be
getting worse lately, despite repeated corrections on this board.

Steven


Quote:
>> This means we do not need a reference to myProject in our client
>> application. In various books I have seen following

>> dim myObject as myProject.class1
>> set myObject = createobject("myProject.class1")

>I can't think of any books that use that method.  What is common is:

>  dim myObject as myProject.class1
>  set myObject = New myProject.class1

>This method is supposed to be faster than your first because the binding is
>done earlier than when using a generic type (ie. As Object, As Control,
>etc.), but I've never timed the two to find out if it's a big or small
>difference.



Mon, 10 Feb 2003 03:00:00 GMT  
 dim myObject as Object versus dim myObject as myProject.class1

Quote:

>One thing is sure: Whatever you decide, you will find reason to regret
>it!

Ah, yes: truer words were never spoke!

Jim Deutch
MS Dev MVP



Mon, 10 Feb 2003 03:00:00 GMT  
 dim myObject as Object versus dim myObject as myProject.class1
Hi Steve,
I think it was bad wording on my part.  When talking about binding, I was
comparing the two "Dim" statements -- not the two "Set" statements.  I said
that his latter method was supposed to be faster than his first method
because of binding.  I should have explained myself better, instead of a
quick message.

As far as the "New" keyword, was I just trying to point out that he can use
"New" instead of "CreateObject" when he Dim's a variable as a class instead
of the "Object" type.  (Maybe he didn't know that).

Thanks,
Tony



Quote:

> Egads, this misunderstanding just will not die!  As soon as one includes
the
> typelib and says:

>   Dim myObject As myProject.class1

> or for that matter, where the project qualification isn't needed to scope
> the class name:

>   Dim myObject As class1

> it is early binding.  End of story.  How you then retrieve an object to
> assign to that reference does not affect the binding.  All of the
following
> allocations are still early binding, giving the above declarations of
> myObject:

>   Set myObject = New class1
>   Set myObject = New myProject.class1
>   Set myObject = CreateObject("myProject.class1")
>   Set myObject = MyMethod( )

> where the latter returns a newly created or already existing "class1"
> object.

> Not to jump on you in particular Tony, but this misunderstanding seems to
be
> getting worse lately, despite repeated corrections on this board.

> Steven



> >> This means we do not need a reference to myProject in our client
> >> application. In various books I have seen following

> >> dim myObject as myProject.class1
> >> set myObject = createobject("myProject.class1")

> >I can't think of any books that use that method.  What is common is:

> >  dim myObject as myProject.class1
> >  set myObject = New myProject.class1

> >This method is supposed to be faster than your first because the binding
is
> >done earlier than when using a generic type (ie. As Object, As Control,
> >etc.), but I've never timed the two to find out if it's a big or small
> >difference.



Mon, 10 Feb 2003 03:00:00 GMT  
 dim myObject as Object versus dim myObject as myProject.class1
Thomas, the topic your question introduces is quite large -- early vs. late
binding of objects. Your observations are correct, as are your wonderings
about execution speed. For an excellent discussion, see the first few
chapters of Programming Distributed Applications with COM and VB 6.0 by Ted
Pattison, MS Press. (Note that a second edition of this book dealing with
COM+ is also available that won't apply to your MTS deployment.) Also search
VB documentation for a decent definition of early vs. late binding.

Also, be sure to check out ObjectContext for instantiating objects under MTS
if you plan to use transaction services MTS provides.

Jeff

Quote:
> Currently we use this syntax for our object variables:

> Dim myObject as object
> set myObject = createobject("myProject.class1")

> This means we do not need a reference to myProject in our client
> application. In various books I have seen following

> dim myObject as myProject.class1
> set myObject = createobject("myProject.class1")

> This only works when we specify the reference to myProject in the client
> application. What are the advantages and disadvantages in using different
> syntax.



Mon, 10 Feb 2003 03:00:00 GMT  
 dim myObject as Object versus dim myObject as myProject.class1
Would there be any advantage to using Set = New versus using the
CreateObject method?  I assume that MyMethod() is the name of a method
in class1?


Quote:
>   Set myObject = New class1
>   Set myObject = New myProject.class1
>   Set myObject = CreateObject("myProject.class1")
>   Set myObject = MyMethod( )

--
Eric W. Goforth
Office Systems Integrator II
First Citizens Bank - 100 E. Tryon Rd. - Raleigh, NC


Tue, 11 Feb 2003 03:00:00 GMT  
 dim myObject as Object versus dim myObject as myProject.class1


Quote:
> Would there be any advantage to using Set = New versus using the
> CreateObject method?  I assume that MyMethod() is the name of a method
> in class1?


> >   Set myObject = New class1
> >   Set myObject = New myProject.class1
> >   Set myObject = CreateObject("myProject.class1")
> >   Set myObject = MyMethod( )

If the object is a class inside your own project then "Set =New" has some
advantages over "Set =CreateObject" since VB uses private methods to create
and use the object.  If the class is in a DLL or activex exe then they are
equivalent.


Tue, 11 Feb 2003 03:00:00 GMT  
 dim myObject as Object versus dim myObject as myProject.class1

Quote:

>Would there be any advantage to using Set = New versus using the
>CreateObject method?  I assume that MyMethod() is the name of a method
>in class1?


>>   Set myObject = New class1
>>   Set myObject = New myProject.class1
>>   Set myObject = CreateObject("myProject.class1")
>>   Set myObject = MyMethod( )

There are smaller issues, but to me the biggest advantage of using New is
that's it's a shorthand, including getting the intellisense write after I
type the "New".  Also, it allows the compiler to verify the that the type is
referenced correctly on the allocation line.

The disadvantages of New arise from that same behavior.  The type is linked
in a way that can make versioning a little more tricky than using
CreateObject.  This is because using a ProgID "myProject.class1"  can refer
to one or more versions of the project--whichever one happens to be
registered on the machine at the time.  New is more picky.  (By the same
token, sometimes we *want* that pickiness, because of what we are going to
do with the reference once we get it.)  Also, using "New" in a DLL meant for
distributed COM (e.g. MTS) has problems that I'm not really qualified to
discuss :-)  Suffice to say that "New" isn't implemented in a
distributed-friendly manner.

As I meant it, "MyMethod() could be any method on any object that returns a
"class1".  I was merely emphasizing how "early binding" was set by the
declaration itself, not how the object was allocated.  You don't know how
the returned class1 was originally allocated, but you don't care.  You know
that you assign that returned reference to a variable declared as "class1",
then you have early binding.

Steven



Tue, 11 Feb 2003 03:00:00 GMT  
 dim myObject as Object versus dim myObject as myProject.class1



Quote:

> >Would there be any advantage to using Set = New versus using the
> >CreateObject method?  I assume that MyMethod() is the name of a method
> >in class1?


> >>   Set myObject = New class1
> >>   Set myObject = New myProject.class1
> >>   Set myObject = CreateObject("myProject.class1")
> >>   Set myObject = MyMethod( )

> There are smaller issues, but to me the biggest advantage of using New is
> that's it's a shorthand, including getting the intellisense write after I
> type the "New".  Also, it allows the compiler to verify the that the type
is
> referenced correctly on the allocation line.

<cut>

Using "New" or "CreateObject" has nothing do to with early/late binding or
the intellisense...  even using "New" in the DIM line has nothing to do with
that.  As long as you specify an explicit type when you declare the
reference you have early binding and intellisense.



Tue, 11 Feb 2003 03:00:00 GMT  
 dim myObject as Object versus dim myObject as myProject.class1

Quote:

>Using "New" or "CreateObject" has nothing do to with early/late binding or
>the intellisense...  even using "New" in the DIM line has nothing to do
with
>that.  As long as you specify an explicit type when you declare the
>reference you have early binding and intellisense.

I know that.  See my first reply in this thread <grin>.  I said when I
*type* New.  So it does affect Intellisense on *that* line.  If I say
"CreateObject", I have to type the string in myself.  Minor, I know.

I guess you are doing unto me as I did unto Tony.  Breathe "New" and
"Binding" in the same sentence and the regular's brain goes into autoreply
mode <grin>

Steven



Tue, 11 Feb 2003 03:00:00 GMT  
 dim myObject as Object versus dim myObject as myProject.class1



Quote:


> >Using "New" or "CreateObject" has nothing do to with early/late binding
or
> >the intellisense...  even using "New" in the DIM line has nothing to do
> with
> >that.  As long as you specify an explicit type when you declare the
> >reference you have early binding and intellisense.

> I know that.  See my first reply in this thread <grin>.  I said when I
> *type* New.  So it does affect Intellisense on *that* line.  If I say
> "CreateObject", I have to type the string in myself.  Minor, I know.

Ahhh... that IS minor <g>  You can always type New and then edit it to
createobject <g>

Quote:
> I guess you are doing unto me as I did unto Tony.  Breathe "New" and
> "Binding" in the same sentence and the regular's brain goes into autoreply
> mode <grin>

Yep.  With all the confusion the topic generates to people just getting into
it that does tend to happen.  Appropriate apologies for not reading
carefully enough.


Tue, 11 Feb 2003 03:00:00 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. dim myObject as Object versus dim myObject as myProject.class1

2. dim string to dim form

3. Newbie Question: Dim A() as String /Dim A as String()

4. Dim obj As New Class crt Dim Obj As Class = New Class

5. dynamically dim a variable ie dim "variable"&n

6. "for each myobject in words" question

7. Should I set "MyObject = Nothing"?

8. if (myobject = NULL) then...

9. set myObject = nothing isn't working

10. dim versus private

11. Closing form / ending application problems (with Dim WithEvents object)

12. dim as object type

 

 
Powered by phpBB® Forum Software