--------------------------------------------------------------
(Dammit, I need a sleep... Here comes the corrected version. Also, I put it here, to top level, for "accessibility reasons".)
--------------------------------------------------------------
//////////////////////////////////////////////////// <some_final_comments note="Walter, please skip this...">
> > "Luna Kid" <lunakid@neuropolis.org> wrote in message news:b6aerf$158r$1@digitaldaemon.com...
> > > Mmm... Actuall, I start liking Sean's "with" idea more and more:
> > >
> > > > with(o) // skips the whole block if o is null
> > > > {
> > > > }
>
[...snip...]
>
> "Matthew Wilson" <dmd@synesis.com.au> wrote in message news:b6aqbd$1ds9$1@digitaldaemon.com...
> > I agree it seems kinda nice, but how to do complex conditional,
involving
> > perhaps a couple of objects, and maybe other conditions?
>
[...snip...]
>
"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:b6beok$1qun$1@digitaldaemon.com...
> This would only cover half of the issue. Assuming one wants distinct
> semantic actions to replace if (o != null) {} and if (o1 == o2), this
would
> only address the former.
Yes, as the core of the idea was separating general-purpose conditionals ("real if") from checking object availability.
</some_final_comments> ////////////////////////////////////////////////////
Actually (despite what I said in private to him earlier...),
Sean's with(x) would be _the_ solution:
- As to the syntax, both of the controversial, but frequently
used and practical C/C++ idioms
if (x)
and
if (x = new object)
would be replaced this way with something nice and clean.
- As to the semantics: the meaning of the construct would be:
"if x is initialized, do the following with it". What does
"initialized" mean?
For a start, "x != null" would be fine. (The current semantics
of references allows null values already, which does indicate
some sort of "uninitializedness" anyway.)
But if not (e.g. in classes where RAII is not strictly
followed, like
x = new File; x.open("realfile"); with (x)...
where x != null but invalid in any useful context), this
semantics can be easily extended later.
E.g., in the future, "with (x)" could implicitly call
some x.initialized() method, if the class of x defined it.
(Notice that this is actually the very common role of
operator bool() in C++, which facilitates -- and makes so
practical! -- the ugly if(x) conditionals there...)
(Just as a side-note: besides the != null choice, it might
be tempting to say, e.g. performance-wise, that having
class_invariant == true
would also be good, but since "with (x)" is a typical run-
time success/failure scenario, disabling contracts would
break the logic of the programs.)
- One "drawback" is the run-time overhead for != null checking.
But no program is meaningful, which operates on uninitialized
references anyway, so the code *must* contain the check, either
way... Then, the preferable choice would be if the compiler
kindly took this routine burden -- and throw some "object
uninitialized" exception, as appropriate.
- Note, that this same exception could be also thrown when
applying operations on x, when it is null (like x == ...
- see in the "null == o" thread, for example).
However, that would be probably be too much, contradicting
with D's nice performance commitments. But luckily, as a bonus,
this slightly extended with statement also offers a compromise
to this:
One (Walter) could agree that with(x) naturally ("explicitly")
implies object validity checking, but all others (like ==)
perform no check (but class invariant checking in debug mode),
as currently, so those operations should be e.g. enclosed into
a with(x) { ... } block.
And everyone could be quite happy then, I think...
Thanks,
Sab
| 
Permalink
Reply
