On Sun, 6 Feb 2005 19:42:14 -0800, Walter <newshound@digitalmars.com> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opslsuv5qc23k2f5@ally...
>> AOP is cool, I wish it was possible to use it in D.
>
> I looked at Kris' reference, but AOP is one of those things I don't
> understand at all.

I looked too, I found it less easy to follow than the article on Aspect-Oriented Programming that Christopher Diggins wrote in the August 2004 edition of Dr Dobbs Journal.

A simple example of AOP is... you have a class Bob, you want to log calls to all it's functions, dumping state etc. You write the code to do the logging and 'hook' it up to certain methods in Bob, but, the important part is that it does not require changes to Bob, and the new code can be 'hook'ed up to another class in the same way.

3 things are involved, the original class, the new code, and a 'pointcut' which defines the methods the new code effects i.e. how to 'hook' it up.

C/C++ achieves it using the preprocessor. I am not sure how Java does it. If you/we think about it a bit I'm sure we can come up with a syntax for D. Mixins are almost it, though what you need is a way of defining where the mixins go without actually modifying the original class.

See also:
  http://www.aspectc.org/

Regan

Regan Heath wrote:
> AOP is cool, I wish it was possible to use it in D.

I've written a simple aspect preprocessor for D, but it hasn't received too much attention in the ng. If still anyone wants to take a look, it's here: http://codeinsane.info/download/adp.zip

I agree this behavior is not nice at all, unless you've never seen programs like "Windows" and believe that code can be totally bug free when compiled in release mode.

I might suggest making it an error, when in release mode, but obviously that has flaws: not only *could* someone be MORE keen to shut the compiler up when switching to release, but it would be very annoying if it was working along and suddenly wouldn't compile using --release :/. So, I suppose that won't work.

Personally, I think the asserts should go away and instead we should get your all-knowing exceptions thrown, whether in debug or release, with line and file information (assuming the case where no compile-time error/warning is shown.)  Alas, I dream.

-[Unknown]


> Wake me up when things get sane again.

I think Walter's stand on 'missing return' is an opposite extreme of java checked exceptions enforcement.

I mean, Java enforces checked exceptions, many people didn't like it, Walter didn't like it, he hated it, and believed that compiler should never enforce few things, including 'missing returns'.

But not checking for missing return statements just too extreme.
People hated Java compiler for its over involvement,
and now, they might hate D for its under involvement !!

Just my opinion
Sai

On Mon, 7 Feb 2005 04:10:40 +0000 (UTC), Ben Hinkle wrote:

> A statement about inserting code could be made in verbose mode (-v) since that is a flag to the compiler to get all the details about what it is doing. Non-verbose mode should be... non-verbose.

Now that's a decent idea.

-- 
Derek
Melbourne, Australia
7/02/2005 5:48:22 PM

Matthew wrote:

> I think it's getting clear that we're going to need fine grained control of what stays in a final production build, and what does not.
> 
> I also think that we should probably either:
>     1 make "-release" mean "*all* CP stuff stays in", or
>     2 make "*all* CP is elided".
> 
> Any halfway house is just likely to lead to confusion.
> 
> Since I, personally, think that 2 is a bad thing, but I strongly suspect there'll be objections to 1, for obverse reasons.

After doing some more reading on the subject, I've come to agree with
the default setting of DMD, which is to strip all contracts on -release.

But there could still be optional individual flags to toggle each of:
*) contracts (all four of them) *) array bounds *) switch default

There are already such flags in the code, just not on the command line.

>     if (global.params.release)
>     {	global.params.useInvariants = 0;
> 	global.params.useIn = 0;
> 	global.params.useOut = 0;
> 	global.params.useAssert = 0;
> 	global.params.useArrayBounds = 0;
> 	global.params.useSwitchError = 0;
>     }

Just didn't make it all the way clear to the documentation, I suppose ?

> Maybe the answer might be to drop "-release" entirely. Can someone with a more detailed understanding than me describe what this might entail, i.e. what the diff between "-debug" and "" might be?

"debug" is just a version, i.e. it triggers the debug { ... } sections.
It doesn't have *anything* to do with the "-release" flag whatsoever...

Where as leaving out "-release" leaves the default values for the above:

>     global.params.useAssert = 1;
>     global.params.useInvariants = 1;
>     global.params.useIn = 1;
>     global.params.useOut = 1;
>     global.params.useArrayBounds = 1;
>     global.params.useSwitchError = 1;


I found some more interesting opinions on:
http://c2.com/cgi/wiki?WhatAreAssertions

> Since assertions that don't fail are no-ops, once a program has  been
> thoroughly tested and bug-fixed, it is possible to recompile the source  code
> without the assertions to produce a program that is both smaller and faster

> Once upon a time assertions were not executable: See AssertionsAsComments.

--anders

Sorry if I didn't say so before Matthew, but I agree wholeheartedly. Which switches to use I don't really care about, though I agree that -'release' is somewhat badly named as it means different things to different people, dependent on experience, company practices and more.

Lars Ivar Igesund

Matthew wrote:
> "sai" <sai_member@pathlink.com> wrote in message news:cu65me$27i4$1@digitaldaemon.com...
> 
>>Anders_F_Bj=F6rklund?= says...
>>
>>>Okay, so -release is "intuitive" and "self-explanatory" - but you'll
>>>have to read the docs to find out what it does ? Does not compute :-)
>>>I find "-debug -release" to be a rather weird combination of DFLAGS ?
>>
>>Yes, -release means ..... it is a release version with all contracts (including
>>pre-conditions, invariants, post-conditions and assertions) etc etc turned off,
>>quite self explainatory to me !!
> 
> 
> I think the original issue under debate, sadly largely ignored since, is whether contracts (empty clauses elided, of course), should be included in a 'default' release build. I'm inexorably moving over to the opinion that they should, and I was hoping for opinions from people, considering the long-term desire to turn D into a major player in systems engineering
> 
> 
> 

In article <cu6k7l$2dk$1@digitaldaemon.com>, Matthew says...
>
<snip>
>
>As such, there's a strong argument that contracts should stay in. IMO, the only reasonable refutations of that argument are on performance grounds.
>

<rant>

I agree. I mean let's face it, we've probably all shipped production code with what amounts to non-language formalized PwC in it, hence my earlier suggestion to divorce PwC from any switches, or at least any of the default "meta" switches.

In the current ref. compiler implementation of PwC, the only perf. side effect that I can see is that calls are made to check for invariants even when there are none defined for a class. That is extremely expensive because it is done for every call to every method. If the compiler front-end can optimize those away than we only pay for what we use.

I'm afraid that as-is, I'd end up falling back to some non-formalized form of PwC (and not even use it as D intends) because as you pointed out, Matthew, non-trivial & complicated code is hard to ever completely debug.

As an example, consider an ad-hoc reporting UI where the user can select all sorts of different interdependent parameters that may have side-effects on any number of other parameters. Typically most of these different combinations will never be tested before release. The UI param class doesn't need high-performance, but the report data-gen class does.

What to do? You can either write gobs of code spread out all over the place to try and validate the input params. or you can place it all in an invariant block and live with the shitty performance of the data-gen class that doesn't even use invariant (or end up segregating the code - and compiler switches in the build script - even though it may not otherwise make sense to do so, only because of the performance side effects of invariants on classes that don't use them).

The compiler already has to walk the class geneology tree for things like making sure that super ctors are implemented with correct arguments, to enforce protection attributes, etc., etc. I suspect it can't add much complexity to add a cd->hasInvariant || cd->baseClass->hasInvaiant flag or whatever to make the decision on whether or not to emit the invariant call for a class.

Formalized PwC is a great feature of D and I just want to see it used. After all, (hopefully) our D applications will go through many more CPU cycles in production than in test.

</rant>

- Dave

Dave wrote:

> I agree. I mean let's face it, we've probably all shipped production code with
> what amounts to non-language formalized PwC in it, hence my earlier suggestion
> to divorce PwC from any switches, or at least any of the default "meta"
> switches.

Maybe I missed something, but what's the difference between
Programming with Contracts (PwC) and Design by Contract (DbC) ?

--anders

In article <cu87kd$2soo$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>Dave wrote:
>
>> I agree. I mean let's face it, we've probably all shipped production code with what amounts to non-language formalized PwC in it, hence my earlier suggestion to divorce PwC from any switches, or at least any of the default "meta" switches.
>
>Maybe I missed something, but what's the difference between
>Programming with Contracts (PwC) and Design by Contract (DbC) ?
>
>--anders

I'm not sure what the consensus would be on that but PwC expresses the implementation side of the DbC idea better in my mind, and it seems that the terms are used interchangeably anyhow. Whether or not the originators of the two terms intended that I don't know.

If the consensus here is that DbC is the better blanket term, I'll be more than happy to use that.

- Dave