Re: beginner Q's about COM/.NET (context = exposing a pre-existing app to scripting)
- From: "Brian Muth" <bmuth@xxxxxxxx>
- Date: Tue, 24 Jan 2006 15:34:58 -0800
"Jason S" <jmsachs@xxxxxxxxx> wrote in message
news:1138144118.621737.105140@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> yes that helps. (d), (e), (f) I'm all set on, I think. I've got some
> books arriving tomorrow that should help more, I hope.
>
> Brian Muth wrote:
>> > a) Should I abandon COM & go for .NET?
>>
>> Scripting languages, at the moment, only can deal with COM objects. You
>> can
>> create a COM wrapper (called an Interop) for a .NET object, so this
>> doesn't
>> mean you can't program in .NET. Overall, you will probably find .NET
>> easier
>> once you get the hang of it. The downside is that there will be a
>> noticable
>> delay when the .NET object is first loaded, since compilation of the .NET
>> assembly is done on the fly.
>
> hmm... (interested but skeptical) Would I be correct in assuming .NET
> is "easier" (less manual labor) to implement objects but has more
> conceptual baggage than COM? If so, I'll probably stick w/ COM. I'm an
> EE and only a portion of my job is software-related... the less
> complexity in what I do in this area, the better. I find that the MS
> tools to make things "easier" seem to work well when you do something
> simple, but as soon as you try to do something real which doesn't quite
> fit the mold you have to spend much more work understanding the tools
> and overriding their default options. The ATL stuff seems to fit this
> pattern to some degree.
Personally I would choose ATL/COM. You seem inclined to do the same.
However, I wanted to point out that it could be done in .NET as well.
>
>> By the way, in the COM world, you should not implement singleton objects.
> ?
> I found a webpage that cited putting
> DECLARE_CLASSFACTORY_SINGLETON(Cmyclass)
> in the declaration for Cmyclass. It seems to work as expected. Am I
> missing a subtlety here? (there's no warning in MSDN's docs for this
> macro)
I strongly urge you not to use it. This takes you into dangerous territory
needlessly. Remember what I told you in an earlier post... let each client
have their own instantiated object. Remember, the objects are all housed in
the same DLL or process, and they can share global variables or static class
member variables. You can even use a C++ singleton class. Just don't use a
COM singleton. If you search the archives you can see why. Also, I refer you
to Item 4 of Don Box's book "Effective COM", aptly titled "Beware the COM
singleton".
(DLL COM singletons are the worst creatures of all. EXE COM singletons do
work if coded carefully. But rather than you trying to figure out if your
project might qualify, you should be thinking about how to implement this
using my suggested approach. If it is not crystal clear, ask questions.)
>
> does this mean if a script stuffs a reference to one of my server's
> objects into a script variable, and lets it sit on the shelf, my server
> is required to honor that request? I understand the philosophy... in my
> case I have an object referring to information that exists in hardware
> which may be unplugged, at which point (from a practical sense) the
> object ceases to be useful. I guess I could always free up the object's
> resources & mark it as invalid, even if the object itself continues to
> exist forever.
Yes, it is the client that determines when to call Release() on your object.
Your object must continue to exist as long as the reference count doesn't
drop to zero. If the underlying resource is inaccessible, then you can
return an appropriate error message if the client tries to access it using
one of your object's properties or methods.
>
> I think I have to use MTA; while program A is using the serial port, I
> want program B to be able to check if the serial port is locked or
> unlocked, and that method call will block if I use STA on the same
> object. (right?)
The method call will block only if some other client is currently executing
another method call. I don't see why an STA won't work for you if you keep
your method calls very short. In other words, a call from one client may
lock the serial port (and this can be remembered by setting a global
boolean), and the call can return immediately. Then when another client
tries to access the serial port through another method call, the boolean
flag is checked.
When designing objects that are going to live in the STA, all you need to do
is avoid sleeping or waiting on a condition for "too long" a period of time.
Sometimes if there is work to be performed by the object that is going to
take a lot of time, it is better to launch a worker thread to carry out this
duty, allowing the main thread to return immediately. This complicates the
design a little, as it is important to make sure the thread is destroyed by
the time the object is released. But the advantage is that method calls are
serialized.
> I'm just not clear yet on the caveats of MTA... there
> must be some shared resources I don't know about that I have to
> synchronize manually...
Well, I can't help you here, because you are the designer. As designer, it
should be evident exactly what those shared resources are.
Brian
.
- Follow-Ups:
- References:
- Prev by Date: Re: beginner Q's about COM/.NET (context = exposing a pre-existing app to scripting)
- Next by Date: Re: Smart Type
- Previous by thread: Re: beginner Q's about COM/.NET (context = exposing a pre-existing app to scripting)
- Next by thread: Re: beginner Q's about COM/.NET (context = exposing a pre-existing app to scripting)
- Index(es):
Relevant Pages
|
