Hi

One reason that i have found useful is that with a single input variant
parameter passed by value, the data passed inside it could change
over time, along with changes in application/requirement if your interface
isnt as immutable as you would like it to be - maybe during the development
 phase if you would like

eg -
The sample interface which you have shown could be made into
Public Function UpdateRecord(ByVal variantparam) as Boolean

the input param could contain a UDT which contains all of your
other parameters. Additional data input can be added to the UDT
over time. I have found this to be a more manageable proposition
in our projects against an ever changing/growing shrinking parameter
list. The UDt typelib identifiers would change but you could keep
your interface constant -

The reason that u have shown - a variant containing data that can
interpreted
differently accepting multiple kinds of data, used with casting will soon
get out of hand and lots of confusion can ensue - it is best avoided in my
opinion as i learned the hard way.

But ofcourse it would be upto the class designer to evangelise the inteface
definitions and deem what is appropriate - and then again variants consume
more memory and is more harder to use and is not at all a good idea for
simple get/set functions

Iam not aware of any other reasons and would be really intersted in more
answers

arun

----- Original Message -----
From: "Bystrov, Vladimir - ICS (vaby)" <vabyTENGIZCHEVROIL.COM>
To: <DCOMDISCUSS.MICROSOFT.COM>
Sent: Wednesday, January 02, 2002 4:41 PM
Subject: Variants and Input Parameters to Components

> Sorry for cross-post, but I would really appreciate your comments and your
> own programming practices. In my organization we are having some
> discussions on "COM best practices", and one of the parties suggests on
the
> following statement as a recommendation to programmers:
>
> - Use VARIANTS for input parameters to components. Cast the parameters
to
> the correct type in the component.
>
> This is different from what I am usually doing and from the samples in
books
> or wherever. I know that one should cast output parameters as Variants,
but
> why input?
>
> The only reason I can see behind this is when you have plenty of optional
> arguments, say you have something like:
>
> Public Function UpdateRecord(ByVal sCriteria as String, ByVal sField1 as
> String, Optional byVal vField2 as Variant, Optional byVal vField3 as
> Variant) as Boolean
>
> If vField2 Is Nothing then
> 'Do not put anything in this field,
> 'the field is nullable
> else
> 'Cast to the expected data type
> 'and add value
> dField2 = Cdate(vField2)
> '...
> end if
>
> End Function
>
> I understand (please, correct me if I am wrong) that if it's done in the
way
> like:
>
> Optional byVal lngField2 as Long
>
> ... the implementation code can not distinguish between two cases -- 1)
> caller did not provide a value, and 2) caller provided a value of 0. And
> thus the following code will not allow user to "zero" a value that is
> already in the database:
>
> If lngField2 <> 0 then
> 'update field
> else
> 'do not update field
> end if
>
> Again, I may be wrong but the above is my only guess for justifying
> recommendation to always use variants for input parameters. What is
> everyone's experience? What's true, what's wrong? To avoid confusion --
I
> am talking about components that are run under MTS and can be used by BOTH
> thin and rich clients. BTW, anyone know if ASP.NET (or how it's called)
> provides for strict casting?
>
> Thanks in advance for any feedback and sorry for cross-posting again!
>
> Vladimir
>
> ----------------------------------------------------------------
> Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
> contains important info. Save time, search the archives at
> http://discuss.microsoft.com/archives/index.html .
> To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]