In article <cufvel$2aln$1@digitaldaemon.com>, Charlie Patterson says...
>
>So why is it OK to remove array-bounds checks at release but not functional return points?  They seem remarkably similar to me.  The assumption seems to be that if you didn't catch them in debug, you'll be alright.

One difference is that bounds checking costs cycles for every array lookup, but an assert(0) at the end of a function doesn't cost anything by just being there.

Nick

"Charlie Patterson" <charliep1@excite.com> wrote in message news:cufvel$2aln$1@digitaldaemon.com...
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cueank$jur$1@digitaldaemon.com...
>>> I see the problem as a matter of elegance and consistency.  And I think it is more elegant to provide the assert as a run-time check. Doesn't D also have array bounds checks?
>>
>> Not in release, AFAIK.
>>
>> <snip reason = "ran out of time; mentally foggy">
>
> When the fog lifts... (-:
>
> So why is it OK to remove array-bounds checks at release but not functional return points?  They seem remarkably similar to me.  The assumption seems to be that if you didn't catch them in debug, you'll be alright.
>
> And why should the user be forced to insert dummy return point (or assertions at return points), but not dummy array-bounds checks or assertions?

Assuming we're correct re checks in release, I agree it's inconsistent, as you point out

Matthew wrote:
> 
> He he. No, sorry. I've ordered a hinge from Dell - a company that seems to know how to provide at least acceptable, if not great, customer service - and it's about to become a Linux machine. (GDC, here I come!)
> 
> 
> 

Oh, ok. Can't say I didn't try... :D

_______________________
Carlos Santander Bernal

I'm proud to have fathered such a successful thread...

-- 
-PIB

--
"C++ also supports the notion of *friends*: cooperative classes that
are permitted to see each other's private parts." - Grady Booch

Paul Bonser wrote:
> 
> 
> I'm proud to have fathered such a successful thread...
> 

He he... well I don't think this is just /a/ thread... it's a multi-thread.  Hard to believe there can be so many topics on one.

:-)

- John R.

Thank-you. That actually does make sense. I can see now why it would be an interesting feature. I can only understand these things in terms of how they are implemented :-). So for AOP, what I see is being essentially a derived class, with the modified methods being created that are wrappers around the base class's methods. The aspect code is inserted into the wrappers.

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cub9la$mbe$1@digitaldaemon.com...
> [OT] btw, if Walter was to build regex into the language, like in Ruby, I'd go for that. :-)

Doing that, as I argued elsewhere, would break some of the core principles on which the D grammar is based. But something close to it can be achieved, see the new regexp and string functions in DMD 0.114.

On Wed, 2 Mar 2005 10:34:14 -0800, Walter <newshound@digitalmars.com> wrote:
> Thank-you. That actually does make sense. I can see now why it would be an
> interesting feature. I can only understand these things in terms of how they
> are implemented :-). So for AOP, what I see is being essentially a derived
> class, with the modified methods being created that are wrappers around the
> base class's methods. The aspect code is inserted into the wrappers.

Yes, that's essentially it.

Regan

In article <d051g0$fq8$1@digitaldaemon.com>, Walter says...
>
>Thank-you. That actually does make sense. I can see now why it would be an interesting feature. I can only understand these things in terms of how they are implemented :-). So for AOP, what I see is being essentially a derived class, with the modified methods being created that are wrappers around the base class's methods. The aspect code is inserted into the wrappers.
>
>

Yes and no. As I understand it, the real power of AOP lies in its ability to cut across multiple, perhaps unrelated, classes. Without a common base-class, and no multiple inheritance. It's not really class-oriented, since the methods involved are often identifed using a limited regex form (select all 'put' methods across all classes, for example).

As suggested, the additional code is wrapped around the methods.

On Wed, 2 Mar 2005 23:39:21 +0000 (UTC), pandemic <pandemic_member@pathlink.com> wrote:
> In article <d051g0$fq8$1@digitaldaemon.com>, Walter says...
>>
>> Thank-you. That actually does make sense. I can see now why it would be an
>> interesting feature. I can only understand these things in terms of how they
>> are implemented :-). So for AOP, what I see is being essentially a derived
>> class, with the modified methods being created that are wrappers around the
>> base class's methods. The aspect code is inserted into the wrappers.
>>
>>
>
> Yes and no. As I understand it, the real power of AOP lies in its ability to cut
> across multiple, perhaps unrelated, classes. Without a common base-class, and no
> multiple inheritance. It's not really class-oriented, since the methods involved
> are often identifed using a limited regex form (select all 'put' methods across
> all classes, for example).

Well, true, technically.
The way I see it, you're simply stating.

Take class A. add concern C1,C2 to method x,y, and z. call it C12_A.
Take class B. add concern C1,C3 to method x, and y. call it C13_B.

It is similar to inheritance, as in, you could do it manually...

class A {
  void foo() {}
}

class C12_A : A {    <- take class A, call it C12_A
  void foo() {
    ..concern..      <- add concern to method foo
    super.foo();
    ..~concern..
  }
}

but the idea is that it's done automatically, via some description/format and can be done to any base class, not just A, that you can add several different concerns to a class, that you can pick methods for each concern and they may differ to picks for another concern.

Or am I missing your point? I must admit my understanding of it comes from a couple of articles I've read and not much else.

Regan