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

"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

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

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

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

"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

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

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

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