Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder General » View Thread |
Messages 1 to 9 of 9 total |
TObjectList OwnsObjects |
Fri, Sep 16 2016 6:13 AM | Permanent Link |
Matthew Jones | Could TObjectList.OwnsObjects be made writeable please? I realise that
this is a possible oops, but it would really help me a lot. Basically, I have an object which contains a TObjectList. It does clever things with the objects in it. And I have one that owns the objects. Now though I want a temporary list of some objects, and this object should not own the objects. I could of course use the constructor, but to be able to just say "OwnsObjects := false" would be a lot simpler. Sure, this might cause someone to leak or something (you could create an exception if turning them off and it already has objects, but I think that's a buyer beware thing. Just adding the write option to the property would make it all a lot easier in some situations. Thanks for considering. 8-) -- Matthew Jones |
Fri, Sep 16 2016 7:42 AM | Permanent Link |
Michael Dreher | "Matthew Jones" wrote:
// Could TObjectList.OwnsObjects be made writeable please? // I realise that this is a possible oops, but it would really help me a lot. // ... Could TObjectList.OwnsObjects remain private access please? The TObjectList instances and client functions that operate on them otherwise will lose the control. On every list operation you have to check, if the ownership was changed in the meanwhile. Sure, making thinks public (or local to global) makes it easier to acces and is harmless for small programs. But in a base class in a framework operating on very ground? I'd rather not. Michael Dreher |
Fri, Sep 16 2016 7:52 AM | Permanent Link |
Matthew Jones | Michael Dreher wrote:
> otherwise will lose the control How? You don't need to change it. Heck, there are functions for adding and removing items too! Perhaps having a procedure that has an obscure name might satisfy such a requirement then. So "ChangeOwnerStatusBeware(false)" to prevent accidental changes (not that I'd think anyone would really change it accidentally!). -- Matthew Jones |
Fri, Sep 16 2016 9:00 AM | Permanent Link |
Raul Team Elevate | On 9/16/2016 7:52 AM, Matthew Jones wrote:
>> otherwise will lose the control > > How? You don't need to change it. Heck, there are functions for adding > and removing items too! I'm with Matthew on this - it's fairly trivial to check ownobjects since it really only matters when objects are released., TObjectlist is also a basic building block and should be flexible. If framework/component needs to control object lifetime then it needs to expose this data in a more safe way. Otherwise crash out and make it possible for dev to figure out what happened. > Perhaps having a procedure that has an obscure name might satisfy such > a requirement then. So "ChangeOwnerStatusBeware(false)" to prevent > accidental changes (not that I'd think anyone would really change it > accidentally!). If you expose some functionality then do it logically and cleanly - doing these things just adds confusion IMHO down the road. Raul |
Fri, Sep 16 2016 9:14 AM | Permanent Link |
Matthew Jones | Raul wrote:
> TObjectlist is also a basic building block and should be flexible. Having just beein digging more, it also already has procedure Delete(Index: Integer; FreeOwnedObject: Boolean=True); which allows you to get around the ownsObjects parameter to an extent. Making lifetime management easier for a developer is an important thing IMO, and being able to make a list flexible in purpose would be good. -- Matthew Jones |
Mon, Sep 19 2016 3:30 AM | Permanent Link |
Michael Dreher | "Matthew Jones" wrote:
// Having just beein digging more, it also already has // procedure Delete(Index: Integer; FreeOwnedObject: Boolean=True); // which allows you to get around the ownsObjects parameter to an extent. Yes, it's powerfull for transfering ownership, for example, and it's devilish. This "flexibility" has the drawback of a possible loss of integrity. // Making lifetime management easier for a developer is an important thing // IMO, and being able to make a list flexible in purpose would be good. All this Pascal to JavaScript compiling is about reducing your flexibility to keep your project more maintainable. Of cource, sometimes there are practical issues for such tradeoffs. Michael Dreher |
Mon, Sep 19 2016 4:47 AM | Permanent Link |
Matthew Jones | Michael Dreher wrote:
> All this Pascal to JavaScript compiling is about reducing your > flexibility to keep your project more maintainable. Of cource, > sometimes there are practical issues for such tradeoffs. Indeed, but we have chosen the Pascal managed memory route, so must live with it. I very much like the C# "ignore memory" coding, but it was a very practical issue that I hit. I could actually have modified more with a constructor variation, but I'm not sure if I can hide the default constructor to stop accidents. Better to make the ownership option explicit IMO. -- Matthew Jones |
Mon, Sep 19 2016 7:45 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Matthew,
<< Could TObjectList.OwnsObjects be made writeable please? >> There's no need. If you need to copy an owned list of objects to one that isn't owned, just create the second instance with False as the constructor parameter, and then use the AddObjects method to add the object references from the first instance to the second instance: http://www.elevatesoft.com/manual?action=viewmethod&id=ewb2&comp=TObjectList&method=AddObjects Tim Young Elevate Software www.elevatesoft.com |
Mon, Sep 19 2016 8:11 AM | Permanent Link |
Matthew Jones | Tim Young [Elevate Software] wrote:
> Matthew, > > << Could TObjectList.OwnsObjects be made writeable please? >> > > There's no need. If you need to copy an owned list of objects to one > that isn't owned, just create the second instance with False as the > constructor parameter, and then use the AddObjects method to add the > object references from the first instance to the second instance: Key is, the constructor of my class doesn't know it needs to be that way, so it is an "after the fact" change. That said, I obviously could change my constructor, but the problem I have with that is the default constructor. Is it possible to "hide" that so that normal code cannot call it? I think the issue I had was with the persistent derived classes, which are created in arrays, they needed to have the default constructor. But I'm fuzzy on that so maybe I'm barking up the wrong problem. Nonetheless, I think it would be a good thing to be able to change the status... -- Matthew Jones |
This web page was last updated on Friday, November 1, 2024 at 07:01 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |