Even C++ had this much right...

[Kathleen Dollard]

Ronald,

I haven't responded yet because I wanted to think about what you are
suggesting. My first reaction was to waffle between "I don't think soooo" in
my best "**** no" tone of voice and "sure, that covers it". I am trying to
get my head around the implications. Sleeping on it didn't help.

I am afraid that it comes up against my understanding of some nuances of the
meaning of "value types" that can not be "boxed". My instinct was to back
channel that with some smart friends and not admit that I am uncertain of
this. However, it is likely that other people are also wondering about the
details of limitations on this type of class (other than requiring a special
collection-and could that collection also hold non-resource classes, and not
being able to include them in non-resource value types).

In reviewing value types, this implies that the resource class is sealed
(can't inherit from it), does not implement or define any interfaces, and
its data is copied when it is assigned to a new variable or passed to a
function.

They could, however, contain non-resource objects? So, I could write a
simple gatekeeper class that contained a reference to a private object? The
resource-type would go out of scope, its reference to the internal class
would go out of scope, GC would be run, and if nothing else held the
reference (no other copies of this particular instance of the value-type
existed) then the private object would go out of existence? Do I have that
right?

There is a lot of ugliness involved in what I am seeing this look like in
the real world. However, that ugliness is all tied up in the resource-type
and does not have to be forced onto the end user. This makes it acceptable
to me, but I wonder if it really would be transparent to the class-user. How
much would that programmer have to know about the fact that this was a
resource-type?

If I have this much right, I can't help but wonder why it isn't a compiler
issue. If I mark the internal, normal class as a "resource" why can't the
compiler build the wrapping resource-type that exposes the public class to
the real world?

Given an imaginary resource-type as you are see it, and the following
(stupid) code, when would the GC be run (I count 4 times?), and would there
at one point be 4 copies of the resource-type's data in memory?

Public Sub Foo
Dim x1 As CResource
Dim x2 As CResource
Dim x3 as CResource
x1 = new CResource()
x2 = x1
x3 = Bar(x2)
x2 = nothing
' more stuff
End sub

Private function Bar(x as CResource) as CResource
Return x
End Function

Perhaps you could also give some other examples of when GC would and would
not be run under your scenario.

How expensive is this GC likely to be? It would be significantly more
difficult for you to offer ref counting only on these rare resource-types?

Also, would it be significantly more difficult for you to implement this by
raising an event when one went out of scope. Course it would be lovely if
you could let us know when a new copy was created so we could do our own ref
counting.

The "very expensive" solution you propose deserves more thought and
discussion. It might be sufficient to provide some mechanism for insulating
the end user from the fact that a resource is in use. I am not sure it
solves the case where a class is written that is not a resource-user, and is
later changed to become a resource user.

--
Kathleen
(MS-MVP)
Reply in the newsgroup so everyone can benefit
--

[Larry Serflaten]

"Kathleen Dollard" <kathleen@nomailplease.org> wrote

> I completely disagree with this. I see two sets of programmers (or myself in
> two different scenarios). One is a class creator and the other is a class
> user.

I don't see a difference. Both of them create and use classes, some of
which will need special handling.


>The class creator must be aware of resource issues. This is
> appropriate and that person needs to be able to control the resources.

Alright, but when the resource is released, isn't that the time to run the GC,
so that all your references to the resources get destroyed?


>The class user should not need to know anything about where a particular piece
> of data or functionality is coming from. The class user should not have to
> control, and in some cases should not be able to control resources, imo.

So, if that user opens a file, or DB or whatever, are they not responsible for
closing it? And if that user calls on one of your special classes, could you
not provide Open and Close methods to remind them how to use the class?

In other words, it seems to be more of an implemetation issue. You, as
a class builder, are responsible for taking care of the resources you use.
In that class you have to create and destroy the resources over the lifecycle
of the class.

But you cannot control how the user writes code, they may not treat the
resources they use, correctly. In that case, their programs suffer for not
following proper guidelines, whether or not they happen to use your class.

Whatever resources they do use, could be mishandled. Yet you want to be
insulated from such a user.... OK then, why aren't the resources you use,
insulated from the 'user'? Shouldn't they be?


> With the current complete lack of DF, this responsibility is forced on the
> class user, it makes no difference whether it is one line of code or 200
> lines of code.

As a class creator, you are the user of the resource. It falls upon you to
treat those resources with proper respect. What you expose to the user
may not look anything like the resource you are using, but you still need
them to treat your class with the proper respect. What you are asking for
is a way to insure that the resource is not compromised because the user
failed in their duties. In other words, you do not want to rely on the user
to do the right thing. If that were possible, why wouldn't such a condition
be applied to the resources you use?

It just seems to me that the 'users' reference he holds to your special class
is not the issue, that can actually hang on until the GC does get around to it.
What is at issue is your references to the resources you used. They are the
ones that need to be taken care of. What ever scheme they come up with
to insulate you from your user, would actually be better put to use at the
source, namely, the resource you used, so that it does not rely on you to
properly handle that resource. The reason I say this is because your user,
the slob that he is, can bypass your class and try to go direct to the resource.
So, in the end, if he fails to treat that resource with proper respect, then his
code suffers. And, the way it stands now, if he fails to treat your class with
proper respect, his code still suffers.

What it boils down to is that you would have a sense of confidense if there
were some method to insure your class gets treated correctly. Well, as you
are aware, the managed objects come from classes in CLR. If MS does
come up with a scheme to solve the issue, would it not be better served to
incorporate it into the classes you use, instead of the classes you make?

What I have in mind is that Mousepointer issue, where a property is set on
creation and reset on destruction. Where that needs to be addressed is
at the forms MousePointer property, so that when the object who changed
the setting falls out of scope, that property reverts back to what it was. Or
something like that. Of course there are cases were the property is to be
left set, even after the setting object goes out of scope, and that could be
an attribute of the value used to set it, or there might be a 'Retain' method
on the form to indicate that the current settings are to be retained, so that
they still act as I described execpt that the defaults now include the set
property value...

Again, I am more in favor of attacking the problem at the source, rather than
further down the chain. The solution Ronald offered does not fully address
the issue (that being sloppy coders). All it does is give the class builder a
sense of familiarity with the way his objects gets used.

LFS

[Kathleen Dollard]

Larry,


> > I completely disagree with this. I see two sets of programmers (or
myself in
> > two different scenarios). One is a class creator and the other is a
class
> > user.
>
> I don't see a difference. Both of them create and use classes, some of
> which will need special handling.

Then do you see any value in encapsulation? The fact that a specific (rare)
class has a resource that needs to be released is a detail of the
implementation of the class. If the user asks this class to do a specific
set of jobs, then why should the user have to know that the class uses a
resource to accomplish it. Encapsulation makes the difference between these
two types of programmers in relation to the specific class, one knows, and
programs the implementation of the class, the other only sees the interface.

> So, if that user opens a file, or DB or whatever, are they not responsible
for
> closing it? And if that user calls on one of your special classes, could
you
> not provide Open and Close methods to remind them how to use the class?

I could of course. And in some cases I think this is approprite. If I write
a class that emulates a database connection, it is reasonable to have an
open and close method. If I write a class that calculates the CEO's salary,
why should the class user have to know that it uses any resources?

> As a class creator, you are the user of the resource. It falls upon you
to
> treat those resources with proper respect. What you expose to the user
> may not look anything like the resource you are using, but you still need
> them to treat your class with the proper respect. What you are asking for
> is a way to insure that the resource is not compromised because the user
> failed in their duties. In other words, you do not want to rely on the
user
> to do the right thing. If that were possible, why wouldn't such a
condition
> be applied to the resources you use?

As a matter of principle, my job as a class creator is to make the class as
simple as possible. I want to rely on that user as little as possible, and
allow them to think about other aspects of the application.

> What is at issue is your references to the resources you used. They are
the
> ones that need to be taken care of. What ever scheme they come up with
> to insulate you from your user, would actually be better put to use at the
> source, namely, the resource you used, so that it does not rely on you to
> properly handle that resource.

I agree in some cases.

But there are still scenarios where I want to control the clean-up.

> What I have in mind is that Mousepointer issue, where a property is set on
> creation and reset on destruction.

I used that one. We were taking advantage of how COM actually . It doesn't
bother me that this doesn't work the same way (and in Ronald's scenario
would be a bad idea).

> Again, I am more in favor of attacking the problem at the source, rather
than
> further down the chain. The solution Ronald offered does not fully
address
> the issue (that being sloppy coders). All it does is give the class
builder a
> sense of familiarity with the way his objects gets used.

I don't perceive this as a problem with sloppy coders. I almost like the
fact that Ronald's solution sounds like it would be rather ugly on the class
side. I really hope it doesn't get used because of familiarity. There are
cases where being able to control DF would improve the robustness of
classes.

--
Kathleen
(MS-MVP)
Reply in the newsgroup so everyone can benefit
--

[Larry Serflaten]

"Kathleen Dollard" <kathleen@nomailplease.org> wrote
> Larry,
>
> Then do you see any value in encapsulation? The fact that a specific (rare)
> class has a resource that needs to be released is a detail of the
> implementation of the class. If the user asks this class to do a specific
> set of jobs, then why should the user have to know that the class uses a
> resource to accomplish it. Encapsulation makes the difference between these
> two types of programmers in relation to the specific class, one knows, and
> programs the implementation of the class, the other only sees the interface.

Yes, I see the value in encapsulation. Also I am sure you , and many others,
have significantly more experience in this area than I. My view of the problem
ranges from opening a local file, to establishing a remote connection. The local
file can be open and closed when needed, or is otherwise not a problem, but
the remote connection may take a while to establish so that we don't want to
open and close it as we would a file. But that is what I tend to lean towards.
If your class requires a resource to provide some task, then it should grab the
resource when needed, and release it when done.

> If I write a class that calculates the CEO's salary,
> why should the class user have to know that it uses any resources?

This is the type of task that I mean, when the user calls on your class to
calculate the salary, then you need to gather your resources to complete
the task, and release them before returning the result.

But, supposing that you had a set of functions that relied on a dial up connection
to somewhere, then you would not want to close that connection between function
calls. So, in this case, the Open and Close senareo would be my recommendation.
Let me also state (for the benefit of anyone reading this) that I am using Open/Close
only as a pattern, I expect that the Close might actually be a call to Dispose, which is
the recommended clean up procedure.


>
> As a matter of principle, my job as a class creator is to make the class as
> simple as possible. I want to rely on that user as little as possible, and
> allow them to think about other aspects of the application.

Thanks, your users will appreciate it! <g>


> > What is at issue is your references to the resources you used. They are the
> > ones that need to be taken care of. What ever scheme they come up with
> > to insulate you from your user, would actually be better put to use at the
> > source,

> I agree in some cases.
>
> But there are still scenarios where I want to control the clean-up.

Again, you have no doubt been exposed to many more situations than I
can think of at this time. But I suspect that most of your resource requirements
will fall somewhere between opening a file, and opening a connection.
Somewhere in that range there will be a point where it makes more sence to
leave the connection open, but I would have to decide each case individually.
What do you mean by 'want to control'? And, which scenareos are you concerned
with most?


> I don't perceive this as a problem with sloppy coders.

You are correct. But if we were not concerned about the users, then why bother
with encapsulation? I think the two issues are more or less linked, to achieve the
same results. Encapsulation provides for easier use, while at the same time, insures
a sturdy design. Or, perhaps that should be vice versa, either way, its the same result.

Can you provide some example (perhaps grey area) patterns where you want control
of DF?

Thanks!
LFS

[Jonathan Wood]

Ronald,

> How would you (and fellow VB developers) feel if resource objects were a
> special type that had some restrictions? I.e. they would be value types
> (stack or static allocated) and you could not put them into collections,
or
> box them, or include them in other value types (but you would be able to
> include them in other resource type classes) and there would be perhaps 1
> special case collection object you could store them in.

The primary benefit of DF is that developers can use a class with much less
concern about how it works internally. The above sounds like a whole other
set of concerns developers must be aware of in order to use a class.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Jonathan Wood]

Ronald,

> Note that existing programs (with the default policy) will just execute
with
> the version (plus patches) of the runtime they were developed against; so
> that is definitely a big part of the side by side story. As far as source
> code compatibility is concerned, I don't even think we ever broke
> compatibility going forward _on the same API platform_ to any significant
> degree. So I don't think it is likely we are going to in the future.

This is a concern I have. Obviously, the goal is to keep APIs on a given
platform backward compatible. But I would be really surprised if MS has not
failed in this respect on more than one occasion. With .NET, it seems like
it would really become an important issue. If compatibility was ever broken,
how would users run my older programs? With tens of MBs of runtime required,
would I be safer to ask all my customers to save those runtimes in case one
of them is ever needed on some computer system they are using in the future?

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Ronald Laeremans [MSFT]]

That will just happen. Installing newer version of the runtime will _never_
uninstall older versions, and your components (absent a publisher policy
file you ship or an admin override) will work against the version they were
built against. So you don't have to ask your users anything.

The runtime size is on the order of 20 MB or so. I hope that I am not going
to scare anyone by stating that accumulating say 1 new version a year of a
similar footprint isn't going to amount to any significant percentage of
disk use on any reasonable PC.

-Ronald-

"Jonathan Wood" <jwood@softcircuits.com> wrote in message
news:3b804fc6@news.devx.com...
> Ronald,
>
> > Note that existing programs (with the default policy) will just execute
> with
> > the version (plus patches) of the runtime they were developed against;
so
> > that is definitely a big part of the side by side story. As far as
source
> > code compatibility is concerned, I don't even think we ever broke
> > compatibility going forward _on the same API platform_ to any
significant
> > degree. So I don't think it is likely we are going to in the future.
>
> This is a concern I have. Obviously, the goal is to keep APIs on a given
> platform backward compatible. But I would be really surprised if MS has
not
> failed in this respect on more than one occasion. With .NET, it seems like
> it would really become an important issue. If compatibility was ever
broken,
> how would users run my older programs? With tens of MBs of runtime
required,
> would I be safer to ask all my customers to save those runtimes in case
one
> of them is ever needed on some computer system they are using in the
future?
>
> --
> Jonathan Wood
> SoftCircuits Programming
> http://www.softcircuits.com
>
>

[Ronald Laeremans [MSFT]]

[Replying to the entire thread, if I missed specific points addressed in
posts, please remind me. And please do remember, that this is a brain
storming thread not me explaining or selling any solution we have come up
with.]

That is basically the problem. It is not possible to introduce reference
counting for a normal gc type, or even for a normal value type because that
would leak refcounting into the entire system (detailed explanations in
Brian Harry's mail about why that is and why that isn't acceptable).

So the only solutions we can currently see are along the lines I mentioned
in my earlier mail:
1) Have a type that is more restricted than a normal value type and that
does offer scope based (and thus automatic and deterministic) finalization;
but that is guaranteed not to leak into normal value types or into reference
types
2) Work with the gc is some fashion, which requires triggering a full gc in
some circumstances, going from "whenever you ever release one of those
resource objects" to a more sophisticated system

Note that DF as exposed by VB 6 is used for several different scenarios, of
which not all fit the same pattern and need to be solved by the same
solution in the .NET world

1) My type encapsulates a scarce resource of which there is only 1, and I
need DF in my programming model. Example: A file object. I want it to be
closed from the moment I am done with it, because otherwise it stays locked
and I can't create a new instance that references to the same underlying
file.

2) My type encapsulates no resource, I am just using scope to trigger an
action. Example: the famous Wait Cursor class.

3) My type encapsulates a resource of which there are just a very few.
Example: a handle to a DC in Win9x (there are only 5, but not other GDI
objects you can allocate several hundreds or thousands). DB connection
handles for a DB licensed through a connection count and not a connected
user or other mechanism could fall into the same category.

4) My type encapsulates a resource for which there are hundreds to thousands
of instances available, but not an infinite number, or performance goes down
significantly if I am using too many. Examples: many here: DB handles, file
handles in general, sockets, GDI objects, thread objects, most other kernel
objects.

For the 4th type, a handle collector solution is probably ideal.
For the first 2, it seems a solution that is scope based is the only
possible solution.
And number 3 seems to fall somewhere in between.

For all scenarios (except maybe 2) the other question is, how many times are
you mainly interested in a solution where the instances of such a
resource-containing type will not leave scope, or to put it in other words,
will not need to survive past the exit of the function they were created in?
Or to put it in yet other words, in how many cases would a souped up version
of the C# using block work for you. With part of the souping up being that
the decision would be on the creator of the type, not on the consumer as to
whether it got scope-based cleanup.

-Ronald-

"Jonathan Wood" <jwood@softcircuits.com> wrote in message
news:3b804d9f@news.devx.com...
> Ronald,
>
> > How would you (and fellow VB developers) feel if resource objects were a
> > special type that had some restrictions? I.e. they would be value types
> > (stack or static allocated) and you could not put them into collections,
> or
> > box them, or include them in other value types (but you would be able to
> > include them in other resource type classes) and there would be perhaps
1
> > special case collection object you could store them in.
>
> The primary benefit of DF is that developers can use a class with much
less
> concern about how it works internally. The above sounds like a whole other
> set of concerns developers must be aware of in order to use a class.
>
> --
> Jonathan Wood
> SoftCircuits Programming
> http://www.softcircuits.com
>
>

[Jonathan Wood]

Ronald,

> That will just happen. Installing newer version of the runtime will
_never_
> uninstall older versions, and your components (absent a publisher policy
> file you ship or an admin override) will work against the version they
were
> built against. So you don't have to ask your users anything.

It may be that I'm missing something (I hope I am) that would prevent this
from being an issue but I'm confused why no one else seems to recognize my
concerns here.

Let's say you purchase a .NET program from me in the near future. Since I'm
going to assume the runtime will be on future versions of Windows, I'm not
going to send you the entire 10s of MBs of runtime--just my program. It
works fine. You continue to upgrade your system. Still, the program
continues to run fine.

It isn't unreasonable to imagine that one day you might clear your hard disk
and reinstall Windows, replace the hard drive, or even buy a new computer.
At that time, you will reinstall your current version of Windows. If there
is any part of the .NET runtimes included with that version of Windows that
is not fully compatible with the program you bought from me, then how will
that program run unless I include the entire runtime on my install disk?

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Kathleen Dollard]

Larry,

> Can you provide some example (perhaps grey area) patterns where you want
control
> of DF?

A class that may connect to external data transparently to the programmer.
Or one where the connection management may change over time, or based on
scenario (for example, a class that can work over a LAN or a Internet
connection depending on user location. Where the connection is dropped over
the LAN, but a dial-up connection is maintained. The using programmer
doesn't even need to know how it deprecates.

Data retrieved from an Excel application. Where the spreadsheet, and Excel
should be released when the object no longer exists, but where the object
has no meaning except representing the underlying Excel data. And, oh, btw,
if the spreadsheet is redesigned such that I want the data fed into memory
then Excel released, I don't want a legacy Dispose/Close method to confuse
future programmers.

Are those the kind of specifics you were looking for?

> Somewhere in that range there will be a point where it makes more sence to
> leave the connection open, but I would have to decide each case
individually.
> What do you mean by 'want to control'? And, which scenareos are you
concerned
> with most?

"I would have to decide each case individually" and would you expect that
decision to be static over time? Would you want the class designer or class
user to make that decision? My biggest concern about DF is the evolving
class where external changes shift the decision about what to do with the
resource. The lack of DF means that shifting this decision either force
significant change in existing apps, or legacy crap (unneeded
Dispose/Close).

Unfortunately, Ronald's solution may not be sufficient here. Not all classes
could be reframed as resource classes.

--
Kathleen
(MS-MVP)
Reply in the newsgroup so everyone can benefit
--

[Ronald Laeremans [MSFT]]

You should include the install for the .NET runtime with your program, or
have the install point to the Microsoft site where it can be downloaded. Or
when new versions come out, update your applications (if needed) or ship a
publisher policy file telling your application to work with a newer version
of the runtime.

I might be missing the magic bullet you are thinking of that would get an
application vendor out of supporting any of these options and still having
their application work with future side-by-side versions of the CLR (or of
any runtime for that matter). As far as I can see it you either ship with
your dependencies that you cannot guarantee will be there, or you ensure you
work with future versions of your dependencies that you can guarantee will
be there.

BTW, I don't see how you will be able to assume the current version of the
runtime will be on all machines in any near future. E.g. Windows 98, NT 4
client, Windows 2000 will not be going away anywhere soon. While the CLR
install will be available in many forms, I think you will be guaranteed that
quite a few users will not have it on their machines in the next few years.

-Ronald-

"Jonathan Wood" <jwood@softcircuits.com> wrote in message
news:3b8067e0@news.devx.com...
> Ronald,
>
> > That will just happen. Installing newer version of the runtime will
> _never_
> > uninstall older versions, and your components (absent a publisher policy
> > file you ship or an admin override) will work against the version they
> were
> > built against. So you don't have to ask your users anything.
>
> It may be that I'm missing something (I hope I am) that would prevent this
> from being an issue but I'm confused why no one else seems to recognize my
> concerns here.
>
> Let's say you purchase a .NET program from me in the near future. Since
I'm
> going to assume the runtime will be on future versions of Windows, I'm not
> going to send you the entire 10s of MBs of runtime--just my program. It
> works fine. You continue to upgrade your system. Still, the program
> continues to run fine.
>
> It isn't unreasonable to imagine that one day you might clear your hard
disk
> and reinstall Windows, replace the hard drive, or even buy a new computer.
> At that time, you will reinstall your current version of Windows. If there
> is any part of the .NET runtimes included with that version of Windows
that
> is not fully compatible with the program you bought from me, then how will
> that program run unless I include the entire runtime on my install disk?
>
> --
> Jonathan Wood
> SoftCircuits Programming
> http://www.softcircuits.com

[Zane Thomas]

On Sun, 19 Aug 2001 20:33:56 -0700, "Ronald Laeremans [MSFT]"
<ronlaere@microsoft.com> wrote:

>While the CLR
>install will be available in many forms, I think you will be guaranteed that
>quite a few users will not have it on their machines in the next few years.

Is the CLR going to ship with future versions of IE? That would help
distribution, I think.


--
The nice thing about standards is that
there are so many of them to choose from.

[Ronald Laeremans [MSFT]]

I do not know. Even then not everyone installs recent versions of IE.

-Ronald-

"Zane Thomas" <zane@mabry.com> wrote in message
news:3bae89b0.262707687@news.devx.com...
> On Sun, 19 Aug 2001 20:33:56 -0700, "Ronald Laeremans [MSFT]"
> <ronlaere@microsoft.com> wrote:
>
> >While the CLR
> >install will be available in many forms, I think you will be guaranteed
that
> >quite a few users will not have it on their machines in the next few
years.
>
> Is the CLR going to ship with future versions of IE? That would help
> distribution, I think.

[Larry Serflaten]

"Ronald Laeremans [MSFT]" <ronlaere@microsoft.com> wrote
>
> Note that DF as exposed by VB 6 is used for several different scenarios, of
> which not all fit the same pattern and need to be solved by the same
> solution in the .NET world

You might want to watch out for that. That is not necessarily the case. It
may happen that two (or more) different solutions are needed to address
and recover from all of the cases you have listed.

My first inclination is to look for workable code in all of the situations you
have listed, and then go through and look for common ground among the
workable code. I fully expect that some may fit into one pattern, while others
may fit better into another.

Unfortunately, I am in a position at this time where I cannot test any
solutions. I have uninstalled beta 1 and am still working on getting beta 2
installed. (I am reorganizing one partition in preparation for a selective
file-by-file backup of data from the boot partition, in preparation for a
fresh install of the OS)

>
> 1) My type encapsulates a scarce resource of which there is only 1, and I
> need DF in my programming model. Example: A file object. I want it to be
> closed from the moment I am done with it, because otherwise it stays locked
> and I can't create a new instance that references to the same underlying
> file.

I was thinking the older style Open and Close statements would not be a problem,
whereas using Sytem.IO (File) classes would exhibit the problem above. If that
is the case, then the solution for this would be to use the older format. Otherwise,
if they need that single resource repeatedly, and can't normally get at it (again) until
after a GC cycle, then (for the most part) they are not done with it until the app ends...


>
> 2) My type encapsulates no resource, I am just using scope to trigger an
> action. Example: the famous Wait Cursor class.

I was thinking this is a tough one to solve, without using a scope based solution.
And, as I said in another post, we may need to find some way to provide a means
to fall back to a default condition for an object's properties, once the object that set
them falls out of scope. As you said, this is a brainstorming session, so let me
suggest this:

Consider an object as a tablet (table of properties) with a set of onion skins that
overlay the tablet. When a user creates an object, it fires up with a predetermined
set of property values. For each routine that sets properties on that object, a new
layer of onion skin is laid on top of the tablet. Meaning a duplicate object is
created except this object has it properties set to the new values. These skins
would be dependant on the class were the subroutine is. So that, when an
object/class gets placed in the GC que, any skins it created become unreachable.
The creation of these skins happen on a procedural level, so that the first property
set creates a new instance (onion skin) which is referenced for the remainder of
that procedure. This allows the user to set and use different properties in different
sections of the procedure, without them all creating a new 'skin'. When the
procedure ends, that skin is 'overlayed' on the tablet so that the runtime sees
all the changes made. Meaning the original object (reference) is held in reserve,
and the object (reference) with the changed properties is substituted for all future
calls. Under normal circumstances, when the user releases the object, it simply
waits in the GC que to be destroyed. The reserved object gets GC'ed and the skins
become invalid. If that object is non destructable, as is the case in the Wait Cursor
case where the App still has a reference to the Form so it cannot be destroyed, then
only the onion skins become invalid (their 'creator' is in the GC que) and its most
recent (still valid) skins are the ones used by the runtime.

As I see it, the tricky part is how to maintain an onion skin so that everyone knows
which one to use. To work as planned, any class that changes properties on an
(global) object has to inform the runtime engine that it now holds the current reference
to that object. Also, the runtime engine has to keep a list of who owned the 'current
reference' so that if the object it thought had the current reference is no longer
available, it can 'unwind' the list until it finds a valid object, so that a reference to
its onion skin can be used. In this way, its the objects who hold references to
the skins, so that when such an object gets placed in the GC que, any and all
of the skins it holds become unreachable. The bad news is that these skins would
multiply like rabbits, but as their name suggests they should be extremely light,
even if the object they represent is complex.

This is not scope based, in that references are not destroyed (placed in the que)
because some object went out of scope, but it acts like it is because the skins
that were created become unreachable when the object that created them gets
placed in the que. To clarify, a skin should be less than a shallow copy of an object
with a few properties set to different values.

Again, this is just a suggestion, and it is apparent that such a solution, if found
workable, would (almost) need to be implemented in (or near) the base Object
class so that (nearly) all objects exhibit the onion skin idea.


>
> 3) My type encapsulates a resource of which there are just a very few.
> Example: a handle to a DC in Win9x (there are only 5, but not other GDI
> objects you can allocate several hundreds or thousands). DB connection
> handles for a DB licensed through a connection count and not a connected
> user or other mechanism could fall into the same category.

We have to work inside the boundries of the language, so it seems to me, this
is similar to #1, in that the object referenced should not be released until the
app is done with it. The fact that there are only a few available is a result of
the object provider's decision, is it not? It will be up to them to decide what a
more appropreate value would be, running on the .Net platform. For example,
why are there only 5 hDC handles in Win9x, as you state? I know that is now
a limitation, due to Win9x already being released, but in the future, such
limitations might be given more consideration. That could then be solved by
attrition (older versions falling out of use) rather than changes to the platform.

>
> 4) My type encapsulates a resource for which there are hundreds to thousands
> of instances available, but not an infinite number, or performance goes down
> significantly if I am using too many. Examples: many here: DB handles, file
> handles in general, sockets, GDI objects, thread objects, most other kernel
> objects.
>
> For the 4th type, a handle collector solution is probably ideal.

As I said, more than one solution may be needed....


> For all scenarios (except maybe 2) the other question is, how many times are
> you mainly interested in a solution where the instances of such a
> resource-containing type will not leave scope, or to put it in other words,
> will not need to survive past the exit of the function they were created in?
> Or to put it in yet other words, in how many cases would a souped up version
> of the C# using block work for you. With part of the souping up being that
> the decision would be on the creator of the type, not on the consumer as to
> whether it got scope-based cleanup.

As I told Kathleen, I am not all that experienced in these differing variations.
My experience has been in desktop applications where a local DB has been
about the closest I got to these issues.

(So maybe I'll just keep quiet now and see what others suggest :-)

LFS

[Larry Serflaten]

"Kathleen Dollard" <kathleen@nomailplease.org> wrote

> A class that may connect to external data transparently to the programmer.
> Or one where the connection management may change over time, or based on
> scenario (for example, a class that can work over a LAN or a Internet
> connection depending on user location. Where the connection is dropped over
> the LAN, but a dial-up connection is maintained. The using programmer
> doesn't even need to know how it deprecates.

I am under the impression, that should not be effected by GC or DF. In either
case you have determined the connection type, so when a class making the
the connection (using a connection class) is done with the connection, that
connection class is either released to the GC (LAN) , or held open (Dial-up)
until the class who is using the connection is no longer needed.

>
> Data retrieved from an Excel application. Where the spreadsheet, and Excel
> should be released when the object no longer exists, but where the object
> has no meaning except representing the underlying Excel data. And, oh, btw,
> if the spreadsheet is redesigned such that I want the data fed into memory
> then Excel released,
>
> Are those the kind of specifics you were looking for?

Yes except that your second issue went over my head... <g>

"has no meaning except representing the underlying Excel data"

Is that a class full of references into an Excel object, or an object that has
specific (state) values?

> I don't want a legacy Dispose/Close method to confuse
> future programmers.

Dispose is the future, that _will_ be expected in .Net, correct?


> "I would have to decide each case individually" and would you expect that
> decision to be static over time? Would you want the class designer or class
> user to make that decision?

Yes, (I think!) Once a solution is found, I would expect it to be static, or,
unchanging, in that version of the class....


> My biggest concern about DF is the evolving
> class where external changes shift the decision about what to do with the
> resource. The lack of DF means that shifting this decision either force
> significant change in existing apps, or legacy crap (unneeded
> Dispose/Close).
>

Thanks for responding, but perhaps I am to foggy minded (at this early hour)
to groc what you are refering to. I can understand how external conditions
might effect how you want to respond, but I fail to see how that relates to DF....

LFS