Even C++ had this much right... - Page 2


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 7 FirstFirst 1234 ... LastLast
Results 16 to 30 of 95

Thread: Even C++ had this much right...

  1. #16
    Kathleen Dollard Guest

    Re: Even C++ had this much right...

    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
    --




  2. #17
    Larry Serflaten Guest

    Re: Even C++ had this much right...


    "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




  3. #18
    Kathleen Dollard Guest

    Re: Even C++ had this much right...

    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
    --



  4. #19
    Larry Serflaten Guest

    Re: Even C++ had this much right...


    "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





  5. #20
    Jonathan Wood Guest

    Re: Even C++ had this much right...

    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



  6. #21
    Jonathan Wood Guest

    Re: Even C++ had this much right...

    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



  7. #22
    Ronald Laeremans [MSFT] Guest

    Re: Even C++ had this much right...

    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
    >
    >




  8. #23
    Ronald Laeremans [MSFT] Guest

    Re: Even C++ had this much right...

    [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
    >
    >




  9. #24
    Jonathan Wood Guest

    Re: Even C++ had this much right...

    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




  10. #25
    Kathleen Dollard Guest

    Re: Even C++ had this much right...

    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
    --



  11. #26
    Ronald Laeremans [MSFT] Guest

    Re: Even C++ had this much right...

    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





  12. #27
    Zane Thomas Guest

    Re: Even C++ had this much right...

    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.

  13. #28
    Ronald Laeremans [MSFT] Guest

    Re: Even C++ had this much right...

    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.





  14. #29
    Larry Serflaten Guest

    Re: Even C++ had this much right...

    "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





  15. #30
    Larry Serflaten Guest

    Re: Even C++ had this much right...


    "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



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center