>> dim f1, f2 as folderItem
>> f1 = new folder(f2)
>>
>> then I get a NilObjectException, because f2 is nil.
> The "new" operator can't return nil...
Wait a sec...from the 4.5 Language Reference, p.311:
"When you try to create an object with the New operator, the application may
not have enough memory to actually create the object. If so, the 'new'
object will actually be Nil. Before proceeding, it is best to test for a Nil
object before proceeding."
Think-aloud: So new _can_ return nil sometimes. My question remains: should
it do so if it's invoking a copy constructor with a nil argument?
Today the answer might be no just because it could break existing code. But
in the spirit of the copy constructor, I'd say yes. I like the notion of
being able to get a nil copy without writing a special copy routine for
every class that it might pertain to. I want a copy of X, so if X is nil, I
want nil.
But some copy ctors might require a non-nil constructor, which is also
legit. So I guess you couldn't have the runtime auto-recognize the
situation; you'd need some syntax the constructor could use. (In C++, could
you say "if src = 0 {this = 0; return;}" in the constructor?)
That's as far as I feel like thinking about this, since it probably isn't
going to happen...
lj
---
A searchable archive of this list is available at:
<http://dbserver.realsoftware.com/KBDB/search.php>
Unsubscribe:
<mailto:realbasic-betas-off at lists dot realsoftware dot com>
Subscribe to the digest:
<mailto:realbasic-betas-digest at lists dot realsoftware dot com>
.
|