3.5 child lazy load issue

I realize it is a little confusing. But it is not the UpdateChild() method that’s the issue. It is the ReadProperty() method.

So I ask you this:

If you have a case where a child reference CAN BE A NULL, and if I make ReadProperty() not create the child, what happens?

Does ReadProperty() throw an exception? Does it return null even though the child is not null (because it is not there)? Do I create some new generic type so it is possible for ReadProperty() to return a “PlaceHolder<T>” or something?

I hope you see my dilemma. You guys apparently don’t ever want/need a null child. That’s fine. But can you really speak for the entire user base of CSLA now and forever in saying that?

Or maybe we decide, here and now, that no one can/will ever have a null child reference. In which case I want several people on the record, so I can point future unhappy people to this thread ;)

Or maybe I’m missing some other answer.

Maybe the answer is for PropertyInfo<T> to have a “lazy load flag”. You’d set that in your property definition. Then ReadProperty() and GetProperty() would throw an exception if you tried to access them prior to calling LoadProperty() or SetProperty(). That would prevent accidental initialization of the property, without introducing ambiguous behavior.

My point is, and I think I’m right, that ReadProperty() can not return null here – because the value IS NOT NULL. It simply doesn’t exist, which is not the same thing.

Rocky

Just to add what Mike has stated.  The following test would fail when trying access the Resouces property:

            var p = Project.NewProject();
            p.Name = "Project Name";
            Assert.IsTrue(p.IsValid);
            try
            {
                p = p.Save();

                Assert.AreEqual(id, p.Id);
                Assert.AreEqual("Project Name", p.Name);
                 Assert.AreEqual(0, p.Resources.Count);   <-- null reference here

However, using FieldManager.UpdateChildren(this);  will work just fine.  So the conclusion is that using DataPortal.UpdateChild(ReadProperty(ResourcesProperty), this); on "lazy create property" will mess up the FieldExists test.  To me, that's unexpected.

Ricky

Wish list:

http://www.lhotka.net/cslabugs/edit_bug.aspx?id=303

I can see the dilemma. In my case, I did not not want to set a default value at all, but the default is null, so I think a "lazy load/can not be null/no default value" flag is a good idea. Then the call to DataPortal.UpdateChild would behave as expected for null and non-null child scenarios.

Regards
Mike

In terms of absolute correctness, the right answer is for ReadProperty/GetProperty to throw an exception if the value hasn’t been initialized (for a lazy loaded property). There is no valid default for something that hasn’t been initialized, and trying to access the uninitialized value is basically a bug.

Rocky

rasupit:

I think is fine to return null (default value) when ReadProperty could not find any value.

I don't.  It doesn't make any sense most of the time, and I think it would cause problems with databinding.  If something asks for the collection, I think it's reasonable to assume you get the collection... not null.