Aspect-Oriented Programming Considered Harmful

kupci writes "The 'x considered harmful' cry is a little overused, but there is a Forrester report that discusses some of the pro's and con's of Aspect-oriented Programming, and includes some interesting links. It is mainly based on papers from the University of Passau. It's worth it just for Clark's 'COME FROM' article." From the article: "Aspect-oriented programming (AOP) is intended to address common problems that object-oriented programming (OOP) doesn't address well, plus some problems that OOP itself created. However, AOP is a risky solution: It is a very generic mechanism for solving some very specific concerns and has been likened to a kind of "GOTO" statement for OOP. Like GOTO, it can cause more harm than good."

Comments

Of course

[ravenspear]

The only thing worse would be GOTO + OOP, which of course = C++

Re:Of course

[Anonymous Coward]

In C++ you can get around ever using "goto" by creating inline functions and using return statements.

AOP can, presumably, be used to good effect in the right situations. "Goto", on the other hand, is an abomination.

Re:Of course

[Dwonis]

"Goto", on the other hand, is an abomination.

Quick! Somebody start a petition to demand that Intel drop the JMP instruction from its processors! It's an abomination!

Re:Of course

[Dachannien]

Last I checked, assembler wasn't a high-level language.

Re:Of course

[toriver]

And C is assembly language in fancy dress. C++ adds garish accessories to the dress-up.

Re:Of course

[Anonymous Coward]

Last I checked, assembler wasn't a high-level language.

And? High level languages have immediate targetted transfer of control instructions as well that one cannot easily get rid of. For example, C has break, continue, and the closing squiggles of for and while statements.

"High" level languages makes programmers not as aware as they should be when they're moving a different value into the instruction pointer, but their programs are still doing precisely that at various points.

One could argue that C and other compiled languages are low level, like machine code and assembler, and that interpreted things such as Java, C#, and BASIC are high level, but it wouldn't have much bearing on the difficulty of living without unconditional transfer.

Re:Of course

[drsquare]

Well, assembly is hardly a language that encourages large, well-organised programming projects, so you've pretty much supported his point.

Re:Of course

[heffrey]

Shouldn't this read GOTO + OOP == C++ ?

-------------

I attempted to post just the text above the dashes and was rewarded with:

"Lameness filter encountered. Post aborted!
Reason: Don't use so many caps. It's like YELLING."

Can I report the lameness filter for lameness?

Re:Of course

[frakir]

Funny thing is that GOTO is considered harmful and BREAK (labelless GOTO) is supposed to be allright. One can read long code with nested loops much easier when there are labels.

I think more harm is done by avoiding GOTOs at all cost and abusing BREAK statement.
Especially when you have to mantain someone elses spaghetti.

Re:Of course

[lightsaber1]

Agreed. The first thing they teach you as a computer scientist is that GOTO is BAD. Then, when you get much further along in your education, they'll teach you the proper way to use a GOTO that both avoids the danger of infinite looping, and actually makes your code more readable and more efficient in certain situations. The uses are still rare, but sometimes the cost of avoiding GOTO is too great.

Say what you will about GOTO being an abomination, but even Leto Atreides, the biggest abomination of all, saved the universe.

Re:Of course

[signifying nothing]

Computer scientist? I think you mean software engineer.

Re:Of course

[iamacat]

I swear C.Sci professors ban using goto for much the same reasons religions control sex - to bully students into total obedience by giving them difficult, meaningless restrictions. In this case, transforming code that is naturally expressed with goto by adding boolean flags, switch statements and so on. Unnecessary inline functions is a new one for me though :-)

In fact, C if statements nested more than 3 levels are damn hard to read, especially once "}" is not on the same page as "{". It's a very common mistake to put some code after the wrong brace. In this case, outer levels of if/else should be replaced with if (...) goto for readability.

Re:Of course

[Anonymous Coward]

If your closing brace is not on the same page as the opening brace, it is advisable to split your procedure into several smaller ones. Without goto.

Re:Of course

[mysticgoat]

<div style="pedantic" >
The difference between Computer Science and Software Engineering is that in CS theory there is no difference, but in SE practice there is. :-)
</div>

I can't see how GOTO has any value in CS. Theory shouldn't ever take shortcuts and in theory if you need faster performance, then you should choose an algorithm that is more efficient in the particular context.

That said, GOTO does sometimes add a great deal of value in practical coding. Sometimes real world dependencies between operations are such that there is no way work out a clean factoring into separate functions in the time available for the project, with the domain knowledge you've currently got. So you've got to contend with a monster function full of complex else-if chains and switch statements to handle all the special cases. IF after you've developed this puppy in proper accordance to theory, EITHER it is a performance bottleneck OR it is going to cause obvious maintenance problems down the line, THEN there is justification for replacing some CS-compliant structures with GOTOs.

But note that when this is done the GOTOs are never built in to the original design; they are used to simplify a design that is theoretically sound, but isn't efficient enough in some way. It is like a high energy particle physicist introducing the fiction of "centrifugal force" to describe events in a car crash-- everyone knows it is not good theory but it is the quickest and surest way to convey information in this particular context.

Re:Of course

[iamacat]

Procedures are for doing reusable or at least logically separate things, not for pure code formatting. You don't want proc that calls proc1 and proc2 (because there are no meaningful names for what they are doing) with 10 arguments each. Boilerplate code like string manipulation can be naturally factored out to procedures, classes etc. Functionality unique to your application often can not be and, as long as it's not reusable, there is no reason to waste time thinking about it. Rather, write comments, use gotos instead of deeply nested ifs and be happy.

Re:Of course

[TheGavster]

If you move the code into a function and inline it, you're going to get the same result: you're unconditionally going from one part of the code to another. How is 'needlessinlineproc()' different from 'goto someproc'? I still have to figure out where the hell you put the next bit of code.

Re:Of course

[Anonymous Coward]

TESTING PARAMETer's of lameness filter.

Re:Of course

[Anonymous Coward]

ABCDEFGHIJKLMNOPQRSTUVWXYZ

Re:Of course

[Anonymous Coward]

Goto's are evil, because they hide the structure of the code. Your Comp.Sci professors were right.

Re:Of course

[jelle]

Because goto's are like roaches. You see one, there are bound to be many others. You kill one, and hundreds come to bury it.

'goto code' tends to turn in to the same well-organized structure as a plate of spaghetti.

And besides that, your code documentation becomes much harder to make/read, your tools (profiling, tracing, formal verification, etc) become much less effective, etc.

If you've maintained code that had gotos and was made by others, you probably know what I'm talking about.

There are some, but very rare occasions where using a goto is the best way to code something. Use them extremely sparingly.

Re:Of course

[TheGavster]

I understand that gotos result in difficult to read code. What I am says is that inlined functions called in only one place result in very similar code, where you unconditionally jump somewhere else, so it is still difficult to navigate the spagetti.

Re:Of course

[Anonymous Coward]

I swear C.Sci professors ban using goto for much the same reasons religions control sex

I'd say it's more like the same reasons religions ban murder.

It's not that it's *always* bad - self defense, to protect your family, if you're alone in a room with Hitler, etc. It's just that for most people, there is a temptations to use murder to solve problems that are best solved by other, less messy ways. If you *need* murder, you'll know it. If you have any doubt, you're best not to do it in the first place.

Re:Of course

[mooingyak]

It's not just professors. It's experienced programmers too. Whenever we interview a candidate, they have to code a relatively simple 'C' program -- read a pipe-delimited file and produce pretty output. Once they've finished their code, it gets passed to me for review. We had a recent candidate who started off like this:

void main(ARGV, ARGC)

as his opening line. Despite the obvious problems already, I wasn't that concerned about it. I am usually much more interested in how they solve the problem than anything else, so syntactic goofs are no big deal. As I scanned along I found this line:

start:

and I said to myself, "That had better not be a label for a goto". I turned two pages and sure enough found:

goto start;

At which point I handed it back to our interviewer and just showed him what I had hit with the highlighter. He was not offered a position.

If you can't match braces, don't write code. It's not difficult, and adding gotos does NOT add readability.

Re:Of course

[jelle]

There are a million ways to make spaghetti, however a function hall has the advantage of giving the function a name (which should be descriptive), and the advantage of limiting the scope of operation to the arguments that are passed to it, plus the member vaiabled (if not declared const).

A simple run of a little tool like 'calltree' will show the relationships between functions, while gotos get no help from that camp.

When well done, using functions, even when called only once, is a good idea. Using gotos, imho, cannot be done well.

Re:Of course

[ultranova]

If you can't match braces, don't write code. It's not difficult, and adding gotos does NOT add readability.

If you can't read gotos, let someone else do the code reviews. Not everyone needs braces, in Real Life or in programming; if you do, use them, but don't give grief to those who don't, for jealousy is petty.

Re:Of course

[TheGavster]

I suppose that clearing up the scope within which the lines exist is an improvement to readability, however even gotos get a (potentially) descriptive label.

Re:Of course

[cakoose]

I can't see how GOTO has any value in CS. Theory shouldn't ever take shortcuts and in theory if you need faster performance, then you should choose an algorithm that is more efficient in the particular context.

EITHER it is a performance bottleneck OR it is going to cause obvious maintenance problems down the line, THEN there is justification for replacing some CS-compliant structures with GOTOs.

Saying that GOTOs have no place in theory implies that "CS-compliant structures" let you express any algorithm efficiently and clearly at the high-level. But if you're forced to use GOTOs to improve maintainability, then there's a hole in your theory. GOTOs, being generic and powerful (and, as a result, dangerous) act like the catch-all to make your theory complete.

Re:Of course

[Anonymous Coward]

Procedures are for doing reusable or at least logically separate things, not for pure code formatting.

Different branches of an if statement are, by definition, logically separate.

You don't want proc that calls proc1 and proc2 (because there are no meaningful names for what they are doing) with 10 arguments each.

Splitting code into procedures provides an opportunity to invent meaningful names and write documentation. More often that not, both can be constructed for otherwise nameless code blocks and improve their readability.

Functionality unique to your application often can not be and, as long as it's not reusable, there is no reason to waste time thinking about it.

Apart from the readability argument, there is another benefit from extracting a chunk of code into a procedure: It is natural to attach specifications to procedures, much less common to do it for code blocks. Provided that the specification is easier to understand than its implementation (often, but not always the case), your code becomes easier to comprehend:

1. The newly introduced procedure can be read, analysed and tested without its original invocation context.
2. The invocation context can be reasoned about without the need to understand the procedure's implementation (the specification alone will do).

You can also check the specification by including runtime assertions. Entry and exit points of procedures are a perfect location for such checks.

Your statement that procedures are for avoiding code duplication is correct. However, there also have other legitimate purposes, which I hope you will recognize when assigned the task of understanding and testing other people's code.

Concerning your remark about passing a big number of parameters, you should use the opportunity to encapsulate sets of semantically related parameters into a named data structure or class (if using an OO language).

Are you familiar with the "Design By Contract" concept? If not, I can heartily recommend reading up about it.

Re:Of course

[mooingyak]

It's not jealousy. I can and I have traced through code laced with gotos. I've written it when forced (DOS batch scripts).

I can and will give grief to those who use them in C or any other structured language where the legit uses are few and far between.

Incidentally, what is this:
Not everyone needs braces, in Real Life or in programming

supposed to mean? Reference to orthodontists?

Re:Of course

[Dachannien]

For example, C has break, continue, and the closing squiggles of for and while statements.

But all of those statements are used in the context of some logical block, and in some sense "operate" on that block. GOTO is/does not - in C/C++, at least, the only restriction is that you must GOTO a label that's in scope at the time.

"High" level languages makes programmers not as aware as they should be when they're moving a different value into the instruction pointer,

High level languages also relieve the programmer of the need of thinking about things like stack frames, heap management, and register usage. A programmer should in a general sense understand how these things work, but there doesn't need to be a constant awareness of those factors, because the compiler is designed to take care of them instead. Programmers working on hardcore optimization might have an interest in those low-level details, but a good optimizing compiler will take care of most of that before the programmer even starts to think about optimization.

The point in my original comment was that, in assembler, not using JMP reminds one of, "You can't get very far in life without saying 'is'". But the last time I've needed a GOTO was when I was a teenager naively programming in BASIC on my old C-64.

Re:Of course

[Anonymous Brave Guy]

Different branches of an if statement are, by definition, logically separate.

You'd better hope not. If you're branching down two paths that have no logical connection, you almost certainly have a design error!

The key thing when factoring out code into procedures is whether you can isolate a complete and self-contained idea, so that it makes sense without context. If you happen to be implementing a complex algorithm with lots of nested conditionals, but none of the branches makes sense without the context of the other conditions, then you absolutely shouldn't factor out all the branches; that just creates a maze of functions where you have to keep jumping from randomly-isolated function to meaningless function just to see what the algorithm is doing.

This is something I encounter several times a week, though I realise that I'm working with more complex algorithms than many at present. I'm frequently told that I (and presumably therefore everyone else in my department too) "just don't understand" what functional decomposition is about, or words to that effect. I've been told this by at least one person on the ISO C++ standards committee, for a start.

However, given the collective experience with programming in general and complex algorithms in particular embodied in the department, and the fact that everyone there writes these complex algorithms as single functions even if they involve 100+ lines, such a claim tells me more about how qualified the speaker was to express any opinion at all than anything else. Often, you later find that they think quicksort is a complicated algorithm, and can't think of any uses for more powerful flow control constructs in languages.

Splitting code into procedures provides an opportunity to invent meaningful names and write documentation.

Ah, but the clue is in the question: if you can't think of a meaningful name for a block in isolation, then perhaps that block shouldn't be read in isolation in the first place.

Re:Of course

[bit01]

I find that whenever I want to use GOTO what I really want to use is a finite state machine (FSM).

Whenever control structure gets so complex that GOTO's seem appropriate a FSM can be a good way to systematise that complexity. With the added advantage that you can often make the FSM a largely static, declarative data structure, not imperative code.

I find my code is a lot clearer as a result, with the bonus of better understanding of the problem domain and complete handling of the corner cases.

---

Large public or private organisations paying recurring, per-seat licensing for software are being economically stupid.

Re:Of course

[Anonymous Coward]

The biggest difference is that a function call necessarily returns to the point immediately after the function call. A goto doesn't have to come back, and that makes reasoning about the code more difficult.

Re:Of course

[Pseudonym]

"Goto", on the other hand, is an abomination.

You've never had to implement a lexical analyser by hand, I take it. In a language without guaranteed tail recursion optimisation, the easiest way to implement finite state machines is with gotos.

"Goto" is a greater sin in C++ than in most languages because if used without considerable care, it can screw up the block structure, giving the compiler a difficult time in determining when to call a destructor. But if used with care, it is a tool in the programmer's toolbox. It just happens to be a tool that doesn't comply with modern safety regulations, so should be used when all other options would be significantly worse.

Re:Of course

[JollyFinn]

I must tell that after I've learned something about the C compilation today.
I doubt that C compiler can optimize enough, you have to. Either write in assembler or know what the compiler will output in different situations and code accordingly. There is one order of magnitude performance difference between optimized assembler and c-code that doesn't take account on what is assembler output of the code with same basic algorithm, depending on situations as C code can be efficient too. And no, the compiler cannot help as it lacks the information that could varrant those optimizations.

Re:Of course

[Anonymous Coward]

Unnecessary commas are evil, too.

Re:Of course

[Anonymous Coward]

if you can't think of a meaningful name for a block in isolation, then perhaps that block shouldn't be read in isolation in the first place.

On the other hand, if you do not attempt to isolate the block, you will never discover that it would make sense in isolation. You will also have a much harder time determining its similarity to another block embedded into a long procedure elsewhere.

My original point was that extracting code into procedures should be a heuristic rule, a second-nature of a good programmer, and that branches are an excellent starting point. Polymorphism was introduced in OO languages based on similar premises.

Re:Of course

[Anonymous Brave Guy]

My original point was that extracting code into procedures should be a heuristic rule, a second-nature of a good programmer, and that branches are an excellent starting point. Polymorphism was introduced in OO languages based on similar premises.

Indeed, and now inheritance and polymorphism are probably the most over-used programming language features on the planet.

I'm not saying you're wrong to try to isolate self-contained and independent blocks of code -- you're not -- I'm just saying that it's not always possible, even when you look at "obvious" dividers like branches or loop bodies.

Re:Of course

[Anonymous Coward]

A programmer should in a general sense understand how these things work, but there doesn't need to be a constant awareness of those factors, because the compiler is designed to take care of them instead.

I respectfully disagree with you. A programmer must have a clear understanding of how parameters and return addresses are pushed onto the stack to make a C function call happen. They must be able to explain what the machine code that the compiler is generating for a snippet of C probably looks like. If they don't understand that much about the software they'll be writing, they'll eventually find themselves in over their heads. I expect that level of understanding of any good programmer, and while it's true that it's important for to-the-metal optimization, it's even more important when it comes to debugging tough problems in complex systems. If they don't know it, they won't be able to do it, because the compiler sure isn't going to do it for them.

This kind of thing is true in other areas. Take web design, for example. One might argue that with WYSIWYG tools that allow a web designer to position elements in a window, press a button, and have the HTML generated for them, that only a general sense of what's going on is necessary because Frontpage is designed to take care of all the messy details. I do not agree with that. When a web page displays in IE, but not quite correctly in Firefox, the skilled web designer will be able to look at the HTML source, understand what it's doing, and make changes to troubleshoot and fix the problem. The mediocre web designer will spend their time fiddling with the stuff in the window trying to make it work.

I expect good programmers, web designers, doctors, lawyers, and mechanics to know what's going on under the hood, and to know it cold.

The point in my original comment was that, in assembler, not using JMP reminds one of, "You can't get very far in life without saying 'is'". But the last time I've needed a GOTO was when I was a teenager naively programming in BASIC on my old C-64.

Point taken. I haven't needed a GOTO since writing an inventory system on a Kaypro 10 (although I did need a JMP just last week, albeit on a Microchip PIC), but I contend that you can't get very far in serious software development by relying on tools more than on your own knowledge of how they work and what they're doing.

Good primer on aspect-oriented programming?

[John_Booty]

Google, of course, returns a ton of results for aspect-oriented programming. Does anybody have one in particular that they recommend?

I'm a fairly experienced coder, but I don't have any experience with AOP whatever. I don't even know what it is!

Re:Good primer on aspect-oriented programming?

[Alien Being]

goatse.cx

Re:Good primer on aspect-oriented programming?

[Anonymous Coward]

One can only feel sorry for this poor soul. An experienced coder who never heard of wikipedia. http://en.wikipedia.org/wiki/Aspect-oriented_progr amming

Re:Good primer on aspect-oriented programming?

[Anonymous Coward]

I find this particularly simple to understand.
http://weblogs.asp.net/Mnolton/archiv e/2004/04/23/ 119181.aspx

Re:Good primer on aspect-oriented programming?

[Anonymous Coward]

Link should be:
http://weblogs.asp.net/Mnolton/archive/2004/0 4/23/ 119181.aspx

Re:Good primer on aspect-oriented programming?

[Anonymous Coward]

Use HTML, dumbass.

Re:Good primer on aspect-oriented programming?

[devillion]

Links

• "Aspect-Oriented Programming with C++ and AspectC++"
• http://www.aosd.net/
• http://www.aspectc.org/

Re:Good primer on aspect-oriented programming?

[Alsee]

tubgirl

-

Re:Good primer on aspect-oriented programming?

[Anonymous Coward]

I'm so confused...

Re:Good primer on aspect-oriented programming?

[Anonymous Coward]

So you could take the time to post "use HTML, dumbass." but couldn't be bothered to post the link yourself?

Dumbass.

http://weblogs.asp.net/Mnolton/archive/2004/04/23/ 119181.aspx

Re:Good primer on aspect-oriented programming?

[simonsayz]

John Wiley and Sons Mastering AspectJ Aspect-Oriented Programming in Java is a pretty good book on it. It's ofcourse based on aspectj but when you know the principles behind the one it's easy to understand the rest.

Re:Good primer on aspect-oriented programming?

[kfg]

I don't even know what it is!

That's ok, neither does its "inventor." That's part of the problem with it.

KFG

Re:Good primer on aspect-oriented programming?

[NFLFan]

Surprised no one has suggested AspectJ yet. You can find it a http://eclipse.org/aspectj/.

Re:Good primer on aspect-oriented programming?

[canuck57]

I'm a fairly experienced coder, but I don't have any experience with AOP whatever. I don't even know what it is!

I don't think you or I have to worry. It is likely a construct you already use.

What I would really like to know is "depricated" versus "depreciated". I can only guess, but could the API developer that did this not spell? Knowing AOP is about as much value, esoteric at best.

Re:Good primer on aspect-oriented programming?

[chrome]

I've had to type this comment blind as I have put out both my eyes.

This was a bad move because now the thing that I remember last seeing was that site.

Ow, my brain.

Re:Good primer on aspect-oriented programming?

[afd8856]

Are they selling /. ids now on ebay? The lack of knowledge you seem have about links on this website seem to give credit to that thought.

Re:Good primer on aspect-oriented programming?

[Anonymous Coward]

Is that where you got yours? Look at his account number you idiot.

Re:Good primer on aspect-oriented programming?

[chrome]

Hahahaha.

Yes, I bought it on ebay for $50,000! I'm actually a 16 yo from Maine.

Oh, and I play EQ2 and I make $5,000 a day from illegally selling level 50 characters and items and plat. ...

That what you wanted to hear?

Jesus, it was a joke. Of course I've seen tubgirl before. On slashdot. I have no idea why I posted my original post - I think it was because I was fucking BORED.

Re:Good primer on aspect-oriented programming?

[-_broken_watchman_-]

Some people "forget" to tell us this... Can you write aspect-oriented programming? Beware of Aspect-Oriented programming. It is patented . See US patents 6,467,086 and 6,442,750 : http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PT O1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm &r=1&f=G&l=50&s1=6,467,086.WKU.&OS=PN/6,467,086&RS =PN/6,467,086 http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PT O1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm &r=1&f=G&l=50&s1=6,442,750.WKU.&OS=PN/6,442,750&RS =PN/6,442,750

Re:Good primer on aspect-oriented programming?

[AEton]

The reason people think you're an idiot is that the posted links actually neither pointed to goatse nor tubgirl.

HTH HAND.

Re:Good primer on aspect-oriented programming?

[chrome]

haha, thats pretty funny.

Well, as I said, I was bored.

I may even have been drunk.

Re:AOP?!

[CrankyFool]

You're on crack. AOP is not specific to Java -- I've seen it done with Python -- see this article for example. AOP can be used for great evil, but it can also be used for great good. When I first read up on it, my first reaction was "wow! This must be how God programs!" :)

For those unfamiliar with AOP

[ravenspear]

Wikipedia linkage

In computing, the programming paradigm of aspect-oriented programming (AOP) centers on constructs called aspects, which treat concerns of objects, classes, or methods. The aim of AOP is to separate program code related to the main purposes of the application (its core concerns) from code related to secondary purposes (cross-cutting concerns).

For example, a telecommunications application might have a core concern of routing calls, while code for timing and billing those calls would crosscut the whole object hierarchy. AOP aims to separate the billing concerns from the core concern. It moves code not related to solving the domain problem from the business logic into a separate module. The application code no longer contains pieces of crosscutting concerns scattered across modules; instead, programmers maintain crosscutting concerns in aspects; this makes it easier to maintain both core and crosscutting concerns.

Any program has principled points (join points) where programmers can identify and modify the program semantics. In AOP, programmers specify join points using a language feature called a pointcut, and specify the behavior to join those points by using advice such as methods or functions. Some variants of AOP allow programmers to extend the types in the system. These features enable aspects to implement behavior for concerns that crosscut the core concern of the application.

Re:For those unfamiliar with AOP

[Anonymous Coward]

I find the example rather silly. For anyone doing telecommunications, the business of billing calls is mission-critical, and therefore should be designed into the core application.

They seem to portray AOP as trick for lazy small-picture designers who want to ignore the boring problems, because someone else can hack it into the system using AOP.

Re:For those unfamiliar with AOP

[starling]

Any program has principled points (join points) where programmers can identify and modify the program semantics. In AOP, programmers specify join points using a language feature called a pointcut, and specify the behavior to join those points by using advice such as methods or functions. Some variants of AOP allow programmers to extend the types in the system. These features enable aspects to implement behavior for concerns that crosscut the core concern of the application.

Excuse me, but was that supposed to mean something?

Re:For those unfamiliar with AOP

[Keeper]

It's an example, geeze. It is obviously going to be contrived and simple so that someone unfamiliar with the concepts being demonstrated will be able to understand it.

Re:For those unfamiliar with AOP

[Keeper]

Let's say you've got objects a, b, and c.

Objects a and b do something useful (the core of the application)

Object c (an aspect) wants to perform an operation when something happens in object a (a concern).

Object c (an asepct) also wants to do different things when something happens in object a and b (crosscutting a concern).

I look at this as a really complicated event notification system. Comments calling this 'goto for OOP' also seems rather appropriate.

Re:For those unfamiliar with AOP

[digitalchinky]

CCITT Number 7.
Signalling System 7.
SS7.

This beast takes care of the mission critical billing, timing, routing, SMS and a thousand other things, all in a single little packet switched channel. It's a small box with nice flashing LED's.

It is perhaps as common in telecommunications now as McDonalds is a household name.

Re:For those unfamiliar with AOP

[Anonymous Coward]

Yes. Get on with the times, dinosaur. Learning never ends.

Re:For those unfamiliar with AOP

[Black.Shuck]

So, AOP is just disciplined OOP?

Re:For those unfamiliar with AOP

[davesag]

think xdoclet. or JDO byte code enhancements, or logging. the java logging api lets you log.entering("classname", "methodname", new Object[] { param} ); and similarly for exiting. but that's a terrible bore to have to go in and add by hand, and also a terrible waste of code-realestate. i just want the logging to be there implicityly. with AOP you could define the entry and exit logging as aspects of each method both in your code, and in any code libraries you are using.

Re:For those unfamiliar with AOP

[TummyX]

I look at this as a really complicated event notification system


Conmplicated compared to writing the event plumbing yourself or compilcated compared to writing the same portiong code over and over and over again in different places?

Re:For those unfamiliar with AOP

[Oligonicella]

Then it failed. It sounded like ultra-vague language to describe something everyone's been doing for decades. Just what about the billing is being moved out? Who the hell writes code to update a billing system when they're routing anyway? the point of structure is to segregate those activities anyway. The example is a non-example. More details would help.

Re:For those unfamiliar with AOP

[Anonymous Coward]

Looks to me like a callback through indirect function invocation. That is, it's a table of function pointers.

Re:For those unfamiliar with AOP

[Anonymous Coward]

Sounds like someone needs a privately-inherited mixin.

Re:For those unfamiliar with AOP

[AmberBlackCat]

Did the XML guys have something to do with this?

Re:For those unfamiliar with AOP

[jp10558]

Now, I'm not a heavy programmer. I've only had 3 or so straight up programming classes in college, so I likely don't get it.

If you want something to happen when a certain thing occurs, wouldn't you just call a function or a method when that whatever occurs? Why would you want a goto style statement there?

Re:For those unfamiliar with AOP

[starling]

Thanks for the clear explanation. I was really just tweaking the OP's tail for excessive use of jargon, but you've confirmed what I suspected, which is that this is an overly complex solution to a problem which is better solved with lightweight processes and inter-process communication.

Re:For those unfamiliar with AOP

[Anonymous Coward]

A (trivial) example of AOP is execution logging. Everyone here who has ever programmed knows that if you include logging in the core objects, it can make your code much longer, and much more difficult to maintain.

With AOP, you can have a logging Aspect instead of peppering all your classes with logging statements. To use the terminology of the above poster's question:

Say you want to log the beginning and end of every method in your system. You would create a pointcut that defines that (using AOP syntax). Then, you associate the code (called advice) you want to insert at that pointcut (such as a logging statement). The pointcut definition + code + other things is called the Aspect (which is roughly analogous to a class). Then, that aspect is spliced into your core code (either at runtime, or compile time depending on the AOP system you are using).

In most AOP systems I've seen, you have a limited set of possible pointcuts (or rather, the join points they specify). Common examples include:

* Start/end of a method
* Start/end of execption handler
* Init/destruct of an object

There are a lot more, but these are the easiest to grok. Also, I gave a very trivial logging example here, but aspects can be used to provide actual program functionality, such as display code, or resource management.

A fairly clean implementation of AOP is in a language called AspectJ. AspectJ is Java based, with a precompiler that does the Aspect splicing before handing the code over to the Java Compiler to finish up. It produces pure Java Code, and does all the AOP stuff with syntactic sugar. There are other AOP language extensions for Java, which I cannot recall right now, that actually create Java programs that are spliced at runtime (Java bytecode is easy to manipulate this way).

For more info, I'd suggest a good Googling!

Miles Teg

Re:For those unfamiliar with AOP

[starling]

Aha, now I see the core idea. I must say that it sounds somewhat useful but *very* dangerous if misused (and you know people are going to).

I'm not a huge fan of hiding things unnecessarily because it can cause unexpected behaviour and make programs harder to debug. Limited to a set of well tested objects and doing stuff that the caller really has no need to know about or control, fine.

BTW, AspectJ immediately reminded me of cfront from the early C++ days. Now that was a scary way to implement OO.

Re:For those unfamiliar with AOP

[snorklewacker]

If you want something to happen when a certain thing occurs, wouldn't you just call a function or a method when that whatever occurs? Why would you want a goto style statement there?

The whole idea of AOP is that it's not a GOTO. The "interceptor" (or whatever the jargon of the week is) gets called, does its thing, returns, and your original function runs. This is nothing, lisp does this with defadvice, even emacs lisp can do this (and indeed emacs lisp makes good use of it).

The neat thing about aspects is that you define them in ONE place. So you tell it "I want function setup_db_connection() and teardown_db_connection() called before every method on any Person, Room, and Resource" (imagine it's a scheduling app). This is just like subclassing, but you don't have to rewrite anything else in the app. In fact, VB programmers who did this sort of hook trickery actually did call it subclassing. If you use a factory pattern, you can do this sort of thing without AOP, but the idea of AOP is to not force you to rewrite everything to use factory patterns -- you just define the "aspect" once, in one place, and it affects everything you tell it to.

I find AOP is a great way to impose "external" conditions like debugging, extra asserts, and tests. I don't think it's necessarily a great way to structure an entire program, though someone with more experience in the methodology might make it work. As a new methodology, it's rife with shoddy implementations, buzzwords, overuse, poor use, and general immaturity. This is how all methodologies start out however -- even structured programming went overboard when it was first introduced to the mainstream.

Re:For those unfamiliar with AOP

[mysticgoat]

A better example might be a computerized patient record system (CPRS).

In a CPRS, it is clear that the core concerns involve information related to the patient's health. However if the institution is going to stay in business, there is a strong secondary concern with regard to diagnosis and treatment costs, billing, and so on. Obviously a healthy hospital has to deal with both of these.

AOP's promise in this situation is to allow these two mission-critical concerns to be temporarily divorced from each other, so that in a medical emergency the patient will get the treatment he needs in a timely way, without doctors and nurses having to deal with billing and cost issues (Clippy: "It looks like you want to defibrillate the patient. Would you like me to compare the costs of alternate treatment modalities?")

I've not run into this "AOP" thingee before. My impression is that the problems it is supposed to solve would be better approached by a change in the object hierarchy-- that its use would be sort of like adding epicycles to epicycles when a Copernican revolution is really needed. In the CPRS example, rather than having a PATIENT object with healthcare and billing concerns, it might work better to have TREATMENT and BILLING objects that were separate components of the PATIENT object.

I'm not convinced that the problems AOP is intended to solve couldn't be finessed by refactoring into a different hierarchy of objects.

Re:For those unfamiliar with AOP

[snorklewacker]

If you're writing a telecom app, you probably SHOULD be using lightweight processes and IPC. That's Erlang's bread and butter. But telling people that "everything in methodology A can be done in methodology B" is totally uninteresting and unhelpful. Anyone who knows the first thing about computer science can just throw out Church-Turing equivalence and say that they're all equivalent. The fact that I could write the equivalent program by soldering transistors together in the right combinations doesn't exactly sell me on that methodology.

Doesn't it behoove you to actually find out what you're dismissing out of hand? Microsoft didn't invent AOP, Xerox did, so you're allowed to think critically in this situation.

Re:For those unfamiliar with AOP

[istartedi]

Excuse me, but was that supposed to mean something?

Asking that question in a discussion of programming methodologies has been futile for at least 10 years. I've never cracked a book on any of these methodologies. Object Oriented was the last one that came anywhere near making sense, and only to the extent that it built on and clarified structured programming.

Whenever I hear (blah)-oriented in the context of programming, I just tune it out because I know it will only lead to a symposium on synergistic paradigms. I do quite well with this approach.

Re:For those unfamiliar with AOP

[Keeper]

Complicated as in ... complicated. Not simple. So I suppose both of your comparisons apply.

Re:For those unfamiliar with AOP

[starling]

See my other message. I did look into it a bit more and came to the conclusion that AOP is marginally useful in some situations, but is way too open to abuse.

Saying that everything in A can be done using B *is* a valid criticism if B has advantages that A does not share. That's why we have different programming languages and techniques.

Re:For those unfamiliar with AOP

[starling]

Thank-you. I was wondering if anyone would understand that I wasn't attacking AOP so much as the sheer amount of jargon being used to describe what turns out to be quite a simple idea.

Re:For those unfamiliar with AOP

[Keeper]

They described a different way to do something that has been done for decades. This allows you to compare and contrast the traditonal way of doing it to the AOP way of doing it.

Re:For those unfamiliar with AOP

[Hanji]

Now, I'm neither an AOP nor a lisp guru ... but does this sound like CLOS :around methods to anyone else?

Re:For those unfamiliar with AOP

[MarkusQ]

Exactly.

When I implemented this sort of thing for a project in Ruby a few years back, I just grabbed all the CLOS nomenclature because I was familiar with it. I didn't even realize I was using "AOP with funny names" until someone reading the code mentioned it. When he asked why I didn't use the "standard" terminology, I lent him a copy of "Object Oriented Programing in Common Lisp" (c) 1988, and asked why the AOP people had to invent new words for everything.

I have yet to get an answer.

--MarkusQ

Re:For those unfamiliar with AOP

[macshit]

The "interceptor" (or whatever the jargon of the week is) gets called, does its thing, returns, and your original function runs. This is nothing, lisp does this with defadvice, even emacs lisp can do this (and indeed emacs lisp makes good use of it).

Note that in Emacs lisp, "advice" (as it's called) is considered a debugging tool, and a way for users to add otherwise unanticipated functionality, but it's not acceptable for code in the official Emacs sources to use it.

The reason is that it makes the program hard to understand, as there's no obvious link from the "advised" code to the "advice".

In general the way such code is rewritten to make it acceptable for inclusion is to add an explicit hook invocation at the place which was advised -- this keeps the flexibility, while making the connection more explicit (a programmer reading the source can see that there are potential calls to external code at that point).

Re:For those unfamiliar with AOP

[matt me]

Excuse me, but was that supposed to mean something?

Looks like the MIT geeks whose script randomly generated computer science papers are posting content onto Wikipedia. Is nowhere safe?

$249

[Anonymous Coward]

who is going to shell out that cash for 5 pages?

Re:$249

[Anonymous Coward]

Seriously, what the fuck. This makes me want to buy it just so I can post the damn thing all over the Internet. Does it come printed on hand made gold leaf paper that was blessed by the Dali Lama?

Re:$249

[Bodrius]

Well, the papers linked in the psot describe the basic problem well enough and they're not charging 250 bucks for the pdfs... not sure what other research results are included in the forrester report, but I doubt there's much you wouldn't find in published academic material if your time is worth less than that... or if you just enjoy reading the research itself.

Re:$249

[bryan986]

Our Money-Back Gurantee If you are not completely satsified with your research document for any reason, you can return it for a full refund within three weeks of your online purchase.

Oh gee

[Anonymous Coward]

"Powerful language constructs can be dangerous when misused"

Thank you for the wonderful advice and welcome to 1971!!

As for the GOTO comparison, it is disingenuous. The problem with GOTO is not that it is a flow control change, the problem is that it is an [i]unstructured[/i] flow control change. AOP is nothing if not structured, in fact its potential flaw lies in that the structures it represents can be so complicated the programmer can lose track. It's the absolute opposite of GOTO.

Re:Oh gee

[starm_]

"in fact its potential flaw lies in that the structures it represents can be so complicated the programmer can lose track." That's GOTO

Re:Oh gee

[Anonymous Coward]

"in fact its potential flaw lies in that the structures it represents can be so complicated the programmer can lose track." That's GOTO

Or object oriented programming itself.

Or most programs written in purely functional languages.

Or the C programs you get when you find that the simplicity of the structures you have to work with forces you to create decidedly non-simple designs for the systems you implement with those structures.

All flow control becomes confusing at some point; all programming concepts become dangerous when misapplied. But comparing them to GOTO for this reason ignores the reasons why GOTO is bad programming language design-- and a bad thing in general-- in the first place. These people seem to mostly be hawking similarity to GOTO just to catch attention ("oh! GOTO, you say?") and sell their report.

Re:Oh gee

[Bodrius]

No, the problem with GOTO is that, as a consequence of being an unstructured flow control change, it makes it impossible to trust your reasoning about code because it destroys your ability to scope it.

To quote: "... it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress ..."

I think Dijkstra's point was that any construct that does this is harmful.

Structured constructs are typically less liable to do this, but only because they are visible and the structure is known.

AOP does have the ability to inject arbitrary code in your function that can change its semantics and you cannot see this when reading the affected code.

No matter how structured that change is, its invisibility makes it impossible to fully understand your code from the source code without 'weaving in' all the aspects explicitly. Like GOTO, it destroys your ability to scope your reasoning of the code to the local view.

As much as I love AOP for a class of problems, this is a very valid concern that needs to be addressed.

It's certainly not the first language featureset that faces this problem; OOP can deal with its own issues with design by contract, either through documented best practices or by enforcing it in the language. I haven't seen much in AOP there, beyond the absence of problematic examples (which would typically come from real-world use).

Re:Oh gee

[Anonymous Coward]

Yes, you are right that's the thing that Dijkstra's original paper complained about.

Now here's the thing - I think this problem has already surface in OO, but so far been unrecognised. In large classes - which I see far too often - multiple method calls operating over a set of either static or object variables end up creating exactly the same kind of non-locality of reference that Dijkstra was complaining about (GOTOS often combined with global variables).

Now this AOP seems to be nothing but a glorified callback mechanism to me - is that right ? If so I can see why it would become such a problem. Especially if was overused to alter the behaviour of the original problem

There seems to be something similiar in lisp - and also recently in python, where certain functions can be decorated with a set of functions which are triggered by the act of calling it - this seems also certain to lead to the same sort of confusion.

Re:Oh gee

[maraist]

AOP does have the ability to inject arbitrary code in your function that can change its semantics and you cannot see this when reading the affected code.

Well, except that AOP can only modify code in a structured way.. You can replace a method (no more obscure than method over-loading), you can wrap a method, turning it's body into a nested scope (again similar to a method which calls super). Yes they have before and after methods, but these are mere conviniences to the wrapping of a method.

My argument is only that while AOP does hurt readibility, it's not MUCH different than holding a reference to a base class, and not realizing that your instance is really a derived class which over-loads your method. If you don't have the proper tools to warn you that a method is over-loaded (IntelliJ's Idea, or I believe eclipse), then you aren't privy to the details of execution. Moreoever, there ARE AOP analysis tools which can warn you that an aspect has wrapped this method. Thus, provided sufficiently intelligent tools v.s. sufficiently obscure inheretance points of basic OOP, the whole readibility point is moot.

My only concern with AOP is in definine an aspect that is more than you can chew. It may initially solve your problem VERY elegantly, but as the scope of the aspect grows, you can find more and more hacks which dramatically reduce understandibility of the code. And worse, can allow obscure bugs to appear. As I've said in other posts, I prefer aspects which do not directly affect the ability of a code block to do as it conceptually is designed to do. They must have side-effects which are useful to the aspect, and nothing else. Logging/tracing are perfect examples. Problem is to find other examples. Moreoever, these are "aspects" which could easily be implemented by a given VM.

Re:Oh gee

[MemoryDragon]

You are definitely right, but yet this problem is also a pattern issue, for instance, with Factory patterns, or with Runtime Object binding you basically run into the same issues, AOP is just another construct you can run into the mess if you do not take care.

The classical example of this, is to move lots of servicing code which happens to be in every application into some kind of beehive construct where you initialize the objects and their bindings with configuration files, you usually do not have any control if somebody injects code that way. But yet some of this stuff can be really useful, in unit testing for instance, where you easily can inject and replace mock objects in a bigger system with an implementation and you can find instantly errors to the spec.

Same goes for AOP. But the benefit in AOP is, there are several areas which ever bigger application has to face, which basically AOP really can help to make the code more readable if you use it wisely and not overdo it. The classical examples are, to move the error handling and logging code into central application scoped aspects, and also to build central aspects which which you can define crosscut concerns for, which enable you to automatically put a method into a clean transactional scope. The same would be possible for putting a method into a remote scope. All of this can be done without having to write a single line of code in the core algorithms.

Re:Oh gee

[Bodrius]

As I pointed out previously, yes there are similar known issues in OOP, but they have been studied quite a bit and there are existing solutions.

Also, the points of code injection in OOP are far more evident because of their visibility in the calling source code as method invocations, so they can be part of your coordinate system. In AOP they are just not visible from the analyzed source code, so your coordinate system breaks.

AOP papers in general seemed to ignore the issue and present only the examples that benefit the most from AOP, and many practitioners end up seeing it as a panacea... it's good to see a change in that trend.

I'm not someone to dismiss AOP for this issue; this is a methodology I have been interested for a while now and had some direct research interest in it at some point. But before AOP can be embraced as part of mainstream development, we need to address the problems that arise when it is used in a suboptimal way, as it will when large teams use it for large projects.

I'm sure some solutions will arise, whether that translates into language-feature modifications or just best practice documentation, but we need to be looking at the problem.

As I mentioned in another post, I think this is a sign of maturity, more than weakness, in AOP. It means that it is taken seriously enough for non-toy projects for its compromises to become evident.

Re:Oh gee

[Bodrius]

Well, except that AOP can only modify code in a structured way.. You can replace a method (no more obscure than method over-loading), you can wrap a method, turning it's body into a nested scope (again similar to a method which calls super). Yes they have before and after methods, but these are mere conviniences to the wrapping of a method.

I think you are missing my point: Lack of structure is the cause, not the problem. The problem is that from "just reading the source code" you cannot build a coordinate system to represent the state of your running process.

Invisibility creates the same problem, regardless of how structured is your invisible change. And that IS different.

Method overrides are both visible risk-points (you are the one calling the virtual method) and a well-known problem. That's part of the push for design-by-contract language features in research.

Even GOTO is a visible risk-point... they can make your coordinate system unmanageable by complexity or growth, but you are aware of the problem and can potentially grow your coordinate system to cover those cases on demand.

On typical AOP, the binding is defined by the advise, not by the pointcut. Your only hope of expanding you coordinates to know that you cover your code behavior is to include ALL aspects in your code as globals code snippets that can be injected in your code. With static weaving hopefully your aspect population, per project, is limited enough. With dynamic weaving, there is not even that hope.

One of the linked papers makes a very good point of comparing AOP not to GOTO, but to the declarative COME FROM which changes a piece of code after the fact.

If you don't have the proper tools to warn you that a method is over-loaded (IntelliJ's Idea, or I believe eclipse), then you aren't privy to the details of execution.

No, but you are aware of the call to a virtual method, so by the semantics of the programming language you should always assume it can be overloaded and code to the documented contract (preconditions, postconditions, invariants and errors).

Depending on the language, parts of the contract may or may not be enforced, but you are aware of the risks in that line of code.

Moreoever, there ARE AOP analysis tools which can warn you that an aspect has wrapped this method. Thus, provided sufficiently intelligent tools v.s. sufficiently obscure inheretance points of basic OOP, the whole readibility point is moot.

That was part of the point in the previous post:

Without doing the weaving explicitly so you can see this change, analyzing the code is hard or impossible. The problem is not readability, it is visibility. As you mention before AOP is well structured, and once the weaving is visible it is typically not that complex to read.

The problem is that you need special tools to SEE in the first place, and these tools have to take the whole project as a whole. This is is a break from previous methodologies where the IDE was a convenience... now it's an essential CASE tool that is part of your language: without it the code does not make sense.

And with dynamic weaving, your tool still cannot speculate on who may wrap your methods at runtime in the future.

As I've said in other posts, I prefer aspects which do not directly affect the ability of a code block to do as it conceptually is designed to do. They must have side-effects which are useful to the aspect, and nothing else.

Most or all of the problems would be moot if we restricted the flexibility of AOP as a general programming language methodology, but that requires a conscious change in direction in AOP, and more research on what limitations could we take without sacrificing the usefulness of AOP...

- Aspects which keep the method return invariant are safe, but they are a very limited us

Considered... Harmful?

[Mancat]

Really, I did read the article, but the headline is kind of discomforting. I mean, how is it harmful? If I were reading this headline while writing aspect-oriented code, should I stop immediately? I wouldn't want to die, you know. If I'm going to die, Slashdot, you need to let me know!

Re:Considered... Harmful?

[The Amazing Fish Boy]

Thanks to Slashdot, I am now eating all the Twinkies I want! Apparently I am now "healthier than I thought." I simply avoid this "AOP" thing, and it's all good. (I'm also picking up some hip slang around these parts.) God damn you, Dr. Atkins. You can rot for all I care. With the Slashdot diet, I needn't exercise any self-control or socialize with others. And thanks to the Slashdot dating service, my love life has never been better. I found a plump girl with a low enough self-esteem to play along with my elaborately frilly warlock fantasies. I put my life in the hands of CowboyNeal, and you should, too!

Re:Considered... Harmful?

[geminidomino]

Read and be enlightened

Re:Considered... Harmful?

[Anonymous Coward]

Bravo, old chap!

NEWS FLASH

[ZorbaTHut]

Useful technique, chemical, or product can be dangerous when misused! With this groundbreaking announcement, aspect-oriented programming joins up with jet planes, oxygen, razor blades, and almonds. Scientists urge all Americans to avoid anything that could, in any way, be harmful to anyone, and the government will begin production of mandatory Full Isolation Spheres (tm) within the week.

Re:NEWS FLASH

[Anonymous Coward]

I think the overall theme to procedural programming, OOP, aspect-oriented programming, functional programming, and whatever others are out there, is that basically no one can make up their mind how programs should be written. Basically, we are all a bunch of clueless noobs, even the veteran programmers among us.

Re:NEWS FLASH

[Jedi Alec]

* insert Philip K. Dick reference here *

Re:NEWS FLASH

[m50d]

You get funny, but you'd be surprised how many people seem to think using OOP suddenly makes everything good, and anything that doesn't use it must be bad.

Re:NEWS FLASH

[Anonymous Coward]

BREAKING NEWS:

Do not use Full Isolation Sphere (tm) inside a Full Isolation Sphere (tm). It's effect is similar to an overdose of dihydrogen oxide

Re:NEWS FLASH

[Jonny_eh]

Don't forget H20, hundreds die from overdosing (or 'drowning') on this abundant but dangerous substance. You might even have some in your home! You children may be drinking it RIGHT NOW!

Re:NEWS FLASH

[Trepalium]

There are a surprising number of constructs in Java and now .NET that just cover over the fact that not everything NEEDS to be an object. So-called utility classes are a prime example. They're not OO in any sense of the word, but immensely useful in the otherwise OO-enforced world of those languages. Although, I have to admit, it's rather amusing seeing an OO-purist get into a huff when you give them a program which uses printf or open/read/close from the standard C library in a C++ program.

Re:NEWS FLASH

[m50d]

They shouldn't be necessary. That's why I prefer python. It's deeply, deeply OO, but if you want to write a non-OO program with it you can go right ahead and do it, there's no need to encapsulate it somehow.

Let's not forget

[Anonymous Coward]

GOTO + Functional Programming, which of course = Call with Current Continuation

At which point your head explodes

Re:Let's not forget

[Storlek]

It might be bad, but it's still not at the same level as COME FROM.

Angry Flower

[maxjenius22]

http://angryflower.com/aposter.html

Re:Angry Flower

[antime]

Or, as the submitter would have written it, "Angr'y Flowe'r."

Re:Angry Flower

[wootest]

Or "Angry Flowers Considered Harmful".

A bit sketchy to be called an article

[Goosey]

The one-paragraph 'article' is just a tagline for a 250 dollar document. Quite dissapointing to read that lead in and find that I won't actually be aquiring any new information on the topic. :\

Re:A bit sketchy to be called an article

[tomhudson]

Quite dissapointing to read that lead in and find that I won't actually be aquiring any new information on the topic

Lets see the information you acquired:

1. Slashdot now shills for $50-per-page reports.
2. 60 lines of code == 1 page, that works out to under a buck a line. So you've learned that your code has lots more value than any stinkin' paper from Forrester, especially since nobody's going to buy it - they'll all be "complementary" copies;
3. You now have another word to add to your Bussword Bingo card
4. Analysts still don't know what they're talking about, but they're finding INNOVATIVE NEW WAYS of communicating that

See, that wasn't so hard. Bet you can come up with some more :-)

Executive Whining

[idsfa]

There's a new idea in field I am incapable of getting a job in that is gaining in popularity among people I wish cared about my opinions. Buzzword I am dissing is intended to address common problems that buzzword everyone likes doesn't address well, plus something into which I have no insight. However, buzzword I am dissing is a risky solution: Complaint which betrays my ignorance and has been likened to somthing everyone hates. attack by analogy. Buzzword I am dissing will find some uses among people I secretly envy, but for the needs of (me) typical application developers, language gurus would do better to write something I can understand. My paper is important, pay me $50/page to read it.

Re:Executive Whining

[hazah]

if only i had mod points... if only.

good stuff.

Re:Executive Whining

[Syre]

It's actually worse than goto.

With goto you're branching to a specific label.

With Aspects you're doing dynamic wildcard modifications of code based on procedure names!

If that wasn't horrifying enough, it also circumvents the compiler (or interpreter)'s error checking.

This is even scarier and less controllable than old COBOL self-modifying code feature
(the much reviled ALTER X TO PROCEED TO Y ... statement),
long since removed from the language.

I'm missing something.

[Lord Kano]

There IS a GOTO statement in C++, an OOP language.

So how can AOP be like GOTO for OOP when GOTO is already the GOTO for OOP?

LK

Re:I'm missing something.

[Anonymous Coward]

Because AOP is not the GOTO of Object Orientation. It's the COME FROM of Object Orientation.

Re:I'm missing something.

[Keeper]

"goto" is a functional operation. Its use is not OOP related; it modifies the flow of execution through a function.

Thus, AOP is the OOP equivelent of a functional GOTO.

Re:I'm missing something.

[TummyX]

"goto" is a functional operation


I think you mean procedural. Functional programming is very different.

Re:I'm missing something.

[Keeper]

Eh...tomatoe, tomato ... :p You're right; I get the two terms mixed up occasionally -- it isn't a problem in my head because the concept I'm thinking of is correct, though it can be confusing for anyone trying to make sense of what I'm saying...

Re COME FROM

[Anonymous Coward]

The Clark link discusses 'COME FROM'.. which, after some analysis, is merely a change from imperative to declarative syntax... however lamely.
XSLt programmers will feel a vague sense of familiarity.. :-)

-fooburger

I like GOTO!

[Wabbit Wabbit]

At the risk of being modded troll, nuking my karma, being yelled at, laughed at, and otherwise folded, spindled, and mutilated, I'm gonna say it:

I like GOTOs. GOTO has it's place. Even in C++. Sorry all you purists, but there are times when it just plain works.


*runs and puts on Chinese wicker fighting suit and hides, trembling, behind a flame-retardant wall*

Re:I like GOTO!

[Anonymous Coward]

I've been programming for years now and I've yet to see a one, this isn't a troll either BTW, I'm geniuinly curious of the often proclaimed "good use of goto". Got an example?

In my mind, to be good it would have to be simpler than the non-goto way without making debugging more difficult.

Re:I like GOTO!

[William Robinson]

Yeah, I agree with you. Not sure whether your comment will be modded as offtopic or mine...but here we go

GOTO statements are *BAD*, I had been taught. But there are places, I had to use it. Being hardcore fan of OO... I hated it. But no options.

There are more shocks you see when u switch languages. Had big pains to implement frameworks in C++ while keeping options of callbacks. (If somebody knows, I will appreciate it) But I was shocked to see that CALLBACKS were put down by C++ purists, which is so common in any OO language (including Java, Object Pascal etc).

Dunno where, I had read.."When I was young, I used to think the world is black and white. When I grew up, I found everything is grey".

Re:I like GOTO!

[Anonymous Coward]

Well, in my eyes GOTO is essentially the same as a JMP command in Assembly...

So, you could say that in the end, everything becomes nothing more than a long series of GOTO (and a few other) statements.

Re:I like GOTO!

[evvk]

Plain C:

void foo()
{
do some thing
if(error)
goto err1;

do something more;
if(error)
goto err2; ....

return;

err2:
free stuff
err1:
free more stuff
}

For anything else I shun goto.

Re:I like GOTO!

[Anonymous Coward]

Yes, and there's a reason we don't program in assembly anymore.

Re:I like GOTO!

[Keeper]

The goto operation can be rather useful if used sparingly and correctly. If I see a goto jump up (earlier in the function) instead of down, I tend to get worried. But it is useful to break out of nested loops or complicated logic statements.

It is also exceedingly useful for error handling, in that it allows you to skip the bulk of a function and still hit the cleanup section of the function. This gives you two things:
1) you avoid a deep, deep mess of nested if statements
2) you eliminate duplication of code in error handlers (and the bugs that occur later on when someone forgot to update one of those handlers to release some resource they just added)

Re:I like GOTO!

[Anonymous Coward]

I don't know why the fact that it's sometimes necessary would make you like it. Sometimes you need a rectal exam, but that doesn't make it fun.

Re:I like GOTO!

[Wabbit Wabbit]

That's pretty much all I use them for as well (branching to staggered rollback points in a function). That, and also a few cases where it was simply the easiest way to "cut and fail" (nods towards those of you who know PROLOG) out of a series of horribly nested and convoluted loops.


And as to the original article topic, I, for one, welcome our new AOP overlords. NOT.

Re:I like GOTO!

[Kupek]

Read some Linux kernel code, particularly the system calls. Most of them are structured in such a way that they do lots and lots of error checking, and do a goto to near the end of the function that performs cleanup (mainly, deallocation of structures) if any of the error checks fail. It's really the most elegant and obvious way to accomplish the task.

Re:I like GOTO!

[Anonymous Coward]

"cut and fail" (nods towards those of you who know PROLOG) out of a series of horribly nested and convoluted loops.

This is why Java has named breaks.

Re:I like GOTO!

[Anonymous Coward]

Well then the reason I've never encountered that would be that [when not using a garbage collected language] I use exception handling - a better way to handle that situation provided your language supports it.

I initially wrote "provided your language supports it - I guess that's the crux", but I realised that would be the same fallacy as saying "goto is good because some languages don't have any other branching mechanism". Dijkstra's point was that languages should have good branching mechanisms and ditch goto.

Thanks for taking the time to post that example.

Re:I like GOTO!

[Anonymous Coward]

This seems to be more an indicator of the poor expressive power of C than the worthiness of GOTO. It is also problematic because what if something happens which might result in an error in a subfunction? What if you at some point wish to purposefully split part of your actions there into a subfunction? In order to keep up this idiom you would basically have to be able to fit everything important you are doing here into a single function body. That function body, with time, could get pretty long.

Look at a modern language-- for example, Java-- and you will find not only that GOTO is not needed in such a context, but that use of GOTO would inhibit the ability to do many things that you might want to do with program structure.

Re:I like GOTO!

[Wabbit Wabbit]

But I was shocked to see that CALLBACKS were put down by C++ purists, which is so common in any OO language (including Java, Object Pascal etc).

Agreed, agreed. Back in the day I used callbacks and function dispatch tables a LOT. They were considered Good Things for all kinds of programming situations. The C++ way, I was taught, was to "bolt on" yet another class when you needed to implement a callback. In Java, it was interfaces (fine by me, never was much of a fan of multiple inheritance, 'though I've used it often). Ick to all of it.

I guess you're right, it's always hard switching languages. I've been coding in C++ since around '89(?), and there are still times I yearn for the "relative" simplicity of C.

Re:I like GOTO!

[tyates]

Exceptions are better because you can break out of levels and levels of nested functions. With gotos you can only jump within the same routine (or you get stack problems).

Re:I like GOTO!

[Anonymous Coward]

As somebody else in this thread said regarding an error-checking/cleanup example:

"suggestive more of the poor expressive power of C than the worthiness of GOTO"

I'd have to agree. Taken to an extreme, if you're working in a language that only provides goto, then goto will always be the most elegent way to to something.

Re:I like GOTO!

[Keeper]

Gotos in C++ are limited to the same method, so no stack problems there.

Exceptions incur an obscene performance hit, and should be used for 'exceptional' conditions and not expected/handled errors. You also have to worry about the case where someone else adds another exception handler that inadvertantly 'catches' your thrown exception (which makes for maintainance problems later down the road).

Re:I like GOTO!

[Anonymous Coward]

Or you could use named breaks and exception handling.

Re:I like GOTO!

[evvk]

The example was in __plain C__. And besides, exceptions are worthless in a non-garbage collected language. (Ugly kludges in C++ don't count as proper GC.) You have to catch them at every point to free stuff, and the nested structures become even uglier than gotos.

Re:I like GOTO!

[Anonymous Coward]

*LOL* Garbage collection *LOL*
You know, some people are coding things like HD Controllers or similar. Then you want to control *exactly* when to free the bus, not at some random point, when the GC decides to kicks in.

Re:I like GOTO!

[Anonymous Coward]

Yeah, but what if you're working in a language that doesn't have exceptions? In that case, the best you can do to make the error handling look "clean" probably involves using GOTO.

Re:I like GOTO!

[zorander]

Goto only has a place because C++ is a weak language. If c++ had a proper runtime exception mechanism or support for continuations (which can be used to implement the former but generally only serve to obfuscate code), then gotos would be wholely unneccesary.

Yes it works, but it's not clean. The only reason I use gotos in c/c++ code is to break out of multiple levels of scope or for a basic 'goto end' pattern in a long/complex routine that needs to ensure cleanup before returning. I suppose I'd also use it for performance reasons if I was that desperate, but I've never been there.

The fact that it works, though, isn't enough to make me use it except in the situations where there's no other choice. I see a lot of gotos in peoples' code where they don't need to be. The creators of C/C++ left goto in for a reason--there are times when there's no other practical choice.

A quick grep of 20klocs of code I wrote for a client indicates 12 uses of goto in 2 routines. One was a parser with a lot of multilevel stuff to break out of. The other was a non-blocking i/o routine that needed to ensure some state cleanup before returning from a lot of places, again in a nested hierarchy. Both were relatively long routines.

Re:I like GOTO!

[bushidocoder]

Gotos can be used in complex string parsing that involves groups to seperate your logic out by group and provide an implementation that doesn't switch a stack context all the time. For instance, regex engine's are often implemented with gotos.

You can replace "string" with any other form of buffered deterministic input parsing.

Re:I like GOTO!

[evvk]

The idea in that construct is to let the first error handler continue to the second, so that the freeing code does not need to be duplicated. Breaking the freeing code into functions is a bit heavy solution, having to pass them all the variables to be freed and so on, and it would only increase the amount of code.

A function longer than a screenfull is too long, I never have such.

Re:I like GOTO!

[Keeper]

You could, if you want hard to read slower code...

Re:I like GOTO!

[Anonymous Coward]

freeing code

Oh, I see. I misunderstood what exactly you were doing the first time. That makes more sense.

Re:I like GOTO!

[Trejkaz]

Well done, you can do the exact same thing without goto by merely inverting the if-condition.

Re:I like GOTO!

[top_down]

But I was shocked to see that CALLBACKS were put down by C++ purists

???

Callbacks are everywhere in C++ although these days they are often function objects instead of function pointers. Somebody who puts down callbacks is certainly no C++ purist.

Re:I like GOTO!

[top_down]

You have to catch [execeptions] at every point to free stuff, and the nested structures become even uglier than gotos.

The freeing of resources, all resources not just memory, is automatic in C++ once you learn to use RAII.

Look it up. It is one of major improvements of standard C++ over C/C++.

Re:I like GOTO!

[Anonymous Coward]

moron alert!

Re:I like GOTO!

[JollyFinn]

Okay here is something.
If you have TWO conditions to one specific code sequence where 2nd test *CAN* cause pagefaults if first test do not pass. The said code sequence is such that creating a separate function for it is out of question and replicating the sequence inside elseif would be just another place to fix problems. So I go for short goto sequences.
Like contion1 is something like if pointer=null or arrayindex=-1 or something similar.
Yes the arrayIndex=-1 while accessing array CAN cause pagefaults. Getting array mallocated to a new page so that the arraystarts at pageboundary and later when previous page gets freed using arrayindex -1 in tests gets pagefault. And depending on malloc implementation for large mallocations they hit ALWAYS pageboundary.

IF(condition1) goto label1;
IF(condition2) {
label1:
DOTHINGS;
}
I doubt people have such problems that such form becomes mysticly unreadable because use of goto.

2ndly I use GOTO as a replacement for return statement in functions where I need properly release the locks and do free() and other issues that are complex enough to varant the GOTO and for some reason would be stupid to put in its own function . But I use descriptive label, FUNCTION_END:
GOTO FUNCTION_END; is a line that you could read quite well.

Of course there is obvious nongoto way for first issue.

if(condition1){
DOTHINGS;
} else if (condition2) {
DOTHINGS;
}

Difference here is that there are TWO locations where you DOTHINGS. If we make a BUG in DOTHINGS there is risk that the guy that fixes it fixes it in only ONE location while leaving the other untouched, and goes happily since his testing shows that the bug got fixed. Or we add a feature and introduce some difference between those two paths and thats a BUG. And what about 3 tests wich each if succeed lead to DOTHINGS but if fails the later test(s) COULD cause a pagefault.

But for the 2nd thing I don't know what else to do in C. If I copy the code in the end to all locations where I should return I risk creating really bad syncronization bugs that are VERY hard to track down. I only need to make mistake ONCE in many locations to create deep problems that seem to pop up in completely unrelated location of code.
Or trying to do 100+ lines of code in DEEP nesting inside functions might be solution but when I look at the code it becomes REALLY unreadable by trying to track in which depth each thing should be instead being sequential.

Yes I'd prefer not doing same code sequences in multiple places since fixing a bug requires changing em all. I've just learned to DOCUMENT the use of goto and reasons for it so that others don't try to "fix" it. TWO METHODS of using goto separated by labelname, ONLY forward gotos. For first condition no unrelated code between goto and label ,and for 2nd the targets are always at the end of function and in numbered sequence if need more than one different location in sequence of freeing specific resources used inside function.

Re:I like GOTO!

[Anonymous Coward]

FSMs [I don't want to get the Angry Flower angry by saying "FSM's"] are an example. I have used it with good success implementing the FSM level of a program using the state diagram and gotos.

goto and FSMs

Re:I like GOTO!

[top_down]

Show me code how to assign callbacks.

Sure. This is an example using the boost::function and boost::bind libraries which have both been available for a long time and are in the process of becoming part of the standard C++ library.

#include <iostream>
#include <boost/function.hpp>
#include <boost/bind.hpp>

using namespace std;
using boost::function;
using boost::bind;

void hello() { cout << "hello from function" << endl; }

struct Object {
void hello() { cout << "hello from member function" << endl; }
};

int
main()
{
// callback with a normal function
function<void()> f(hello);
f();

// callback with a member function
Object o;
f = bind(&Object::hello, &o);
f();
}

If you don't want to use libraries just assign function objects or static class functions.

If you want to do several callbacks at once check out one of the many available signal/slot libraries.

Re:I like GOTO!

[Anonymous Coward]

Um, you are aware of what happens to the code you write before it executes... right?

Re:I like GOTO!

[sjelkjd]

Ever heard of auto_ptr?

Re:I like GOTO!

[Anonymous Coward]

IF(condition1 || condition2)
{
DOTHINGS;
}

Re:I like GOTO!

[insert_username_here]

It is also exceedingly useful for error handling, in that it allows you to skip the bulk of a function and still hit the cleanup section of the function.

That is what exception handling, and the finally statement (in Java, anyway), is for.

It has the added bonus of making sure that all the stuff you created is automatically destroyed where necessary (in C++, anyway) - you don't even have to type a thing.

Re:I like GOTO!

[Anonymous Coward]

Thanx.

But u see the point. ur comment Callbacks are everywhere in C++ although these days gives an impression as if, callbacks are part of standard C++ way.

If u r aware, OOP was first implemented on pascal (rather than C). And Pascal had inherent capability, while C++ did not. I could go with the list of many things. For example: C++ did not provide any mechanism to identify whether this object is instance of *THAT CLASS*.

Anyway, discussion will prolong. and is becoming offtopic. :-)

Re:I like GOTO!

[evvk]

Yes, auto_ptr is exactly the kind of ugly C++ kludge I mentioned. *Yuck*.

Re:I like GOTO!

[Keeper]

As the goto statement does not exist in Java, it is a given that we're talking about C++.

While anything allocated on the stack will be destroyed when an exception is thrown, any resources allocated during execution will leak (ex: handles or memory allocated on the heap). As the data on the stack is deallocated (the very items which were referencing the afore mentioned resources), you never get an opportunity to clean up after the error condition. To make matters worse, you never get an opportunity to rollback the state of the operation when you throw the exception.

Not to mention the complications that arise when SEH is thrown into the mix (destructors are never called on objects allocated within an SEH block)...

Obviously you can write code to work around that. However, it is far more complicated and error prone than ensuring that the flow of execution always hits the end of the method.

Then, there is the overhead of actually throwing an exception ... making a pure virtual function call is cheap in comparison.

Re:I like GOTO!

[castrox]

Also, you may use GOTO for breaking out of multi-level loops where a single BREAK won't help you. E.g.:

for (int i=0; i<10; i++) {
for (int j=i; j<10; j++) {
...
if (i*j == x)
goto SUCCESS;
}
}

SUCCESS:
...

Re:I like GOTO!

[Keeper]

The use of RAII breaks down when resources must be freed in a deterministic order, or worse, when resources are interdependent.

Re:I like GOTO!

[Anonymous Coward]

If you are programming in a language where GOTO's are useful, it's time to learn a new programming language.
Seriously... simplicity is the biggest requirement, and GOTOs are exceedingly bad for simplicity.

Re:I like GOTO!

[maxwell demon]

Callbacks are everywhere in C++ although these days they are often function objects instead of function pointers

Great! I am looking for an example.

Ok, here you go:

#include <vector>
#include <iterator>
#include <algorithm>
#include <iostream>
#include <cmath>

bool is_negative(double x) { return x < 0; }

int main()
{
std::vector<double> v;

// read numbers from standard input
std::copy(std::istream_iterator<double>(std::cin),
std::istream_iterator<double>(),
std::back_inserter(v));
// those iterators are actually callbacks packed into an iterator interface:
// istream_iterator encapsulates the input operator on streams,
// back_insert_iterator (the iterator which the function back_inserter
// returns) encapsulates a callback to a container's push_back member function

// replace all negative numbers with zero
std::replace_if(v.begin(), v.end(), is_negative, 0.0);
// is_negative is of course a classic callback (alternatively,
// a function object obtained by binding the second argument
// of std::less<double> to 0.0 could have been used)

// calculate square_roots
std::transform(v.begin(), v.end(), std::sqrt);
// and here we have a classic callback to std::sqrt

// sort from largest to smallest
std::sort(v.begin(), v.end(), std::greater<double>);
// std::greater<T> is a function object which just encapsulates
// the greater than operator

// output the results
std::copy(v.begin(), v.end(),
std::ostream_iterator<double>(std::cout);
// the ostream_iterator again is just a callback to stream output,
// encapsulated in an iterator interface
}

All standard C++, using the C++ standard library. And also it's all genuine C++ code, not just C code moved to C++.

Show me code how to assign callbacks.

I don't know what it gives you, but here you are:

callback = f;

I'm of course assuming that callback and f are of compatible types.

These example should be pure OO.

Why? If you haven't yet found out, C++ is not a pure object-oriented language, but a multi-paradigm language. The code I've shown actually uses generic programming (ok, it just scratches at the surface of GP, since it only uses the STL algorithms, but doesn't define one on it's own).

But then, if you want a typical OO version of callback, just look up the observer pattern. (And no, I'm not going to show that here as well, it's already hard enough to get the above code through Slashdot's lame[ness] filter!)

NO C global functions. (Every function is part of some object.)

Well, in the example above, I've had only 3 C global functions: is_negative (but this would probably be better done with standard function objects and binding anyway), std::sqrt (the standard library just has this as function, but it could be encapsulated as object as well), and main (whiuch you just cannot avoid in C++ anyway). The rest are either function templates or objects (which is typical for generic programming).

Re:I like GOTO!

[top_down]

The use of RAII breaks down when resources must be freed in a deterministic order

I use RAII to free resources in a deterministic order all the time. You might not have total control, you still have a lot of control. And if you really need total you control you can just handcode it.

or worse, when resources are interdependent.

When resources are interdependent than this should reflect in the design: they probably should be released in the same destructor.

Re:I like GOTO!

[Anonymous Coward]

Here are some clear reasons why Go To is harmful:

The first quote is from Shakespeare, "go to, go to; you have known what you should not do". You know you shouldn't be doing it but it you do it anyway.

The second quote is from Genesis: "go to, let us go down, and there confound (confuse) their language, that they may not understand one another's speech.". Clearly this foreshadows spaghetti code.

The third quote is from Mikado: "Young man, despair,: Likewise go to,; Yum-Yum the fair: You must not woo. It will not do:: I'm sorry for you," This shows how truly deceptive the "go to" is because that's precisely what he ends up doing in the next line.

Since testimonals from well known sources are better than facts, it's obvious that you should not use "go to".

Re:I like GOTO!

[antientropic]

While anything allocated on the stack will be destroyed when an exception is thrown, any resources allocated during execution will leak (ex: handles or memory allocated on the heap).

Wow, this is stunningly wrong. That's what destructors are for - they will free any resources that your local objects allocated/acquired. That's the resource acquisition is initialisation paradigm, and it ensures that resources are always freed when you leave a scope. This is contrary to using a goto for error handling, where you still have to be careful that every execution path goes through the cleanup code. And of course, how are you going to ensure that some future maintainer doesn't add a "return" somewhere, bypassing your cleanup code altogether?

This is one of the really nice features of C++, by the way. It's much cleaner than finally blocks.

Re:I like GOTO!

[Peter La Casse]

Where the previous poster was stunningly wrong was when they stated "As the goto statement does not exist in Java, it is a given that we're talking about C++." We could just as easily be talking about C.

Re:I like GOTO!

[woodlander]

Everyone has their dirty little secrets.

Re:I like GOTO!

[marcosdumay]

GOTOs can destroy compiler optimization. Also, it destroys the flow logic of most of the programs that uses it, making it harder to read (but not all programs).

Exceptions are what was created to avoid GOTOs on error handling, it solves problems 1 and 2 that you point, but C doesn't have them (C is old, C++ has).

Several people use GOTOs on interruption handling, it makes their code a mess and very hard to maintain. But slightly faster.

So, if you know how to use GOTOs (and most important, how to not use), go ahead and use them. But if you are just an old BASIC programer that dont want to take time to learn how to program on a real structurate language, get out of the way.

Re:I like GOTO!

[Pete]

ur comment Callbacks are everywhere in C++ although these days gives an impression as if, callbacks are part of standard C++ way.

Well, callbacks are a fairly straightforward concept. They're most commonly used in things like GUI programming, where you do a lot of (asynchronous) event handling.

But more generally, callbacks are just a very specific example of functional programming, which is just another style of programming that emphasises functions as first-class elements. And because C++ supports several programming paradigms, you can do object-oriented programming, functional programming and/or generic programming - often all at the same time.

Just like in Perl, there's more than one way to do it. And there isn't any one "correct" way - whatever gets the job done is fine.

If u r aware, OOP was first implemented on pascal (rather than C).

No.

Object-oriented programming is widely recognised as first being implemented on a language called Simula in the 1960s. 1962 to be precise - for Simula I - though Bjarne Stroustrup based C++ most closely on the OO concepts in Simula 67 (1967).

Pascal was first implemented in 1970, though the original Pascal didn't support object-oriented programming.

And Pascal had inherent capability, while C++ did not.

I'm not quite sure what you mean by that. Most implementations of Pascal don't support object-oriented programming at all, much less have "inherent capability". Those implementations that do support OO-style programming usually aren't called Pascal - eg. Delphi, Oberon, Modula-2.

I could go with the list of many things. For example: C++ did not provide any mechanism to identify whether this object is instance of *THAT CLASS*.

You're using your terminology confusingly here, so it's difficult to work out exactly what you're saying. But I can say that I've only seen a few occasions where it'd be useful to work out if Base* p is actually pointing at a Derived object, and usually those cases arise when you've started out with a bad design or bad logic. Usually the whole point of having a (pointer-to) Base is that you're supposed to rely on using Base functionality. You're not supposed to care if it might actually be a Derived, the only thing that should matter is that it is substitutable-for a Base. If you need to access Derived functionality, you should have a Derived.

But anyway, in those cases where you're dealing with someone else's badly designed code, a dynamic_cast should be enough to get around it. Take your Base* and try to dynamic_cast it to a Derived* - if that fails, you haven't got a valid pointer-to-Derived. Go find the person that built the code you're using and kick them. Hard. :-)

Re:I like GOTO!

[Anonymous Coward]

Named breaks are gotos that use a different keyword.

Re:I like GOTO!

[Pete]

Well - it's kind of difficult to defend against a criticism so vague and (going by context) inconsistent. I mean, if you're going to say that C++ smart pointers are all ugly kludges (as I can't see a way you'd think auto_ptr is an ugly kludge but shared_ptr isn't), then you should really be comparing it to the alternatives - umanaged raw pointers which (as you've pointed out) leave you fucked in the case of exceptions. And if you think that they're ugly kludges too, then you pretty much think all of C++ is an ugly kludge :). Which is fine with me, don't get me wrong - just that you shouldn't specifically point towards the smart pointer technique as being an ugly kludge of a solution (to the problem of exception-safe dynamic memory management without automatic garbage collection).

There's also the minor detail that writing auto_ptr<T> t; inside one block is much tidier (and, IMO, clearer) than writing T* t = new T(); in one block and then matching that pointer up with a corresponding delete somewhere else. It's also safer - even before you bring exceptions into the picture.

As a final point, C++ does have true garbage collection as an optional extra. I haven't used it myself, but apparently some people do, and it works fine.

Re:I like GOTO!

[canuck57]

For anything else I shun goto.

Goto is NEVER required. There are aways structured ways around using it even in your example.

Re:I like GOTO!

[Anonymous Coward]

17 years as a professional programmer in high level langs - C, C++, VB, Java, C# - and I have NEVER used a GOTO since my university days when I got smacked upside the head for it. I haven't even been tempted. If you're working in a high level language that provides the typical-since-the-70s flow control mechanisms, and you can't program your way out of a problem without GOTO... or if you even have to THINK too hard about how to avoid GOTO... then you're in the wrong business. I'd hate to be the sucker who has to rewrite all your wacky code so that it works and is maintainable.

Re:I like GOTO!

[Pete]

Whether you think of them as ugly kludges or not and whether you think of them as an acceptable solution or not (and you certainly have the right to your opinion (informed or not) on both points), the conventional C++ solutions for exception-safe dynamic memory management do work.

And you don't have to "catch exceptions at every point to free stuff".

Re:I like GOTO!

[Anonymous Coward]

Well, there always is longjmp. Or in a real programming language, continuations.

Re:I like GOTO!

[maraist]

You know, some people are coding things like HD Controllers or similar. Then you want to control *exactly* when to free the bus

Perhaps there is an aspect of what you're saying that I'm not experienced enough with (not having written/modified many drivers). But if by "freeing" a bus, you mean something equivalent to closing a file, or breaking a network connection. You're absolutely NOT supposed to let the garbage collector do this. You are supposed to explicitly call exit, close, disconnect, or what-have-you. Unless the object put these statements in the "finally" clause, the GC doesn't even do this.. Moreoever, in Java, you are never garunteed to have "finally" called anyway (as certain optimizations can often be made such as with a copying-collector that look only at live objects, not non-live-referenced obects).

And if what you mean is that you're releasing memory to the system and allowing the driver to exit, then that's no different than finding a way to unload your application/applet when you're done anyway.

I am aware of Java-based driver/controller situations. Mostly with embedded hardware that use whatever micro-java OS was popular in the 90's; never worked with it personally, so I don't know the limitations. But in these circumstances, you can use hardware assisted garbage collection which can be rather powerful.

I'm basically just asking for clearification of what you think is inherently limiting with Garbage collection, when in fact, GC to my mind enhances the long-term resource maintainability of any piece of software.. The only caveat is that if you need real-time performance, you have to use a lower throughput G.C. which has an upper-bound CPU utilization.

If you're really real-time, then you're going to adhere to the mantra of keeping two sets of objects, one base set of objects which are long term and one set of transients. Their fields only reference other long-term objects; never transient material. Transient references only live as locals and parameters. To prevent aging of transients, the call stack should periodically exit all the way out to the root of the thread.

Thus the vernarable objects will soon be tenured into a region of memory which is hardly ever garbage collected. And transient objects will only ever live in the eden (with a scant few ever accidently being tenured). Thus each garbage collection will find that most of the eden should be flushed, which involves almost no work. It is only when the eden can't flush out 80% of itself that it spills into tenured memory space. And it is only when tenured memory space is full does it have to perform a full GC and thereby wake up into cache the entire tenured section of memory (less large arrays of primatives).

The above are only suggestions to improve performance / throughput.. Your GC is still chosen so as to have real-time time constraints.

Re:I like GOTO!

[Anonymous Coward]

Oh.My.God.

Two pieces of advice:

First:

if (condition1 || condition2) {
DOTHINGS;
}

Secondly:

If you're employed as a C programmer, quit now while you're ahead.

Re:I like GOTO!

[maraist]

Breaking the freeing code into functions is a bit heavy solution

See, you obviously recognized the "correct" solution. With the comment "don't want to duplicate code", you immediately have to think of writing a function (which is the only reason functions exist; well, that and easier-to-read recursion).

The problem with your jusitifation is that it isn't true. I challenge you to write a java snippet with a while loop of a million iterations, one with an inlined code-block, one with a private method invocation, and one with a public method invocation.

Guess what, they'll all take the same amount of time. That's the point of a JIT. A c-compiler could see the private method and say, hey, the insert is small, let me inline it.. But I CAN'T inline the public method unless I want to tripple the size of the code (two inlines + the original method). But in a VM, you can do whatever the hell you want, because the actual runtime environment looks NOTHIGN like the original byte-code.. You are actually generating native assembly code based on the byte-code. Moreoever you're continuously modifying the particular byte-code... As for the public-method, the VM knows if anybody is actually refercing that public method; beit a call or an over-loaded method.. And at the point in time that you're iterating over the loop, the VM can decide to erase the public method and inline it, keeping a tight piece of code.. IF a constructor is called from a class which DOES overload or invoke the public method, then the optimization is invalidated and new analysis begins.

That's the bueaty of VM's.. You write really innefficient code that focuses on clearity and maintainability.. The language is written for HUMANs, or more and more analysis code. Optimizations are delegated to the JIT.

Now with the pushign of multi CPU architectures, the arguments of GC's are going to start falling away.. SUN's JVM, for example has certain GC optimizations which are demonstratively only useful once you get to 4 or more CPUs. With hyper-threading enabled P4's, we're already at that point. With dual core hyper-threading, we're that much closer to a practically JIT's world where the detrements of virtualization become disguiseable.

Sorry, this was a rant mostly about performance which really should have been directed at a different post. BUt it was kind of related. :)

Re:I like GOTO!

[Anonymous Coward]

Hah! Tell me about how exceptions and named breaks are simpler than GOTOs.

GOTOs are how computers work. They're close to the machine. If you're thinking in terms of GOTOs, conditional GOTOs, and GOSUBs, and of pointers that are really ints, you're thinking about how the computer works.

I don't understand what is wrong with all of these programmers who seem to hate how computers really work and want to work in some arbitrary model that distorts their perceptions of efficiency and clarity.

A programmer can become decent later if he starts out with BASIC, provided he learns assembly next. But no mind can ever be truly adequate to the task of programming if raised on a goto-less language like Pascal or Java.

Re:I like GOTO!

[maraist]

More and more languages support named continue/break statements. Don't remember if gcc supported it yet. Such statements are more powerful than goto because they imply cleanup code that may or may not be implied by a goto. For example, you know that the for-post code block will be invoked on a labeled continue, as well as running the conditional.

FOO: for(..) {
BAR: for (..) {
if (..)
continue FOO;
if (..)
break BAR;

Perl was nice because it had even more flow-control statements for clearity.. "redo", for example would go to the start of the loop-block without running those two for-blocks. This is nothing particular to perl, just a conspectual-clearity which was valued by the compiler writer; to avoid justifying use of a goto.

Re:I like GOTO!

[Anonymous Coward]

Then there is the reality in all languages that not everything fits well into a class. Some things will be 10 lines in a more procedural form and 50 or more (and much more complicated) when fit into a class. Goto if properly used has its place. Just don't use it beyond the scope of a single function, not across functions, and definitely not across cpp source files.

C++ has the ability to mix approaches and this is one of its biggest strengths. Only an over the top purist would ignore this key advantage. I have been programming in C and C++ for almost 15 years and programming in general for more than 20 years now.

AOP does concern me in the same way that overusing GOTO can. The single problem of goto and/or overusing C++ classes is that it completely destroys the ability of the programmer to follow the flow of the program code. This significantly affects the ablility to maintain the code or even to treat it as modular code which was the whole point originally to C++ to begin with. C++ classes are useful for those things that have a definable set of fuctions and behaviors and does not have too complicated an inheritence model, but fails miserably when these rules are broken. AOP seems intriguing but forgets this very important aspect of programming and therefore fails in my mind to be worth the trouble.

I have seen various C++ frameworks (MFC and PowerPlant) which are impossible to follow the proper execution flow because of these issues! If anything is going wrong, especially due to your own coding error, it can be impossible to make sense out of the stack callback order or what aspect of your code is wrong. I have spent many days dissecting MFC and PowerPlant to figure this out and then given up because of the sheer scope. Documentation of these processes quickly get so abstract as to make them useless as well.

BC

Re:I like GOTO!

[maraist]

Goto is NEVER required. There are aways structured ways around using it even in your example.

While I'm a long-time student of goto == spagetti, I'd stay away from the "NEVER" statement.

Imagine, for example an embedded controller which has a hot-off-the-shelf c compiler. It's brand new, and c is great for new architectures because it's so low to the metal, it's reltaively easy to make a compiler generate assembly code from the language.

In such a circumstance where driver-performance and memory-usage is critical, a goto is still acceptible, though you might want to wrap functionality in MACRO's at that point. That way you still look like you're calling functions for clearity purposes.

Thankfully low-power, low-cost, high performance computing is virtually apon us, and thus the needs for this are deminishing.

Re:I like GOTO!

[50000BTU_barbecue]

"GOTO has it's place."

An apostrophe has its place. That wasn't it.

Re:I like GOTO!

[greg_barton]

Congrats! You've invented exception handling.

Re:I like GOTO!

[evvk]

Heavy in lines of code, not performance.
Code should be as short as possible while still readable.

Re:I like GOTO!

[Anonymous Coward]

Thanx.
But u see the point. ur comment
If u r aware

I'm sorry, I don't speak moron.

Re:I like GOTO!

[Baki]

Apart from exceptions, you can fully replace goto statements by using small methods and bailing out in the middle, i.e. put a return statement somewhere before the end of the method.

Should you need some statement before truely returning, you can:

* use a try/finally block
or
* call your method from an extra method, return in the middle and put the 'end' statement in the extra method

IOW: I see no reason at all for a goto statement if you only jump forward.

And jumping back is, as we agree, inacceptible.

Re:I like GOTO!

[stonecypher]

The freeing of resources, all resources not just memory, is automatic in C++ once you learn to use RAII.

Look it up. It is one of major improvements of standard C++ over C/C++.

What are you talking about? Resource acquisition is allocation is a technique, not a language facet. I use it in a dozen languages. It's just an idiom, and it works perfectly well in C.

Re:I like GOTO!

[snorklewacker]

> (destructors are never called on objects allocated within an SEH block)...

Absolutely wrong. The reason throwing exceptions has such high overhead is precisely because it has to call the destructors of every object that goes out of scope. You simply don't know what you're talking about.

Re:I like GOTO!

[stonecypher]

But I was shocked to see that CALLBACKS were put down by C++ purists

I don't know any C++ "purists" which say that callbacks are bad. What you may be confused by, which I suspect is the case since you're so happy to excahnge case, is that CALLBACK - a windows calling convention frequently used by people when totally unnessecary - was being panned. It is frequent for novice programmers to think that to make a callback one must declare with the calling convention CALLBACK, which makes their code non-portable.

Callbacks are simple, easy to portably implement, and very very common in C++. They're the primary event handling mechanism in both single threaded and re-entrant C++. The idiomatic implementation is

typedef int (*FPFloatReturnsInt)(float);

void RegisterCallback(FPFloatReturnsInt cbFunc) {}

int ExFunc(float Foo) { return (int)(Foo); }

int main() { RegisterCallback(&ExFoo); }

Re:I like GOTO!

[stonecypher]

Those implementations that do support OO-style programming usually aren't called Pascal

Or Borland Pascal, Turbo Pascal, Berkeley Pascal, GNU Pascal, IRIE Pascal, FreePascal, etc.

By the way, Delphi, Oberon and Modula are Pascal in the same way that C++, C# and ObjectiveC are C, that C is BCPL and in fact that Pascal is C. That is to say, they aren't. (Delphi is Object Pascal, not Pascal. Object Pascal is further from Wirth/ANSI Pascal than C++ is from K&R/ANSI C.)

Re:I like GOTO!

[stonecypher]

I presume that Java is your home language?

C++ and Java see exceptions quite differently.

Java uses exceptions to handle most problem conditions, including things as trivial as conversion errors and preventing the use of unallocated object instances (a particularly easy example comes in the form of trying to use a BinaryWriter without creating it first, thanks to checked exceptions.)

C++ uses exceptions quite differently. In C++, error conditions are not a reason to throw an exception. Exceptions are last-resorts. If someone detatches the drive while you're using it, then you throw an exception. I mean hell, there are a lot of C++ programmers out there which think that running out of RAM isn't a good enough reason to throw an exception, hence (nothrow) new.

While anything allocated on the stack will be destroyed when an exception is thrown

C++ exception handling was specifically designed to make this not true. Consider reading Sutter's dialogue on the difficulty of properly implementing constructors and destructors for safe behavior in exceptions, since the particulars of stack unwinding during exceptions and allocation/deallocation failures during construction are so complex. Nonetheless, it can be done if one knows the rules; grab the Sutter Trio, the Meyers Trio or the C++ Faq book if you want to find out how.

There is a trivial example about halfway down this MSDN page.

you never get an opportunity to clean up after the error condition

Yes, you do, by design.

To make matters worse, you never get an opportunity to rollback the state of the operation when you throw the exception.

You get control back safely, and if you implemented the Command pattern, you can make that rollback quite easily.

Not to mention the complications that arise when SEH is thrown into the mix

What problems do you suggest structured exception handling adds to an exception mechanism which, no offense, you're apparently not particularly familiar with in the first place? Particulars would be nice; it might be that I can provide you with the resources you need to use these admittedly difficult tools correctly.

Obviously you can write code to work around that.

No, you really can't. See, this is the difference between C++ and Java exceptions: Java exceptions get thrown a lot. You should never, ever see a C++ application throw an exception; if they do, they're 1) buggy, 2) written by programmers from languages with different opinions about exceptions, or 3) really buggy. Exceptions in C++ are for handling serious machine failures, not software errors. Software errors can be handled by less intrusive means with far less overhead and far less complicated rules about resource unwinding.

To be plain, if you're attempting to use C++ exceptions to catch code failures, you don't understand the purpose of exceptions in C++. Just because they use the same keywords doesn't mean they're particularly related.

Then, there is the overhead of actually throwing an exception ... making a pure virtual function call is cheap in comparison.

Frankly, the cost of a last-ditch "holy crap the machine just went apeshit" mechanism isn't important. You should never see an exception. Exceptions in C++ are for corporate-level fault tolerance, and nothing else.

Re:I like GOTO!

[Keeper]

I use RAII to free resources in a deterministic order all the time. You might not have total control, you still have a lot of control. And if you really need total you control you can just handcode it.

And in the process your code just got a lot more complicated. Because now you use RAII in some places, and hand coding in other places. It gets worse if you do both in the same function, as then there is a large amount of confusion about when, where, and how certain resources are being removed. And don't get me started about what happens when someone manually cleans up RAII objects to enforce ordering, which tends to confuse the living hell out of people (ie: code maintainability and clarity is reduced).

Something else that hasn't been mentioned is side effects of RAII objects can sometimes be non-obvious. People tend to get used to treating them as the primitive types that they are, when really they are a wrapper class for a primative type. Sometimes the operations performed on that primative type have a non-obvious side effect, which leads to 'mysterious' bugs that people spend hours tracking down.

A good example of this is using RAII to manage a BSTR type. If you pass the RAII object into some method and a copy constructor is called to clone the object, you start off ok. The problem is once that method completes, the destructor on the RAII object is called. This calls a system method that overwrites the last error result, which was just set by the method you called. So your code ends up reporting a failure of ERROR_SUCCESS because you used an RAII type. This type of problem isn't limited to RAII types, but it is most unexpected with this sort of type due to the expectations of a person using it.

There are other variations of this problem involved with trashing the results of method calls you can make (imagine your function has a BSTR RAII type in it, and you set the last error information before you return; the destructor for that RAII type will trash your last error result).

When resources are interdependent than this should reflect in the design: they probably should be released in the same destructor.

Once you exceed a certain level of functionality, you're not using RAII -- you're writing a class framework. While I'm not opposed to writing class frameworks to wrap complicated functionality and represent it in a simple fashion, I am opposed to writing class frameworks to manage simple operations.

Re:I like GOTO!

[stonecypher]

Those are called "functors."

Re:I like GOTO!

[Keeper]

As I said, used sparingly and correctly, they are a good thing. Used to ensure an exit block is hit in a method before returning, they are very readable and compiler optimization is uneffected. Typically, when not used to perform iterative actions gotos do not effect compiler optimizations which is why I said I get concerned if I see it jump up in the code. Very rarely will I accept code with a goto that doesn't jump to an error handler, as other constructs are better suited to the task the programmer is trying to accomplish.

Exceptions are appropriate for error handling when you encounter an error you can't handle, or for when a deep stack of nested calls needs to be cancelled out to some root level.

They are not appropriate (with they way they are implemented in C++) for handling common expected errors or for making code inside of a method more 'tidy'. The cost of throwing and handling exceptions is gigantic (it starts off by generating an interrupt, to give you a bit of an idea). Pure virtual function calls are cheap in comparison.

Re:I like GOTO!

[Anonymous Coward]

No you can't.

How do you skip the excepted (error-induced) code at the end of the function if the conditional is inverted and the function runs from head to tail?

The example above isn't the best, because the idea in such a logical progression is to catch the errors in the execution of _a loop_, which the original author did not include.

You can't just invert the conditional and skip error handling code in this case.

Re:I like GOTO!

[Keeper]

Here is what happens in your scenario:

void MyFunction()
{
char *szString = new char[25]; // do something

if (somethingfailed)
return; // do something else

delete [] szString;
}

szString leaks.

Now, that can be modified as follows:

void MyFunction()
{
char *szString = new char[25]; // do something

if (somethingfailed)
{
delete [] szString;
return;
} // do something else

delete [] szString;
}

Now imagine you've got 20 "somethingfailed" type conditions in your method. Now imagine that the cleanup code is non-trivial. And then imagine you need to make a change in that cleanup code... This gets ugly very fast.

There are lots of ways to 'work around' this sort of problem. All of them, IMO, are unacceptable for various reasons. Either they perform poorly, are hard to maintain, can have unobvious side effects, don't work in all but simple cases, or are obtuse (ie: result in WTF comments from people trying to figure out what is happening).

Re:I like GOTO!

[Keeper]

There is a difference between 'normal' C++ exception handling and structured exception handling (SEH). SEH is lower level than what you typically see with C++, and doesn't give you all of the niceties that C++ lops of top of it.

You should do some research of your own before claiming that I don't know what I"m talking about.

Re:I like GOTO!

[webview]

And besides, exceptions are worthless in a non-garbage collected language.

Not always true. Garbage collection provides a catch all (no pun), but ideally, well written code should handle all conditions and clean up the code (calling appropriate cleanup method, eg. Close()). Even in garbage-collected environments, the GC runs at (usually) unspecified times and there are many times assuming the GC will "clean up my code" is sloppy.

One should always try to code as lucidly as possible and clean up when appropriate. Microsoft: Can you please put the destructor concept back for us ex-C++ C# programmers?

Re:I like GOTO!

[Keeper]

I presume that Java is your home language?

I deal primarily with C++ on a day-to-day basis. I try to stay current with the various languages that exist, so I can speak with some intelligence about other languages and make appropriate decisions regarding what language to use when starting a new project.

I agree with your next two paragraphs regarding the use of exceptions in both Java and C++. Java's implementation of exception handling does not typically involve generating an interrupt, which makes it far more acceptable to use than in C++. Java's implementation of exceptions has its own set of drawbacks which I won't get into because it isn't relevent to our discussion here.

I mean hell, there are a lot of C++ programmers out there which think that running out of RAM isn't a good enough reason to throw an exception, hence (nothrow) new.

The logic behind this: If there isn't enough ram to perform an allocation, what makes you think there is enough to allocate for an exception? If the exception can fit in ram, great, you can handle the condition gracefully. If it can't, you would never get an opportunity to handle it gracefully. If you try to handle it both ways (throw if you can, return NULL if you can't) you just made your code twice as complicated for no reason.

Me: While anything allocated on the stack will be destroyed when an exception is thrown
You: C++ exception handling was specifically designed to make this not true.


I think you inserted a "not" while reading.

Yes, you do, by design.

You only get the opportuntity to clean up if you catch the exception. Terminating your method by throwing an exception does not give you the opportunity to clean up after the error condition. While you can catch the exception in your method, cleanup, and then re-throw, you end up with the problem you 'solve' by eliminating the 'goto cleanup' in the first place.

What problems do you suggest structured exception handling adds to an exception mechanism which, no offense, you're apparently not particularly familiar with in the first place? Particulars would be nice; it might be that I can provide you with the resources you need to use these admittedly difficult tools correctly.

SEH (differentiated from the normal kind of exception handling provided by most C++ compilers) doesn't call the destructors of any objects allocated on the stack.

Exceptions in C++ are for handling serious machine failures, not software errors

Agreed. My arguement was that C++ exceptions should not be used to control a functions exit or to guarantee cleanup of allocated resources, so I think we are pretty much in agreement.

Re:I like GOTO!

[jelle]

In C++, you have exceptions: "throw()" and "try {} catch()" to do that without the ugly goto's and with information carryover (why did the exception happen) and with much better implicit protection, such as little things like object destruction when they go out of context.

Goto's to jump out of nested loops are not a good idea for another totally different reason: the compiler will not be able to optimize the code as well.

Re:I like GOTO!

[SnowZero]

I agree completely. I never used goto until I saw it used in the Linux kernel, just like in your example. It's helpful when you have locks/semaphores, which absolutely must be balanced. C++ destructors can help for not leaking memory on early returns, but locks and other state still need to be cleaned up after errors.

Re:I like GOTO!

[jelle]

Local variables, when not placed in registers can be allocated on a stack, even in a basic block inside of a function, hence the goto can jump into another stack frame because many of them can exist inside of a single method.

btw: An expected error? What?

You're probably using goto's where you should be using a simple if().

Re:I like GOTO!

[SnowZero]

Destructors help, but do you wrap every libc or kernel function you ever use in a class? In real-world programming one has to interface with the incredible bulk of C code that is out there, and wrapping absolutely everything is damn near impossible. Each goto label replaces an entire wrapper class. I really like OOP, but when you start to get into low level interfaces, sometimes its not the most elegant way.

Re:I like GOTO!

[Keeper]

Objects may get destroyed when they go out of context (which also happens when you just return from the method), but non-stack allocated resources are not cleaned up. Exceptions handle that pattern about as well as the if failed cleanup pattern ("if (failed) { cleanup operations; return; }"), which is to say, poorly.

You are also assuming that information carryover is necessary or useful (which it isn't for a function which returns no result and is stuck catching exceptions it threw itself).

Finally, you are ignoring the performance implications of throwing exceptions like crazy in C++ code.

Jumping out of nested loops has its pros and cons. If your loops have a significant amount of code dedicated to managing when break should be called, odds are using a goto to jump out of it will not hurt perf much and it will aide maintainability. Again, I'm not advocating its use in all situations, just the appropraite ones.

Re:I like GOTO!

[Keeper]

Local variables, when not placed in registers can be allocated on a stack, even in a basic block inside of a function, hence the goto can jump into another stack frame because many of them can exist inside of a single method.

Compilers handle this correctly.

btw: An expected error? What?

It is a failure that you know may occur and can handle.

Expected error: File not found
Expected error: Invalid user input
Expected error: Website is not responding

Unexpected error: Out of memory
Unexpected error: My window handle is no longer valid
Unexpected error: A core component is missing

You're probably using goto's where you should be using a simple if().

I'm probably not. My use of gotos is typically restricted to ensuring that methods hit a common exit point. Until someone shows me a better way of handling the "if failure cleanup & return" pattern, I will continue using them for it.

Re:I like GOTO!

[SnowZero]

Which, incidentally, is not supported in plain C.

Re:I like GOTO!

[top_down]

Resource acquisition is allocation is a technique, not a language facet.

Of course, check out http://c2.com/cgi/wiki?ResourceAcquisitionIsInitia lization

it works perfectly well in C.

How does it work without destructors?

Re:I like GOTO!

[Anonymous Coward]

/* parent's code can be rewritten as: */
void foo()
{
int err = do_some_thing ();
if (!err) {
err = do_something_more ();
if (!err)
return;
free_stuff ();
}
free_more_stuff ();
}

/* however, I'm not really sure why we're "returning void" and not cleaning up the resources. Perhaps it's getting saved to a global variable? */

Re:I like GOTO!

[Anonymous Coward]

If your environment passively stores error codes and allows them to be silently overwritten, you have much worse problems than having to save and restore the value during destructors.

Re:I like GOTO!

[Keeper]

The conversaion is comparing and contrasting the use of "goto" and "exceptions". Java doesn't support the concept of a goto statement, so we can't be referring to Java. C doesn't support the concept of exceptions, so we can't be talking about C. Ergo, it is a given the conversation centers around C++.

Re:I like GOTO!

[Anonymous Coward]

I like GOTOs. GOTO has it's place. Even in C++. Sorry all you purists, but there are times when it just plain works.

I like the apostrophe. It has its place, even in everyday English. However, it isn't appropriate here.

Re:I like GOTO!

[Keeper]

If you're programming using the Win32 API, it is a fact of life. It does, however, raise to light the broader issue of unexpected consequences and interactions that may occur through the use of such classes.

Re:I like GOTO!

[bluGill]

There is still no code that cannot be done without goto. Sometimes goto is justified because it is faster which performance counts (which must be decided by a profiler, not a human!), or because all the if(error) checks you use instead end up making the code less readable than a simple goto. Those are the two most common reasons for goto, and so far the only two that I can accept. (though I'm open to more if you can defend it)

Re:I like GOTO!

[bluGill]

Not sure exactly what the grandparent was referring to. However there are some issues with garbase collection that make it unworkable for embedded systems.

The first is it destroys RAII. When I free memory my destructer runs, which can also release a lock. With the lock released some other code can now run. Without RAII I have to manage resources, which is just as difficult as memory management, but has many different interfaces to do that. (the procedure for releasing a file lock is different from closing a socket is different from releasing a semaphore, and so on) Good programing means other code should not know those internal details of a class. Even if I use a destructer (which isn't always called as you pointed out), it isn't called right away, meaning the next thing that wants that resource has to wait.

The next problem is it is not deterministic when the collector will kick in. In many embedded systems that code must run at certain times. When the collector is running your code cannot run. You partially alluded to this with your comment on using different garbage collectors, but that isn't a full fix to the problem.

Garbage collection is nice. However it does not solve all problems, and it causes other problems. Depending on what your requirements are it may or may not be worth having. In most projects you are best off mixing and matching - except that switching languages is often more of a cost (in complex code and performance) than sticking to one language and suffering where some things are not optimal.

Re:I like GOTO!

[Trejkaz]

I don't like coding on the morning of a public holiday, but here's how it worked in the days before people discovered exceptions.

void foo()
{
int success = // do some thing
if (success)
{
success = // do something more;
if (success)
{
// do final stuff for success
}

// Do cleanup for second "do something"
}

// Do cleanup for first "do something"
}

But as others have said, exceptions are much, much better. Except, of course, C++ exceptions, which suck.

Re:I like GOTO!

[bluGill]

and a copy constructor is called

Can't happen as RAII classes must define a copy constructor that handles this situation. In the case you described my copy constructor is defined private in the header, and has no implementation. The compiler will therefore refuse to compile any code that where it would otherwise silently make a copy.

This is basic RAII. I'm surprised you don't know it, as any introduction to RAII will point this out. (at least in C++ which is the only place I've seen RAII)

Re:I like GOTO!

[snorklewacker]

Ohhh, you mean MICROSOFT's implementation, the one in MFC, the one that makes no sense to use in modern C++, the reason C++ has structured exception handling in the first place, to avoid C macros that cause such problems. Well yeah. If you use setjmp and longjmp, they cause you problems in C++. That's why you don't use them.

C++ exceptions actually tend to suck in their own special way -- exceptions across DLL boundaries are often rife with nasty little surprises. But there's certainly nothing wrong with the idea, in general nor with C++.

Re:I like GOTO!

[Minna Kirai]

And because C++ supports several programming paradigms, you can do object-oriented programming, functional programming and/or generic programming - often all at the same time.

No, C++ does not support functional programming. Functions are not first-class concepts of C or C++. If they were, it would be possible for you to pass functions as arguments and return functions as output. That works with function constants (as pointers to a function written by the programmer), but not with functions defined at runtime.

Just try to make a straightforward translation of a functional program from Scheme to C++. It can't be done. Function pointers as objects which imitate functions give you some of the benefits of functional programming for a reduced problem domain, but aren't enough to deserve the "FP" name.

PS. If you try hard, you can make a "function object" with enough power to represent almost-arbitrarily functions defined at runtime. But that would be an example of "All programs of sufficient complexity eventually grow to include a LISP interpreter"

Re:I like GOTO!

[jelle]

I agree: Exceptions should be used as exceptions, not something that get caught 'like crazy'. Checks for common cases should not be done with exceptions.

Compiler perform many optimizations to loops, many of which will not be performed when a goto statement is possible, because the goto statement makes it difficult for the compiler to know which optimizations will result in a speedup without breaking the code.

If you often have code that needs to do 'cleanups' _and_ needs to check many sequential possible error conditions, such that a couple of "if(!failed) {}" sets make your function unreadable, you should probably consider splitting your function and/or rethink your resource allocations. Put all resources in an object of its own, and the compiler will clean them up for you when it goes out of context, just make a class where the destructor cleans things up, and instantiate the object in your function. Then you don't need nester if()'s, no exceptions, and more importantly, no goto's...

But then again, early returns are semi-evil too. But at least not as evil as a nest of goto's.

Re:I like GOTO!

[jelle]

"Compilers handle this correctly."

Actually, that may be true, especially since it's been many years since I last needed to use a goto.

The expected errors you list should never occur in speed-critical points, so the cost of throwing the exception doesn't matter (the cost of checking an exception is never more than that of checking any condition, such as an if()).

You may want to try putting your resources in classes, and let the destructors do the cleanups automatically as soon as you go out of context. imho, that is the c++ way (in plain C, it's not so clear though...).

Re:I like GOTO!

[Pete]

Erm... yeah, okay. Apparently my knowledge of the wide variety of Pascal-like implementations is woefully incomplete :).

My original point (that the first version of Pascal in 1970-ish didn't support OO-style programming) stands, but I'm happy to acknowledge that I was at least quite misleading with the statement you quoted - that there are lots of implementations of standard Pascal that do support object-oriented development now (most of which do have the word "Pascal" in their name).

Thanks for the correction re: Delphi, BTW. Obviously I paid too much (or perhaps not enough) attention to the ravings of the Delphi nut I used to work with. :)

Re:I like GOTO!

[arkanes]

You only get the opportuntity to clean up if you catch the exception. Terminating your method by throwing an exception does not give you the opportunity to clean up after the error condition.

RAII is used specifically to address this. If you don't know what it is, you've got no business writing C++ code with exceptions anyway. The typical use of GOTO in C code (see the Linux kernel for some good examples) is to simulate this sort of handling - you do some stuff, something fails, so you jump to cleanup and return. In C++, you create objects to manage the lifetime of whatever work you're doing (these are generally lightweight objects created on the stack, and therefore no real performance hit), and in an error condition all you have to do is return - cleanup code is automatically executed when you leave the block.

SEH is a specific mechanism, which is actually intended to be used from C, although I believe the MS compiler implements C++ exceptions on top of SEH. It's not really relevent, unless you make a point of using SEH instead of the language level exception mechanism, in which case you should expect to deal with the C legacy crap problems.

Exceptions shouldn't be used to terminate normal flow for many of the same reasons you shouldn't use GOTO - it's harder to reason where the code goes. Exceptions are for exceptional circumstances, although there's a great amount of debate over how exceptional something needs to be before you throw. I tend closer to trivial than you do, although not as much as Java does.

Re:I like GOTO!

[JollyFinn]

No I'll keep learning. I just dissassembled and tested this to work on 3 different platforms with multiple optization levels just to make sure that compiler does always stop before testing condition2.
on if(condition1||condition2)

Anyway as long as there is employed persons who do.

if(condition1) goto label2
DOTHINGS;
label2:

I think I'm not first one to go.

If you ask what I DO then I'll have to ask have your mobile phones had any crashes?

Re:I like GOTO!

[Pete]

No, C++ does not support functional programming. Functions are not first-class concepts of C or C++. If they were, it would be possible for you to pass functions as arguments and return functions as output.

You mean like this?

#include <boost/bind.hpp>
#include <boost/function.hpp>
#include <boost/lambda/lambda.hpp>
#include <iostream>

using namespace std;
using namespace boost;

int main(int argc, char* argv[])
{
function< int (int& a, int b) > f = lambda::_1 += lambda::_2;
int a = 0;
function< int (int b) > g = bind(f, ref(a), _1);
function< int () > h = bind(g, 3);

cout << "h() == " << h() << endl;
cout << "g(17) == " << g(17) << endl;
cout << "h() == " << h() << endl;
cout << "a == " << a << endl; // a == 23

return 0;
}

Slashcode stuffs up the indentation of course, but there's only one level of indent so it's still fairly readable.

Anyway, bind is a function, it takes a function f (defined as an anonymous function and assigned to f at runtime) as a parameter and returns a function (assigned to g at runtime). Same with g and h. I guess it's up to you to decide whether you'll accept that g and h are defined at runtime - the functional structures (of f, g, h) are defined at compile-time, but the parameters they close over (a, 3) are supplied to them at runtime (and they're certainly assigned at runtime).

And yes, this does seem to be almost a solution to the task that Paul Graham said probably couldn't be done in C++ (see appendix A at the bottom) - with a bit of handwaving over the types issue. Note that you can change the above so that it closes over the value of a but doesn't change a - simply by replacing ref(a) with a.

Just to be clear, I'm really not claiming that C++ can match languages like Common Lisp or Scheme for this sort of programming. It just can't. But it does a bloody good job of covering enough that it can reasonably be considered a language that supports functional programming (and supports it quite well, at that).

Which is pretty impressive given the limitations of standard C++.

Re:I like GOTO!

[welshmnt]

Well.....

for (int i=0; i10; i++) {
for (int j=i; j10; j++) { ...
if (i*j == x)
i=j=10;
}
}

He He He!

Re:I like GOTO!

[stonecypher]

It never ceases to amaze me how deeply people believe that one cannot have an OO model, including destructors, without language support. You do realize that C++ was originally rolled in C, don't you?

Re:I like GOTO!

[stonecypher]

I mean hell, there are a lot of C++ programmers out there which think that running out of RAM isn't a good enough reason to throw an exception, hence (nothrow) new.

The logic behind this: If there isn't enough ram to perform an allocation, what makes you think there is enough to allocate for an exception? If the exception can fit in ram, great, you can handle the condition gracefully. If it can't, you would never get an opportunity to handle it gracefully. If you try to handle it both ways (throw if you can, return NULL if you can't) you just made your code twice as complicated for no reason.

Uh, sorry. It's been common practice for about 20 years to allocate a small block of emergency RAM on the start of a program, then to release it on catching bad_alloc to give some space to work with, or alternately to pre-allocate the space for a bad_alloc exception. Remember back in the day when DOS programs would warn you to kill TSRs because you were running low on memory? C has never had any mechanism to determine the amount of remaining memory, and neither did DOS; how do you think that was accomplished? (Answer: they pre-allocated a block of 32k or so, released it when things got tight, and displayed a near-panic message.)

The real logic behind nothrow new is threefold.

First is that C/C++ are hardcore portable languages, and it is frequently the case that efficient implementation either requires missing hardware support such as interrupts - which exceptions are not required to be implemented through - or when the existing operating system wants exceptions to be thrown through it, typical of single-process multithreading embedded OSes like PalmOS and the suspected operating systems underlying the Nintendo DS and Sony PSP. In those cases, the exception system shouldn't be built in at all, and that C/C++ allow this to be removed is what allow developers for devices like that to have access to modern high level languages.

Second is that C/C++ is intended to support industrial and military caliber development and use, which introduces huge reliability, uptime and realtime considerations. Exceptions are a safe general mechanism for machine error handling, but when you're controlling a nuke, a medical imager, a construction crane or a satellite, you have very specific new error and exception handling needs, and no generic mechanism will ever suit you. Furthermore the way in which C/C++ exceptions are implemented makes realtime programming sickeningly difficult; it's possible, but damned hard, and it's often easier to replace the nightmare situation code than to hand-comb everything else, especially considering that failing in an existing exception situation is frequently less costly than failing in normal situations. By comparison, commercial development for closed platforms often sees large returns from hooking device error handling hardware up to language error handling mechanisms in that their clients have dramatically simplified problem behavior and can therefore develop that much cheaper. In both the cases of high-reliability and ease-of-sealed-deployment, removing the exception code entirely is frequently a big financial win - and more than occasionally a prerequisite - for using the language in that situation.

Third, the most common, and the viewpoint to which I was referring, is that running out of RAM is simply not an exceptional situation, and that therefore it should not be handled through exception mechanisms. Most of these programmers are commercial programmers from the days when a machine with four meg of RAM was considered well-equipped, and are therefore used to applications actually running out of RAM. It's easy to handle, and there's just no need to throw yourself into application panic. You wouldn't call UNIX panic over running out of RAM, would you?

In general, one isn't worried about recovering gracefully from exceptions. This is why I think your home language isn't C++ - and this isn't a jab at you using the language fr

Re:I like GOTO!

[stonecypher]

Meh. Most Delphi nuts don't know anything about the history of their language, much like Visual Basic people are often appalled to learn about GOTO and line numbers.

But yeah, I was just nitpicking. ;)

Re:I like GOTO!

[Baki]

For cases where you have to free resources, use try/finally. As far as memory is concerned: nowadays we have garbage collectors :). Even though Java is lacking in some respects compared to C++, garbage collection is a huge plus and but for the most low level tasks, having to deal with memory is insane.

I've used C++ for 10 and C for over 15 years (a.o. in embedded and hard real-time applications), so I have had my deal of manual memory management.

Btw you can ease the pain in C++ if you write decent destructors, and as a rule allocate memory and class instances inside methods on the stack instead of on the heap as you did in your examples.

Re:I like GOTO!

[top_down]

It never ceases to amaze me how deeply people believe that one cannot have an OO model, including destructors, without language support.

That is indeed amazing given that every C advocate around will repeat this over and over again.

You do realize that C++ was originally rolled in C, don't you?

How can I miss it when every C advocate around will repeat this over and over again. But of course it doesn't help your argument as you don't need automatic destructors to implement automatic destructors.

Just show us some code dude.

Re:I like GOTO!

[Keeper]

MFC doesn't use SEH (at least, it doesn't to my knowledge). SEH is a compiler extension that gives you lower-level access to the exception mechanism provided by Windows; something similar may exist for other platforms, but I haven't cared enough to find out.

SEH gives you a lot more flexability; the major things people use it for would include:
1) the ability to catch 'hardware' exceptions (divide by zero, access violation, etc)
2) the ability to have complicated logic in the 'catch' filter
3) access to the exception record (which contains details about the exception and any parameters for the exception that may be present)
4) access to the context record (which allows you to do things like saving a minidump and writing out a stacktrace for the exception)
5) do nifty things to the exception objects before passing them to handlers

Under the hood, the compiler translates the try/catch blocks into the same primitives you have access to via SEH.

There certainly isn't anything wrong with using exceptions. There are lots of ways to manage the sort of problem I originally described -- all of them work, and all of them have their various pros and cons. That being said, I've yet to see something that works as well as maintaining a single exit point paired with the use of a goto-on-error statement.

When I write code, one of my primary objectives is maintainability and obviousness. I hate having to fix bugs that other people introduce because they didn't realize the full implications of the change they had made. And I hate having to take lots of time bringing a new hire up to speed on how something works. Most other solutions cause either bugs due to un-realized complexity, or require lots of mentoring time to describe. If I can avoid all of that through the use of a goto, I'm all over it.

Re:I like GOTO!

[Keeper]

If you often have code that needs to do 'cleanups' _and_ needs to check many sequential possible error conditions, such that a couple of "if(!failed) {}" sets make your function unreadable, you should probably consider splitting your function and/or rethink your resource allocations.

If you ever do any programming using COM, you'd realize how impracticle that is. Every call you make has a success or failure result to it. Everyone one of those results must always be checked for failure. Following your logic would require a nested if statement for each function call made. Each time you make a call that returns an object, you have to make sure it gets released before returning (otherwise you leak a reference, and thus the object). Believe me when I say you do not want to manage that code with nested if statements.

Remember, the "nest" of gotos always goes down, and they all hit the same point. And the name of the label is (almost always) the same. It is incredibly easy to follow.

Re:I like GOTO!

[Keeper]

There are many forms of expected errors that can occur; I was listing some very obvious ones that anyone could relate to. An expected error is anything that "failed", but the failure was not entirely unexpected.

Putting resources in classes doesn't always work, especially when resources need to be released in a specific order or when the process used to destroy a resource has unavoidable side effects (the most common example I can think of here is where destruction of a resource overwrites some global data).

The way exceptions work under the hood is not well understood by most people. You don't incur any cost for checking the exception unless the exception is actually thrown. However, you do incur a cost in registering and unregistering exception handlers each time you enter/leave a try block. This is substaintially more costly than just an if statement, but it isn't horribly expensive in its own right. It does, however, add up. If you were to use exceptions the 'proper' way (ie: get rid of pass/fail return codes, and always throw on error), your code would be noticably slower.

The primary cost of using exceptions in C++ is the actual throw. This is why returning values indicating success or failure is still so popular in C++. It isn't nearly as big of a deal in other languages, but the implementation in C++ leaves a bit to be desired...

Re:I like GOTO!

[Keeper]

Ugh, I swear I'm having the same conversation like 50 times. :p

RAII is great until you need to release resources in a deterministic order, or until the act of releasing a resource has a side effect.

In this particular usage example, it is very easy to reason where the code goes -- it always goes down, and it always hits a label at the end of the function that exists right before all of the method level cleanup occurs.

I typically see SEH used when asynchronous exception handling semantics are required or when lower-level access to exception information is required. I think that newer compilers support handling both synchronous and asychronous exceptions now, so that may no longer be as much of a concern.

I'm pretty hardcore in my use of exceptions; I generally only throw them when the app is in a state that can't be recovered from. A wide range of personal experience has directed me to that position (from bugs in compilers, bugs in designs, to bugs in people).

Re:I like GOTO!

[Keeper]

C++ doesn't have the concept of finally.

Additionally, there are plenty of occasions where you don't have a choice allocating a resource on the heap or on the stack (because the resource may exist on neither the heap or the stack; ex: handles, critical sections, ref counted objects, and the like).

If you're like everyone else who has replied to me after I raise the above point, you'll mention that RAII solves all of those problems; to which I'll reply it doesn't when the order releasing resources is important, or when releasing a resource has an undesirable side effect.

Re:I like GOTO!

[Keeper]

That has got to be the best flame I've seen in a long time. It has all the classics -- a long history lesson, many implications about my lack of knowledge or how much of an idiot I must be, a you're wrong even though you agree with me statement, and even an attack on grammar.

Bravo.

Re:I like GOTO!

[VonKruel]

YES! It's good to hear someone else say that!!

I have used goto _occasionally_ (but I never inhaled(compiled?) ;) Seriously -- I fully agree it does make sense in some cases. In a couple hundred thousand lines of C++ code I've probably used goto less than 10 times, and in each case I used it because the resulting code was _more_ readable for it. goto is not the devil - those sons of bitches who abuse goto are the ones who are the ball lickers :)

Re:I like GOTO!

[Anonymous Coward]

More and more languages support named continue/break statements. Don't remember if gcc supported it yet.

Uh, right, yeah, because GCC is a language?

Re:I like GOTO!

[Peter La Casse]

Exceptions were only mentioned in one or two posts; the theme of the conversation is that goto "is also exceedingly useful for error handling, in that it allows you to skip the bulk of a function and still hit the cleanup section of the function."

Somebody suggested that that's what exception handling is for, but C doesn't have exception handling, so the conversation is clearly not about exceptions.

Re:I like GOTO!

[jelle]

'Remember, the "nest" of gotos always goes down, and they all hit the same point. And the name of the label is (almost always) the same.'

Sounds survivable, as long as it stays like that, and the jumps never cross, and it doesn't turn into a 'ladder' of jumps.

Either way, I haven't needed goto's in years.

Re:I like GOTO!

[Keeper]

To me, the conversion has been "you should use xyz instead of gotos", not that "xzy is also useful in this case." Perhaps I'm being overly defensive while reading ...

Re:I like GOTO!

[Anonymous Coward]

What you've discovered here is called "lazy evaluation" or "short circuit evaluation".

e.g. in the expression X && Y, if X is false, then the expression cannot possibly be true, regardless of Y, so there is no need to evaluate Y. Likewise, in the expression X || Y, if X is true, then the whole expression must be true, so there is no need to evaluate Y.

This behaviour is part of the C/C++ language specifications, so it should be quite safe: if you manage to find a platform or optimization setting that does not exhibit this behaviour, then one the following has happened a) you've found a bug in the compiler, b) the C/C++ compiler you're using is some non-standard dialect, or c) && and/or || have been overloaded somewhere (NOT recommended, precicely for this reason, but you can guarantee somebody somewhere will do it without realising the consequences).

Lazy evaluation of boolean logic operators is common in many other languages: Python, Java, JavaScript, PHP, most BASICs, TCL, even on the BASH command line...

So I wouldn't worry about those compiler/platform tests -- it's a commonplace behaviour, not some dirty trick.

Some languages (notably functional languages) take this concept to a whole new level called "delayed evaluation" where entire expressions are not evaluated even when bound to a variable. Only when the result of the expression is actually used does the evaluation ever take place.

It's not considered in the context of OOP

[ravenspear]

Because OOP purists would mysteriously erupt in convulsive fits mixed with violent outbursts of anger resembling a sex crazed bigfoot/unicorn hybrid if you actually used a GOTO statement while writing OOP code.

Re:It's not considered in the context of OOP

[Jace of Fuse!]

So is that Bigcorn or Unifoot?

Re:It's not considered in the context of OOP

[Anonymous Coward]

Frank? Is that you? I said I was sorry. Hope you get better soon.

GG

best tool for the task

[sfcat]

I like OO but is isn't great for every task. For instance, logging (which is the default example for AOP) is really bad in OO. This is because you have to add something like

Log.printLog("some message " + someObject.toString());

everywhere you want to log something. But with AOP you can used kleen operators (*, +, ?, etc) to add Log.printLog() to certain methods of certain objects. Aspects allow you to inject code into method call boundaries. But like all programming constructs it can be abused. This is because you might get an exception stack trace that indicates a specific method call has thrown an exception when the exception came from code inserted by an aspect. But other languages can be abused too (Perl anyone). So I think this type of critism of aspects says more about the critic than about the programming construct. I don't use C++ to implement logic evaluators (I would use Prolog or another logic or unification based language). Nor do I try to write OO code in LISP (despite the horrid OO extensions for LISP) because each language has it strengths and weaknesses. For each application choose the language that best suites the task.

On another note, I think these types of critisms are really from people who are afraid of learning new languages or skills. They have worked long and hard to get good at C (or Java or some other language) and don't want to have to learn another language. Well suck it up, there aren't many Fortran programmers anymore and if you want to keep working, you must keep learning new languages and skills. Not that you should jump on every bandwagon, but if I'm writing something that needs to be really, really fast I use C. If I'm writing something that needs to be maintainable forever and speed isn't that important I use Java. The best tool for the task.

Re:best tool for the task

[God! Awful 2]

I like OO but is isn't great for every task. For instance, logging (which is the default example for AOP) is really bad in OO. This is because you have to add something like

Log.printLog("some message " + someObject.toString());

not:

Log "some message " someObject endl;

???

-a

Re:best tool for the task

[God! Awful 2]

Uhh...

Log << "some message " << someObject << endl;

Re:best tool for the task

[Anonymous Coward]

This is because you might get an exception stack trace that indicates a specific method call has thrown an exception when the exception came from code inserted by an aspect.

I can see some problematic aspects to AOP, but frankly this particular example sounds to me more like a problem with inadequate tool support than with the AOP concept itself.

Re:best tool for the task

[AuMatar]

1)Only C++ uses like that. Not all language are C++
2)Even in C++ a lot of people avoid that usage. Its an example of everything thats wrong with operator overloading. ab means left shift a by b bits. Overriding it to now mean write to a stream is a horrible and confusing idea. Would you override + to mean something totally different than addition?

Re:best tool for the task

[Trejkaz]

But what does AOP solve in that logging scenario? As far as I can tell, it lets you change this:

Log.log("Something went wrong!");

Into this:

log("Something went wrong!");

Four less characters, whoop-di-shit.

And that's not even going into the fact that static import brings exactly the same benefit.

Re:best tool for the task

[Anonymous Coward]

"sure"+"whynot"

Re:best tool for the task

[Anonymous Coward]

AOP lets you define various side effects and entry/exit conditions for any operation, including primitive operators.

As a contrived example, you could technically set an entry-condition that checks the denominator for division and logs before attempting to divide by zero.

In another contrived example, you could acquire a semaphore in the entry condition for modifying a certain primitive type (and release in the exit condition).

Re:best tool for the task

[AuMatar]

Ok, slashdot messed up the formatting on 2. It should read:

"a << b means left shift a by b bits"

Re:best tool for the task

[m50d]

The problem is too many people do jump on every bandwagon. I think that's what the author is warning of. AOP is not a panacea and shouldn't be seen as one.

Re:best tool for the task

[Bodrius]

Funny, this is not the first time I heard of this complaint and, for example, I wouldn't think Anders Hejlsberg was afraid of learning a new language feature considering his career... (the question on AOP is asked within the first two mins if you don't want to watch the whole thing).

The concern predates the report for quite a bit, and from some reliable sources. This is not a surprise, as I would think the role of companies like forrester is to communicate trends like these, not to create them out of the blue.

You are right, programmers should choose the best tool for the task. But an issue with AOP as commonly proposed is that you can use the wrong tool and do the wrong task whether you choose it or not, because the weaving is not happening on your request (pointcut), but on the aspect's (advice).

Depending on the approach of the AOP framework this could be a risk at the team level (static weaving), or at the user level (dynamic weaving) because keeping track of all the aspects introduced by other people in your code is hard/impossible.

AOP based on declarative annotations could help a lot, but for dynamic weaving (which still can be extremely useful) the main problem doesn't go away.

Maybe providing limitations to the semantics of an aspect (in terms of invariants it must keep) would be a solution, but that would limit AOP to a non-general programming model, and for that we would have to define the classes of problems where it may be 'useful' or 'harmful', or provide a general way to define these limitations by the application (since we assume they are domain-specific).

In any case, this does not seem to me like the kind of criticism coming from people afraid of a "new thing".

Rather, it seems the kind of criticism a new technology faces when applied to 'real world' problems and projects, which is a good sign that AOP is taken seriously enough by mainstream development teams, and that there will be people working on solutions to these problems.

Re:best tool for the task

[AigariusDebian]

Not really. AOP allows you decide in runtime if you want to change:

a.setvalue( 'bar', 'foo' );

to

if (perms.check( a, 'setvalue', username, srcip))
a.setvalue( 'bar', 'foo' )
else
log.alert('Access control violation!', ......);

or to

log.debug( "doing a.setvalue( 'bar', 'foo' )" );
a.setvalue( 'bar', 'foo' )

Imagine a running application that you load a debug aspect into in the runtime and it starts giving you heaps of debug output. Then you modify the debug aspect and reload it for some other debug info. And all of thet is possible without stopping the porgramm in question (if you use runtime crossweaving).
And even with compile time crossweawing you can easily change debug or authentification settings of the whole 200 Mb app by editing one aspect. By adding just a few lines you can add debugging to any object or function.

Re:best tool for the task

[Nicolas MONNET]

Ah stop the crap over overloading. Yeah, it's not always a good idea. But hell, it's more readable in that case. Much more so than Java.

Re:best tool for the task

[Trejkaz]

My objection is that these things can both be done using a Decorator pattern, and the Decorator pattern doesn't make your code so hard to debug when errors do occur.

Re:best tool for the task

[Trejkaz]

But logging at the start and end of methods is completely useless. I want logging in the middle, with information other than what method is being called... basically it should provide what the existing logging provides, otherwise it hasn't solved anything.

Re:best tool for the task

[Hast]

Personally I don't think so.

Log.println("Some mess " + obj);

Doesn't seem less readable IMHO than

LOG << "Some mess " << obj << ENDL;

(Note that at least Java will automatically call the toString() method when you print() an object. Good to know for debugging.)

That's just what I think, I'm not really bothered with the overloading personally. I just think it's turning your println into Perl (ie unreadable lines of non-alphanum characters).

Re:best tool for the task

[Anonymous Coward]

Java uses + to mean string concatenation. Next?

Re:best tool for the task

[10am-bedtime]

if you don't try to write OO code in lisp, how do you know it cannot be done (and done well)?

hint: AOP is just half-assed CLOS.

(no worries, i don't use any of this stuff, either. ;-)

Re:best tool for the task

[pkhuong]

You lost your credibility when you wrote: "Nor do I try to write OO code in LISP (despite the horrid OO extensions for LISP) because each language has it strengths and weaknesses." Given that Common Lisp is actually CLOS, an object-oriented language (one of the first ones, and one that has been called one of the few real OO language by Kay), I find it difficult to consider the standard as an "horrid extension".

I think that, a priori, we should read criticism as an opportunity to improve concepts, not merely dismiss them. The "each language has its strengths and weaknesses" PoV, while often true, makes it easy to fall into a trap where each language or concept evolves in a vacuum, instead of becoming better and unifying concepts together by generalisation.

Re:best tool for the task

[maraist]

It's very rare that java code at least doesn't call a million functions to perform even the most basic operations.. Want to iterate over a collection.. Most likely you use collections instead of arrays anymore for EVERYTHING.. Why? because there are a million tools which enhance collections, filters, queries, dynamic expansion/contraction, nice default toString capability, arbitrary nesting, etc. So if what you're trying to do is print something in a while loop, you can custom taylor your aspect to capture the exact looping point.

Likewise with the dozens of other "no-function-is-larger-than-a-screen" operations. If you want a logging point, make sure you throw it into a method.

Ok, what about the overhead of calling functions in loops.. Got you covered, it's called JIT. Performance is no longer the reason to use C over VM's. A good C compiler might not know the optimal time to inline code verses leave functions separate. But a JIT can.. Sure it'll take many iterations to figure it out.

This applies to aspects as well. Even though you're adding large amounts of code each each method (entry/exit points), it's likely that the most commonly used points will be inlined, re-arranged for optimal execution, etc.

That being said, I haven't been happy with using aspects for anything that directly affects functionality.. So the example of grabbing a semephor would make me ill.. In a previous life, we used aspects as a security model.. Every method invocation of a certain category had it's returned contents acess-control-restricted. The problem was that functionality started relying on it. We wouldn't redundantly check for things, but that meant that there was magic in the code.. We justified it by saying that we're effectively segregating the database.. You physically can't get to data that you don't directly or indirectly own, so you can simplify your programming assuming that you have access to everything. Of coures this doesn't translate into SQL calls that return counts, and what-have you, so the limitations creapt up too often..

But logging has no direct affect on an application. Statistics gathering, or run-time debugging of hard-to-reach code. Trace-paths. Possibly even event generators. Things that at the very least don't affect the operation of what a class logically wants to do or provide. Afterall most event generators are hidden from the general work-flow. They have internal fireXEvent, and side-interfaces which expose registerX or what-have-you.

That being said, current AOP adoption is too shaky.. Either you have to manually wrap objects with proxies, or you have to run a post-compiler, which plays havoc with other post-compilers (like cactus).. You can only really safely have one post compiler, and so you should probably have no post-compilers; it's a broken concept. Something like jboss with it's class-loader runtime bytecode enhancement is cool, but not everybody wants to run under jboss.

So unless the language itself adopts it, I'm not a huge fan of AOP right now.

Re:best tool for the task

[stonecypher]

Your logging example is easily implemented in typical OO languages as the visitor pattern.

On another note, I think these types of critisms are really from people who are afraid of learning new languages or skills.

Curious, considering the criticism you levelled in response.

Re:best tool for the task

[NoOneInParticular]

Would you override + to mean something totally different than addition?

If you were to design a language that doesn't allow operator overloading *cough* java *cough*, you sure as hell would:

String str = "" + a + b;

Where a and b are arbitrary objects (not necessarily strings), so you've got auto-casting to boot! Actually, most languages overload addition to mean string concatenation as well, so what was the point about '+'?

Re:best tool for the task

[Minna Kirai]

ab means left shift a by b bits. Overriding it to now mean write to a stream is a horrible and confusing idea.

Yeah, because when I saw cout << "hello" I naturally assumed it was trying to shift the standard input file handle left by hello bits.

Give it up, C++ is 15 years old, and << has meant "write to a stream" for that entire time.

Saying that operator overloading shouldn't be used because the function's behavior might not be like the symbol's traditional meaning is the same as saying I shouldn't be allowed to name my own functions, because I might call something a fake description.

Re:best tool for the task

[Nicolas MONNET]

Congratulations, you suck at Java!

No, seriously. The first line you wrote creates an intermediate "String" object, and thus wastes heap space (and leads to quicker GC).

A strictly equivalent program would take 2 lines.

Re:best tool for the task

[Hast]

*Sigh*. Kids should be quiet when adults talk.

Sure you could use StringBuffers instead but that hardly matters does it? It certainly doesn't for demonstrative purposes. Besides only really evil people optimise their program early.

I guess you're just angry because I proved you wrong though. But that's ok, when you grow up you'll learn to handle disappointments in a more adult manner.

Re:best tool for the task

[Nicolas MONNET]

This is not an early optimisation; this is exactly the cause for many Java programs sucking and sucking up memory. If you do that often -- and, duh, logging happens often, -- you're going to trash the heap quickly.

$250 to read the article

[LadyLucky]

What the submitter failed to mention is that to read this article you have to stump up with $250. The comment in the submission is merely from the executive summary.

'It's worth it'. Come on, how many people here read the article, let alone will pay $250 for it?

Re:$250 to read the article

[Dachannien]

It's likely that the OP'er works for or attends an institution which has a site license for Forrester's content, and so they were able to read the article for free. It probably didn't even occur to them that other people wouldn't be able to access the article. The same thing happens when people link to scientific journals in their /. submissions.

Re:$250 to read the article

[Anonymous Coward]

But can this be considered proof that the editors did not read the article either?

Re:$250 to read the article

[KiloByte]

No. The whole concept has a merit, and it works. You're just missing what it is.

It's not a viable programming technique, but it's a viable method for siphoning money into their account. And as thus, a valid business method.

Re:$250 to read the article

[Anonymous Coward]

I don't think there's any more proof of that particular fact required.

They should really have their job titles renamed. Editors my fucking arse.

Buy this document? 249.00???

[the-build-chicken]

Two fifty to hear some twat tell you that a new technology is good, but only in the right circumstances used by trained people.

What bollocks.

Do any CIOs still buy this crap? Do the sensationalist headlines do the job and actually sell this bs? "AOP considered harmful"...be afraid...be very afraid!

I personally don't have a week go by when we don't find another great use for AOP...and we write financial apps...so that blows his 'frameworks only' theory out of the water.

But I suppose "AOP, useful sometimes in the right circumstances if you make sure you train your people on how to use it, not so useful in others" doesn't exactly sell those $250 a pop articles, does it Carl

Re:Reminds me of my teen years

[Anonymous Coward]

Boring. The real hackers used 10 ? "FUCK YOU",

$249 to buy this 5-page "Research"?

[Anonymous Coward]

$249

Patented

[matria]

Looks to me like the most harmful part of it is that it's patented, or at least parts of it are.

Re:Patented

[matria]

Patent here

Re:Patented

[Anonymous Coward]

It's sickening that a programming METHOD can be patented. That's like patenting a method of composing music...

But....

[ICECommander]

I always thought GOTO was good: 10 PRINT "BASIC PWNZ" 20 GOTO 10 30 REM HAHA SUCKERS!

Re:But....

[The Amazing Fish Boy]

I always thought \r\n was good.

Oh yeah. It definitely is.

A little annoying....

[Anonymous Coward]

...that you can't read the article. I guess it's lucky the reviewer posted a link to a simalar paper - but annoying none the less.

next article

[my_haz]

AOP Geeks Healthier Than You Thought

AOP shortcomings vs benefits

[Anonymous Coward]

There has been a lot of buzz and hype in the Java community about AOP in the recent years.

I, personally, agree that AOP shortcomings outweight its benefits at this time. AOP requires steep learning curve, makes debugging more difficult (can't easily use it with Java debuggers that are available), reduces code readability and, overall, does more harm than good.

Considering all the hype around AOP I'm sure it will prove itself in a couple of years as useful as EJBs now, i.e. hardly useful at all.

Wow...

[threaded]

Couldn't you like plug a load of them together and make like a beowulf cluster of them.

RTFA

[NitsujTPU]

Oh, wait, don't RTFA... it's probably not worth the $250 ($50/page) price tag to you.

Re:RTFA

[Anonymous Coward]

Where are the karma-whores when we need them. Come on, $250 is a small price to get the chance to post the article here and get some karma.

I happen to LIKE C++!

[n0nsensical]

You insensitive clod!

Re:AOP?!

[aichpvee]

Yeah, you really got your head around this one, slugger. AOP is definitely only for Java.

Side effects++

[evvk]

The bad thing about AOP is that it adds lots of side effects to function calls and can thus make the program very hard to reason about. This is completely orthogonal to (purely) functional programming that intends to remove side effects thus making it easier to reason about programs.

Functional programming: f(1) == f(1) always, with no other effects to "global state" etc.

Imperative programming without AOP: f(1) != f(1) necessarily at every point of the code, as the function can access globals. It can also change the global state, so its effect is more than returning its value; it can have side effets.

Imperative programming with AOP: Same as above, plus the side effects may happen somewhere unrelated to the definition of f itself.

Re:Side effects++

[Tyler Eaves]

Of course, a PURELY functional language is worthless for real world use. Even languages that are usually considered pure funtional like haskell have some sort of 'cheat' to allow changing the global state.

Re:Side effects++

[evvk]

It may seem like a cheat at first sight, but the haskell approach to IO/global state is really elegant infact, and stays within the boundaries of a purely functional language. Most other functional programming languages do use a cheat, and are thus impure (and strict instead of lazy).

What haskell infact lets you do with its IO monad is construct instructions for a separate IO interpreter (that is not pure) within the Haskell runtime. It is a kind of DSL (domain-specific language), a concept that is used a lot in Haskell programs.

What the type signature

putStr :: String -> IO ()

can be interpreted to mean is that putStr is a function that given a string returns instructions for IO interpreter on how to print it out, without returning other value (()=void).

Re:Side effects++

[gbarta]

This is not true at all. It is true that AOP as implemented in OOP evironments (e.g. AspectJ in Java) is usually used to add side-effects to existing code, but that is just because side-effects are the most common way of doing things in OO programs.

If AOP was to be implemented in a pure functional evironment, then it would not require side-effects.

For example, if the original code had a function call like this:
foo( bar(1), 2, 3)
then the aspect could modify the function call to be:
foo( 2, bar(1), 3)
or whatever, no side effects required.
If side-effects were to be used, then monads could be employed as per a pure FP approach.

AOP is about providing flexibility in where logic exists in the source code (in fact potentially you do not even need the source code), so that if you want to change the behaviour of a function/method then you do not have to actually modify the definition of that function/method. It has no requirement to employ any programming style, imperative, OO, or otherwise.

Re:Side effects++

[evvk]

The whole point of AOP is arbitrary uncontrolled side effects: the standard logging examples etc. Composing a function with an "aspect" that only modifies the parameters or value is pointless and is not going to work with multiple "aspects".

At the monadic level, many uses of AOP are more controllably implemented with HOFs and monad transformers. This obviously doesn't allow arbitrary aspects, but that's the point of doing it this way.

Re:Side effects++

[gbarta]

The whole point of AOP is to provide a means of modularisation for code that is logically related but would otherwise be sprinkled all over the code-base.

Most of the standard examples heavily employ side effects, because they are being used in the context of imperative programs.

AOP was originally invented in a LISP environment and while LISP is not as pure as Haskell etc, many of the original LISP examples are much more in an FP style than an imperative one.

There is huge scope for modifying the behaviour of a functional program by changing the arguments passed to functions. It is limited only by your imagination.

Having multiple aspects operation of a single area (join point in AOP speak) does indeed add complications, but these compilications are easily handled (e.g. by defining priorities for order-of-application) in an imperative/OOP environment, and I cannot see why a functional environment would be any different.

A functional language does have a richer set of tools for solving these kinds of problems, making AOP perhaps less appealing for functional languages, but that does not imply that AOP has to be inherently 'unclean' from a functional point of view.

Re:Side effects++

[keesh]

It's a nice theoretical concept but a real pain in the ass to work with. Sure, Haskell is nice as a compsci masturbation language, but coding real projects in it is a task for lunatics.

Re:Side effects++

[Anonymous Coward]

If AOP was to be implemented in a pure functional evironment, then it would not require side-effects.

For example, if the original code had a function call like this:
foo( bar(1), 2, 3)
then the aspect could modify the function call to be:
foo( 2, bar(1), 3)

Sounds like an underpowered, watered-down version of Lisp Macros.

Re:Side effects++

[Anonymous Coward]

Functional programming: f(1) == f(1) always, with no other effects to "global state" etc.

Also makes a lot of stuff computable at compile-time. :-D

Joke, Hoax or Troll? All of the above?

[Anonymous Coward]

The article, links and topic are ludicrous. Essentially crapflooding by the editors.

10 GOTO 10

[John Bokma]

GOTO doesn't cause harm (or its syntax sugared grandchildren), it's the programmer who is not able to understand when to use it or not. Such programmers are a harm by themselves :-)

Re:10 GOTO 10

[Anonymous Coward]

GOTO hasn't really gone away, it's just that we have lots of new versions of it which help manage the spaghetti code problem by introducing "typed" GOTOs (OK, the language lawyer in me cringes, but it's an interesting idea).

Anyway, just think of the usual break/continue operations you find in most C-style languages. Those are basically just restricted forms of GOTO, which let you do pretty much just as much evil, but in a more structured way.

GOTO probably wouldn't be so maligned if it were only good for, say, jumping to blocks right before a return, the usual case where it's used properly (in plain C, anyway, other languages have fancier mechanisms for doing the same thing cleanly).

Re:10 GOTO 10

[maxwell demon]

Well, real fun is if GOTO can go to a computed line number. And when I say "computed" I don't mean selecting from a list of line numbers given as an explicit list in the source code. The ZX Spectrum for example IIRC allowed code like the following:

10 PRINT "Please enter line number to continue at."
20 INPUT a
30 GO TO a

Re:10 GOTO 10

[Anonymous Coward]

And it is professional to always assume that such a "programmer who is not able to understand " your code might be the only available resource somewhere down the road.

Most gurus I worked with are totally unable to write code easy to understand for the "junior newcomer starting with maintenance tasks", not because they can't, but because they refuse since it is "too boring" or worst, for job security.

You can never predict what a mess someone else will make in your code a few years down. A few easy steps (like avoiding GOTO) can make things better for coders and save a LOT of money to the business.

Unfortunately the way businesses treats workers lately (mainly with fast layoff policies and outsourcing) pushed coders to say "Why should I care if that Indian guy who will maintain my perfectly working project has a hard time changing features?"

Re:Buy this document? 249.00???

[Anonymous Coward]

I think they meant AOR is considered harmful.

To anybody with any kind of musical taste.

It just ended up on Slashdot by accident...

Re:AOP?!

[sv0f]

OP is not specific to Java -- I've seen it done with Python

And it was invented by Kizcales working in Common Lisp. For example, see this brief history.

Those [like the grandparent] who do not know history...

Re:Reminds me of my teen years

[Fjornir]

C:\>copy con autoexec.bat
@echo off
echo ^G^GSYSTEM ERROR
autoexec.bat
^Z
1 file(s) copied.
C:\>copy con t.bat
echo Fuck you.
t.bat
^Z
1 file(s) copied.
C:\>t.bat

Frankly there ought to be more goto in C

[Julian Morrison]

The absence of "goto myfunc(param);" makes implementing coroutines or tail calls un-necessarily hard when using C (or compiling to C). There is no valid reason for a very-low-level language to hide features available from assembler.

Article is FUD against Common Lisp which has AOP

[Anonymous Coward]

Common Lisp is the only language that has clean transparent implementations of AOP. Trying to do AOP in Java or C# is a waste of effort. but in CL it's truly transparent and easy.

This article is part of an early FUD PR campaign by a large software company on the west coast, which fears the rise of CL among developers.

Re:AOP?!

[Anonymous Coward]

AOP can be used for great evil, but it can also be used for great good. When I first read up on it, my first reaction was "wow! This must be how God programs!" :)

And that explains why he created Humans...:)

C--

[tepples]

The absence of "goto myfunc(param);" makes implementing coroutines or tail calls un-necessarily hard when using C (or compiling to C).

If your C compiler does not optimize obvious tail calls (e.g. return myfunc(param);), then your C compiler has a bug.

There is no valid reason for a very-low-level language to hide features available from assembler.

C is not a very low level language. You're thinking of C--.

That's ok.

[Some Random Username]

Some people pay hookers to take cheese graters to their johnsons, so you are in good company.

Re:That's ok.

[Anonymous Coward]

This was significantly more information than required.

Re:That's ok.

[Anonymous Coward]

Some people pay hookers to take cheese graters to their johnsons, so you are in good company.


A friend of mine was wondering, how much would that set me back? I mean, how much would that set my friend back?

Re:Article is FUD against Common Lisp which has AO

[Anonymous Coward]

You mean Microsoft?

DSL?

[tepples]

What haskell infact lets you do with its IO monad is construct instructions for a separate IO interpreter (that is not pure) within the Haskell runtime. It is a kind of DSL (domain-specific language), a concept that is used a lot in Haskell programs.

Then what are the impure languages? Dial-up?

For those unfamiliar with OpenOME.

[Anonymous Coward]

http://www.cs.toronto.edu/~yijun/OpenOME.html/inde x.html

"OpenOME, a goal-/agent-/aspect-oriented requirements engineering tool
The Organization Modelling Environment (OME) is a general, goal-oriented and/or agent-oriented modeling and analysis tool. It provides users with a graphical interface to develop models, and supports access to a powerful knowledge base that allows for sophisticated computer-aided analysis. This tool is intended to provide software developers with a clear link between the requirements, specification and architectural design phases of development. Attention is also being placed on this use of this tool in business process reengineering."

I'm FREAKING OUT!

[sllim]

My neighbor is an Aspect Oriented Programmer!
What about my 3 year old?
Is he gonna come down with cancer?
Should I move?
Is there a list that shows where these people live?
Can they be tracked by satelites?

Forrester is just another clueless IT consultancy

[tyates]

The big IT consultancies like Forrestor, Meta, gartner, etc are intellectually bankrupt. If you want an example, read the free article off of Forrestor's web page on IT metrics. It's absolutely worthless. Believe it not, it says that you should evaluate your IT department based on a balanced scorecard that is calculated by, among other things, the number of steering commitee meetings you have. Yes, you read that right, the more meetings the better your department is.
These consultancies ran out of ideas a long time ago, and are trying to turn IT ito some Six Sigma pseudo-science. It doesn't work, but idiots still buy into it because it sounds impressive.

Method call boundaries??

[Anonymous Coward]

"But with AOP you can used kleen operators (*, +, ?, etc) to add Log.printLog() to certain methods of certain objects. Aspects allow you to inject code into method call boundaries."

And what if I want to add log statement somewhere in the middle of the method? And with some arbitrary objects? Logging only method call boundaries is pretty much useless.

All AOP examples I've seen deal mostly with loggind and transactions maangement (again within method boundaries). That's a good testament, IMO, of how useful AOP is.

$50 per copied page???

[po8]

How do I get suckers^H^H^H^H^H^H^Hfolks to pay $250 for my 5 page speculations on computer science topics? Seriously. I'm an academic, and I write 20+ pages per month of this stuff for free. If I could get even 100 people to pay $50 per page each for it, that would be $100K per month: that's way more than I make in a year at my current job. Leaving aside the question of the price of my immortal soul, it doesn't sound like too bad a gig.

I started to list my qualifications, but got tired of typing. Suffice it to say that they're way more than that Forrester guy has. Let me know folks: if 100 of you pay me $50 per page each, I'll research pretty much whatever you want.

Re:$50 per copied page???

[Anonymous Coward]

Perhaps you should point some of your energy and intelligence in the fields of marketing and production.

You know, those professions that you probably talk shit about on a weekly basis.

The ivory tower is protection, but is also isolation.

The real threat

[Anonymous Coward]

Is GOP*: Globals Oriented Programming.

*No relation to a certain political party. No, really.

classic newbie blunder

[Anonymous Coward]

You've attempted to assign C++ to a complex left-hand-side expression (GOTO+OOP). This is a classic blunder. What you probably meant was: "GOTO"+"OOP" == "C++".

In addition, you're overloading the use of strings to have orthogonal meanings, which is frowned upon. After all, using the standard string operator overloading, your left-hand-side "GOTO"+"OOP" is simply "GOTOOOP", which is clearly not equal to "C++" -- a good comment compiler would notify you that this expression always evaluates to false. A further refinement would be to introduce your own class and write the expression as:
LanguageFeature("GOTO")+LanguageFeature("OOP") == LanguageFeature("C++").

In the future, I hope slashdot will provide a better comment compiler that can automatically detect such simple mistakes.

Re:classic newbie blunder

[Anonymous Coward]

> "GOTO"+"OOP" is simply "GOTOOOP", which is clearly
> not equal to "C++"

Yes but you forgot that in C++ you can redefine the + operator[1] so that all restaurants are Taco Bell[2] and all summations are equal to "C++".

--
[1] A string class is required
[2] Thank goodness there's diversity in restaurant and language choices.

Re:classic newbie blunder

[Anonymous Coward]

Actually, you seem to have assumed that the user meant std::string("GOTO")+std::string("OOP"). The actual semantics of "GOTO"+"OOP" == "C++" is a pointer addition and pointer comparison.

Re:classic newbie blunder

[hayriye]

System.out.println(LanguageFeature.getInstance().g etFeatureCreationFactory().create(GoToFeature.clas s).add(LanguageFeature.getInstance().getFeatureCre ationFactory().create(OopFeature.class)))

Very true. That's what i told them at IBM HRL

[dharmax]

When i worked at IBM research labs, i criticized AspectJ using almost exactly the same words: they try to solve specific issues (logging, persistency, etc), that deserve specific solutions, using a completely generic approach. They failed to provide more examples for those specific problems that AspectJ will solve. Of course, i was silenced - because that's the way it works in IBM Haifa - they just can't deal with criticism :)

The concepts behind AspectJ, TMO, are not bright. They break encapsulation, they are too ambitious and far from real-world understanding of programming concerns. All in all, they introduce too many problems.

TMHO,Aspect Oriented Programming should be different, and should be based on something much simpler, much more down-to-earth ideas and more consistent with real-world needs.

Today it is easily possible to do using Java Annotations, that will specify class member's affinity with an aspect, and thus provide:

A) a mechanism by which the compiler could limit access (errors & warnings) to members according to their affinity with a common aspect or aspects (common to it and its caller);

B) a programmer, using a proper IDE, can view a breakdown of his code according to aspects.

C) in runtime, the current aspect should be visible to the program thus extending the ability to: I) log, and trace errors; II) affect work-flow according to the aspect in action (that's an intense feature so im not too sure about that)

Doing more than the above, looks to be like an abuse of proper programming concepts.

The Annotation mechanism introduced in Java 5 is quite powerful and maybe already provide all that is needed for the job, including hierarchical arrangement of aspects (slash annotations), attributes, etc. Very little is needed in order to implement what i propose.

Maybe i'll propose is to the JCP. What'd ya think?

Re:Very true. That's what i told them at IBM HRL

[drauh]

"TMHO"? Trade Mark Humble Opinion? Man, this intellectual property thing is getting out of hand.

Re:Very true. That's what i told them at IBM HRL

[MemoryDragon]

Actually you are totally correct, about half a year ago, I privately thought about the problems of AOP and why I never used it, and the problem was, you do not have clear identifyable regions in your code which marks the crosscut regions.

I went the AOP rout recently and I am very happy with it, currently using spring, the only thing I am not happy with is, that there still is too much lack in being able to mark crosscut regions clearly. meta attributes will be able to resolve that issue on a clean semantic base.

Re:Very true. That's what i told them at IBM HRL

[kupci]

The concepts behind AspectJ, TMO, are not bright. They break encapsulation, they are too ambitious and far from real-world understanding of programming concerns. All in all, they introduce too many problems.

That seems to be what the author (at Univ. Passau) was driving at. So I'm not sure if he was proposing changes to AOP to fix it. But as others have pointed out it is a relatively new technology, so perhaps the wrinkles can be worked out. Or not.

I'd suggest posting your idea to Javalobby. Rick Ross is a supporter of the JCP, and there might be others with good suggestions, that you could run your ideas past.

I certainly would prefer using annotations over AOP for these types of things. I've used xdoclet, quite nice to be able to put the annotations right in the code it is relevant to, rather than stuck in an XML file somewhere. And I think with compiler warnings, that could process annotations (perhaps this is already the case, it wasn't for xdoclet), their usage would be simplified.

heh

[Anonymous Coward]

The PL community is doing a bunch [http://aosd.net/2005/index.php ] and making a lot of progress. At Aspects Day [NEU/Brown 2005] there was a great presentation about its merits. On the one hand, aspects seem to invalidate invariants. However, the verification enthusiasts out there are making significant progress [Verifying Aspect Advice Modularly, SIGSOFT ISFCS 2004] Another view of aspects is that they explicitly programmers to change the semantics of their code[credit another ugrad at my school]. That's a lot of power. Slashdot should have linked to something not costing $250, esp considering most of the real work in the field is publicly available. Finally, AspectJ is just a Java realization of AOP, and therefore not the full deal. Open your minds - if you're looking for the next step in languages, don't look at the existing ones known to be crippled.

But the main concern ~is~ billing...

[jfb3]

Except what we know is that the core concern of a telecomunications application ~is~ the billing and timing of calls.

That's why you always get billed even if sometimes the call is dropped. Never the other way around.

first 5 lines of windows XP source code

[saladami]

Remember when this was leaked? Well here it is... See where we'd be without GOTOS? 10 GOTO 20 20 GOTO 30 30 GOTO 40 40 GOTO 50 50 GOTO 60

Re:first 5 lines of windows XP source code

[Anonymous Coward]

Please, use the Preview button next time.

New constructs for AOP?

[pmontra]

GOTO was declared harmful but it's functionality was needed so it has beed replaced by other kind of control flow statements, mainly procedure and function calls (that is methods in OOP).
That's more a matter of syntax than of semantic.
If a consensus emerges that the current syntax of AOP is harmful we'll probably get new languages with a way to either prevent or explicitly declare those side effects.
Does anybody know if there is any ongoing work in this area?

Re:New constructs for AOP?

[BarryNorton]

Regarding the separation of side effect from pure functional behaviour; yes, this is accomodated in type theory. Presumably this could be applied to aspects if these were themselves being applied to a sensible modern language (meaning one which developed on higher-order function composition, not its poor imperative cousin you're stuck with).

I'm guessing though that your belief that GOTOs are only syntactic, and without semantic consequences, implies that it's not worth pointing you to, for instance, the Haskell semantics...

Re:New constructs for AOP?

[Anonymous Coward]

You forgot about Java's named break.

Now I'm a ol1++0 (0;-)

[Anonymous Coward]

ol1++0!

Quite confused

[t_allardyce]

So let me get this straight..

AOP basically means that when an object is created, or a method is called you wan't to run some code?

So if we tried to put this into a non-OOP example you would basically be calling something else whenever certain functions were called? Eg calling a 'save', 'load' or 'start' function would result in running the 'logging' function too?

But as I gather (and its pretty hard to find a simple explanation around here) the idea of AOP is that it allows you to do this without having to put any function calls in your code, ie it 'captures events'. So if for example you had to implement some security checks but you were worried that someone in your project would forget to put the 'if(secure)' lines into their modules you could rest assured that AOP would be on the case.

Then theres COME FROM which is basically an event handler that says 'when you get to this line/label in your code, come over here and run me.

I see no problem with this in a relatively high-level environment where the goal is to write less code and where so much crap is going on in the background anyway (dynamic this and managed that) that another overlay is just going to make things look simpler.

Isn't this however almost exactly the same as an interrupt?

Re:Quite confused

[Chris Burke]

Then theres COME FROM which is basically an event handler that says 'when you get to this line/label in your code, come over here and run me.

Wait... Are you saying that C-Intercal is an Aspect Oriented language?

To paraphrase Mr Heston...

[andrewjhall]

All these arguments about different methodologies and techniques being harmful or not boil down to one thing:

"There are no good constructs, there are no bad constructs; a compiler in the hands of a bad programmer is a bad thing, a compiler in the hands of a good programmer is no threat to anyone - except the patent system."

US$49.80 per page!!!

[Anonymous Coward]

http://www.forrester.com/Research/Document/Excerpt /0,7211,36794,00.html

Price: US$249.00

Report Length: 5 pages

US$49.80 per page!!!

A 1000-pages book should cost US$498.00!!!
It's stupid book with the worth of heavy 10 oil-barrels.

Wait a moment ...

I will go to buy a cheap book (US$60) from www.amazon.com.

Re:US$49.80 per page!!!

[smittyoneeach]

Will enough people pay for the reasearch to support whatever the /. fee was for carrying this story?
Is research for money a Good Thing, or is it "begging the question" brought to a new level?

Exceptions are more valuable for non-GC languages?

[QuestionsNotAnswers]

1) Everyone uses the same construct to ensure everything is freed properly on routine exit, 2) If you see an alloc not inside a try then you immediately check for a leak, 3) There are fewer stylistic clashes over how *abnormal* conditions are passed at a programmer level (error management needs to be consistent; reading other peoples code becomes easier). For *non-critical* projects I alloc everything at the top, have one try and free everything at the bottom so no nasty indenting (only works well if code you are using has a rule of avoiding throwing exceptions in constructors e.g. using initialiser function that can throw exception instead of doing everything in the constructor).

Software Patents Considered Harmful

[Minna Kirai]

And since Aspect-Oriented programming is a patented technique, basically nobody can legally use it unless you're a personal friend of the inventor.

So, who really cares if its theoretically any good, when legally it is worthless?

Re:Software Patents Considered Harmful

[Hast]

Wouldn't this be a software patent, and as such perfectly useable in the rest of the world. Or at least those parts that haven't accepted software patents yet.

Re:Software Patents Considered Harmful

[Anonymous Coward]

This is completly untrue. Anyone can use a number of the general purpose AOP languages like AspectJ (theres even AspectScheme). Moreover, you can program in aspect style without any special language mechanisms. The patents are no problem at all

Re:Software Patents Considered Harmful

[Minna Kirai]

AC: Anyone can use a number of the general purpose AOP languages like AspectJ (theres even AspectScheme).

It is true that the patent owner provided a license to use it in AspectJ.

AC Moreover, you can program in aspect style without any special language mechanisms.

Yes, anyone can go do that. You'll just be breaking the law, which many people find not much of an obstacle. The license Xerox gave to AspectJ only applies to the implementation they provided. Re-implementing those kinds of features yourself is worthy of a lawsuit.

AC: The patents are no problem at all

Do your own research, then. Type "aspectj" "patent" into google.com and see what comes up. (You'll get articles like this, which straightforwardly explains that AspectJ is an implementation of someone's patent)

AOP sound in principle

[triksox]

I've been following AOP (cautiously) for some years now. Here's a few salient points for those who don't have $250 to splash out.

The underlying principle of AOP is about "separation of concerns", a term introduced by Dijkstra back in 1974. Separation of concerns is a Good Thing[tm], but there's more than one way to do it. It's a conceptual thing more than it is any one particular implementation technique.

Both structured and OO programming offer techniques that allow the hacker to more clearly separate concerns: by organising their code into subroutines, modules, objects, methods and so on. The problem with OOP is that real world problems don't always break down into a set of clearly defined, independant object classes. In some cases you can end up with a problem fragmented into so many small pieces that you can no longer see the wood for the trees.

AOP tries to address this by allowing you to identify those concerns that don't fit neatly into an object model. These "cross-cutting" concerns are typically things like logging, debugging and security that affect many of the objects in your system. If you decide to change the way logging is handled, for example, you don't want to have to go and edit every single object that generates logging information. But that's often what happens in OO based systems - you design your class hierarchy with Products, Customers, Orders and other real-world entities in mind and implement them as "black-boxes" with internal functionality neatly hidden away. That's fine when the functionality really is local to the object, but not when it relates to a system-wide aspect like logging, etc. These are the kind of undesirable artifacts that can arise from the decomposition of a problem into objects.

However, that's not to say that there aren't ways of achieving the good parts of AOP in a non-AOP language. Many Design Patterns are examples of separating concerns. The Model/View/Controller and Model/Visitor patterns come immediately to mind. Going back to the early logging example, we could implement this in AOP fashion in an OO language, by creating a "Logger" object which implements all the logging functionality. Just make sure all your other objects delegate to the logger for logging rather than trying to do it themselves. Now you have all your logging code in one place, and you just have to worry about how you're going to pass the logger object around so that all your other objects can call on it... (and this is often the start of the rest of the problems...)

So AOP-a-like can be done in OO languages, but most OO languages aren't really cut out for it - you have to code the magic manually if you want it. Hence the rise of AOP languages (usually just bolt-on syntax additions to existing languages) that make this process that little bit easier.

AOP in Java does smell a little like GOTO, IMHO. In brief, it uses "join points" to connect different aspects together (e.g. call this logging method just before calling that other method). One can certainly argue that it's a more structured form of GOTO, but I believe the same fundamental problems remain: control flow jumping all over the place, with actions-at-a-distance waiting to catch out the unsuspecting programmer.

So my advice on AOP would be to treat it like OOP, XML, Java, and all the other "silver bullets" that over the years have claimed to be the next big thing that will save our collective software sanity. Recognise the problem that it's trying to solve, realise the benefits of the particular solution(s) presented, and ignore all the hype!

Re:AOP sound in principle

[iksrazal_br]

"AOP in Java does smell a little like GOTO, IMHO. In brief, it uses "join points" to connect different aspects together (e.g. call this logging method just before calling that other method)."

I just don't get the GOTO reference that everyone talks about. Maybe in some narrow context but that would be largely missing the point. The Spring framework is probably the most popular AOP in Java, and while I'm just a beginner with Spring what I see is XML initialzing objects as beans.

bean id="myDAO" class="com.dao.myDAOImpl" property name="sessionFactory" ref bean="mySessionFactory"

Not proper XML in HTML/Slashdot but you get the point. So we have defined the myDAO interface being implemented by myDAOImpl - its pluggable. Then the setup is automatic in the code, done in a Service package similair to a Business Delegate in MVC:

public MyDAO getMyDAO() { return MyDAO; }

public void setMyDAO(MyDAO myDAO) { this.myDAO = myDAO; }

That and the replacement of JNDI getting DataSources and removing boiler plate code in things like JDBC and Hibernate. So to me, AOP reduces lines of code for common operations. What the hell does that have to do with GOTO?

iksrazal

Re:AOP sound in principle

[DerSchreiner]

COM+ tries to solve a lot of those common "concerns": Logging, Async Messages, User Managment, Transactions etc.

Even though COM+ is rather "flat" OOP, it is a good example of a pragmatic attempt.

At the same time it is limited (of course), and by far not as far reaching (academically).

All technologies that have build-in interference (e.g.: CSS, XSLT) are difficult to manage and (imho) require extensive tool support.

AOP and database trigger analogy

[ortholattice]

I would guess the issues with AOP are similar to those with database triggers. You use them very cautiously when there is a very clear advantage.

In my opinion, database triggers are the GOTO for databases, based on countless hours of nightmarish debugging of other peoples' trigger-happy code.

Triggers are nearly indispensable for some things, like creating audit trails. For that task it is the best tool.

But lazy database design and lazy programming can invoke a trigger that invokes 3 other triggers that each invokes 2 other triggers all of which perform what ends up as a giant transaction affecting half of the 100 or so tables tied to a customer's record. Try to debug that. Or try to write new functionality, never quite knowing what the side effect of any database transaction is going to be.

Where are all the aspect gurus?

[QuestionsNotAnswers]

Given the amount of 'buzz' about AOP, I am surprised to not see any comments from anyone in the trenchs with some experiences using it. Anyone?

Aspects: I've read about them, I've heard about them, but I am sceptical as whether the benefits actually come about. Are the debugging, side-effects, and perhaps unobvious program flow worth the gains?

<dig>Maybe we have scared all the Java programmers away?</dig>

Re:Where are all the aspect gurus?

[Keeper]

This is actually the first I've heard of it. It is actually rather intriging, as it would seem to be an interesting solution to a problem I've been recently trying to cope with -- relating to keeping elements of a user interface in sync with what is happening among several objects inside the software.

Right now there is a mess of calls inside the core of the software the twiddles elements of the UI where appropriate. It is a maintenance nightmare.

Thus far my focus has been isolating the interaction between the core components and the UI to a simple event/notification-like interface, paired with some simple 'decision/permission' state objects. That doesn't sound too far off from what AOP does under the hood...

Re:Where are all the aspect gurus?

[Hast]

When I tried AOP a few years back it was before they added terms like joint and concern. The principle is the same though.

We were doing a compiler in that project and that was a very good time to use AOP. From the CC programs you get a bunch of object code, but you don't want to edit these files as they are generated by other programs. Instead we used aspects which are then "weaved" into the generated code (this is what is called joints and concerns now). In reality it's pretty much a bunch of pre-compiler steps.

Eg we did an Aspect of the compiler code called Interpret. This aspect added a method "interpret()" in all classes, and you can easily define it's default behaviour as well as adding specific behaviours for some classes. So in our case we defined expressions to return their values and print statements to do a println and so on.

Run the pre-compiler steps, then compile and you've got a compiler that can parse and interpret code. Now add a new stamtement type to the grammar, and do it again and you have a new compiler working. No need to hand edit a bunch of files.

Naturally since this was in the early stages one problem was that looking for compiler errors in generated code was a bit of a bother. All in all it was a great help.

Re:Where are all the aspect gurus?

[Anonymous Coward]

So AOP just fixes lack of multiple inheritance in Java?

Re:Where are all the aspect gurus?

[MemoryDragon]

No... actually it fixes the problem of constantly having code which is non problem domain related messing up your domain related algorithms...

Re:Where are all the aspect gurus?

[gfim]

Sounds like you need (or have already found) the observer pattern.

Graham

Re:Where are all the aspect gurus?

[Keeper]

It is definately very similar in concept. I don't think I could pick one pattern that fully describes my design. But that's why it's fun. ;)

An empirical result- boy, will this get flamed!

[blackhedd]

I looked through a 50,000 line C++ program I wrote last year. There are 83 goto statements- I was damn surprised there were so many! An average of 8 goto's occur in each of ten different functions. Each of the functions is a large state-machine processor (they are actually PDU handlers for network protocols), so in each case the basic function structure is about the same. The goto's are there to break out of the state machine after detecting an error. Each error is completely handled where it occurs but of course invalidates the transaction, which cannot continue. So the goto is actually more natural in this specific case than an exception handler.

If you're going to (judiciously) use goto where appropriate in C++ programs, note one important thing: a goto may not span automatic variable declarations. This should make sense, since the goto target wouldn't how know to reset the stack-frame pointer. This restriction doesn't apply in C, which only allows automatic declarations at the top a function.

Re:An empirical result- boy, will this get flamed!

[snorklewacker]

State machines are very typically written in terms of goto. Most C compilers still can't do general tailcall elimination (just recursion), so goto is used to make them fast. A protocol stack is one case where speed must trump aesthetics.

Let's see

[jfern]

1. Make useless 5 page document
2. Have a link from Slashdot allow you to buy said document for $249
3. Profit!

I like GOTO too!

[bundaegi]

This is how I usually write my C code:

• Any function that needs allocating memory is problem prone.
• I don't need to know where exactly the code failed, just that it failed.
• The compilers I use free NULL pointers gracefully.

The last one reduces the error handling to a minimum: just one label to go to (although, be careful, you do need to initialise them pointers as NULL).
Important point, the same freeing code is used by the function as part of the normal, non-error flow. This is why the returned error_code variable is first initialised to 0 (all clear). goto statements are used to escape the normal flow when an error occurs, just like a break statement breaks out of a loop.

int foo()
{

int error_code=0;
int *stuff_ptr1=NULL;
int *stuff_ptr2=NULL;

do something;

if(error)
{

error_code=1;
goto err;

}

do something more;

if(error)
{

error_code=1;
goto err;

}
....

err:
free(stuff_ptr1);
free(stuff_ptr2);
return error_code;

}

html code copy-pasted from the vim html output.

Re:I like GOTO too!

[Anonymous Coward]

free(NULL)?

Fantastic piece of crap code!

Re:I like GOTO too!

[bundaegi]

Did you actually read what I wrote? Read again, you might learn something!

I am perfectly aware that my code is only portable if free(NULL) is handled correctly. Guess what? It's part of the fucking ANSI C spec. That's how standard it is. As in:

ISO/IEC 9899-1990 7.10.3.2 "The free function":

#include void free(void *ptr);

That section states "If ptr is a null pointer, no action occurs."

If you don't believe in ISO specs, do check out the linux man page for malloc:

free() frees the memory space pointed to by ptr, which must have been returned by a previous call to malloc(), calloc() or realloc(). Otherwise, or if free(ptr) has already been called before, undefined behaviour occurs. If ptr is NULL, no operation is performed.

So there... you don't like the construct, don't use it. I'm not forcing you now, am I? You don't understand it or have concerns, fine, say so...

But don't just dismiss something as a "fantastic piece of crap code" without explanation, it doesn't reflect favourably on your intelligence.

Re:I like GOTO too!

[Anonymous Coward]

Well, being part of an ISO spec does not help that much when memory gets trashed, that's why it's crap, try to be rationale and insert a simple conditional.

Either that or you'll have to insert a comment stating that an ANSI C compiler is required.

I think i am gonna start all my C functions with some extras free(NULL);free(NULL);free(NULL); statements from now on! :)

ok ok just kidding..!

Re:I like GOTO too!

[bundaegi]

huhu,

I think i am gonna start all my C functions with some extras free(NULL);free(NULL);free(NULL); statements from now on! :)

and that gets recognised by GCC and compiled into NOP NOP NOP... so unless you want to introduce a 3 instruction delay, there is no much use to it ;-)

sure I could put

if (ptr!=NULL) free(ptr);

and there would be harmony in the universe again. But that's pretty much the first test performed in any free.c function (handy example with uclibc):

/* Check for special cases. */
if (unlikely (! mem)) return;

free(NULL) doesn't trash memory. freeing a uninitialised pointer does. I don't expect a int *ptr; to initialise a ptr to NULL (why should it) but I do expect reasonably well written (up to iso specs) malloc, free, realloc functions in all modern compilers. That's the basics. It's been the basics for what, 15 years now? Probably even longer... Yes, even microsoft!

Sure C doesn't hold your hand the way java does, but that's part of the fun I guess.

Anyway, bedtime...

Re:I like GOTO too!

[Anonymous Coward]

Sorry if I have been too harsh on my first post, but too many years of C coding enables some kind of instictive alarm when you see an unconditional free(), especially if it's a NULL value! :).

In my experience freeing a NULL pointer is always a bad idea, no matter how good the runtime libraries or compilers are (I remember some ibm compiler initializing to 0's the stack vars, and some ugky code relying on that 'feature'). You know, experience encourages to avoid bad habitudes.

Objective-C has these, and no one bats an eyelash.

[israfil_kamana]

A very well respected (if a bit obscure) OO language is Objective-C. It has a few features that are analogous to aspects.

First it has categories, which allow you to add new methods, or replace the implementation of a method in a given class. You add a category to that class that includes, say, a replacement description method, and the new implementation replaces the old. Or you can add a path utility methods to the String class, as another example.

It also has "poseAs", which allows you to insert an object into a hierarchy. Say you have Class B which extends Class A. But you want custom behaviour to be accessible to all As children (including, for example, B). You create Class C, which extends A, and make it poseAs Class A. Now the runtime hooks all clesses that inherit A off of C, which replaces A. A still exists, but is in the background, providing normal inherited functionality to C.

These abilities were one of the things that made Objective C a very powerful OO language. In particular, it allows a particular kind of reuse, by virtue of allowing one to patch someone else's library without having source. So if you want to add the aforementioned path utilities to NSString, you just added a Category in your own code, and your code would run with the extended functionality in NSString (no one elses would, unless they used your category too). This means that often you can make the most out of someone else's code without a complete rewrite.

It isn't all powerful. There are access and visibility restrictions. It is also used to partition code for ease of organization and better modularization. Here's the point:

Because it is a well known feature of the language, you think in terms of categories, and you know to look for categories. This can be aided by tools, but you most definitely need to pay attention to them. But because of this, they are only "dangerous" if you aren't paying attention. And guess what! That's true of programming, period.

Perl6/Pugs dude has no problem with Haskell

[Anonymous Coward]

In fact, I've never seen shorter code to accomplish such a complex task. Haskell must be doing something right when the language of choice to write Perl6 is not Perl5, but Haskell.

Re:Objective-C has these...

[israfil_kamana]

Woops, forgot to add a C2 Wiki entry for Objective-C.

How to make your boss accept GOTO

[thaig]

I use macros like this to make my goto usage acceptable to other programmers in my office.

/**
A set of macros for helping to ensure that
C functions or C++ methods can clean up
allocated memory properly.
*/

#define RV return_value
#define DECLARE_RV(type,default) type return_value = default;
#define RETURN(value) { return_value = value; goto cleanup_point; }

#define CLEANUP cleanup_point:
#define CEND return return_value;

#define SAFE_FREE(mem) if (mem) { free(mem); mem=NULL; }
#define SAFE_DELETE(mem) if (mem) { delete mem; mem=NULL; }
#define SAFE_DELETE_ARRAY(mem) if (mem) { delete[] mem; mem=NULL; }

So some cleanup code might look like this:

int aFunction(char *aParameter)
{
/* The return value is an int and will default to ERRNONE */
DECLARE_RV(int,ERRNONE);
char *buffer1 = NULL;
char *buffer2 = NULL;

if (!aParameter)
{ RETURN(ERRFAIL); }

buffer1 = (char *)malloc(1000);

if (!buffer1)
{ RETURN(ERRFAIL); }

buffer2 = (char *)malloc(1000);

if (!buffer2)
{ RETURN(ERRFAIL); }

/* Do something here */

CLEANUP;

/* only free buffer1 and buffer2 if they actually were allocated. */
SAFE_FREE(buffer1);
SAFE_FREE(buffer2);

CEND;
}

So I can safely "return" an error if I fail to allocate buffer2 without worrying about buffer1 because it's handed by the cleanup.

This makes code much clearer and avoids lots of dumb memory leaks that can happen when you make changes to a function. I never mention goto when I show this to people and they are very pleased with it.

Re:How to make your boss accept GOTO

[rifftide]

Not bad, your system is actually readable. But it only works in functions that follow the convention of returning the error value, and all the error values from the various functions are from a consistent set.

Here's a way your function could be revised to avoid goto (this might not work in a more complicated situation however):

int aFunction(char *aParameter)
{
return_value = ERRNONE;
char *buffer1 = NULL;
char *buffer2 = NULL;

if (!aParameter)
return_value = ERRFAIL;

if (ERROK(return_value)) {
buffer1 = (char *)malloc(1000);

if (!buffer1)
return_value = ERRFAIL;
}

if (ERROK(return_value)) {
buffer2 = (char *)malloc(1000);

if (!buffer2)
return_value = ERRFAIL;
}

/* Do something here */

/* only free buffer1 and buffer2 if they actually were allocated. */
SAFE_FREE(buffer1);
SAFE_FREE(buffer2);

return return_value;
}

Rochkind provides a more complicated set of macros in his book "Advanced UNIX Programming". His are probably more typical of a larger project where additional requirements have accumulated over time, e.g. errno to string mapping and function back trace.

The need of relying on the preprocessor for error handling constructs is a serious drawback. In C++ you would typically use templated smart pointers/resource holders to ensure cleanup. You could report errors either by throwing exceptions or propagating return values (as you've done it) - smart pointers work either way.

Re:How to make your boss accept GOTO

[Anonymous Coward]

Quite clear coding, but #define always obscure the real code, specially when they are defined in some undefined include file. I for one prefer simple goto's, no problem with them as long as the hardware keeps using jump instructions.

Re:How to make your boss accept GOTO

[thaig]

I started using this sort of "local-exception" when I was writing code using the asynchronous LDAP API. The functions had to be a bit longer than I usualy like and there were so many ways that the operations could fail that using nested-if led to very deep indentation. It made the code a bit confusing.

Re:How to make your boss accept GOTO

[thaig]

I started using gotos but had so many negative comments from my colleagues (some of whom just believe "goto is bad" without understanding it) that I had to come up with some way to make it look nice.

Otherwise I agree - the header file introduces a dependency across every file in your project so that any changes to it require a rebuild of your entire product. That doesn't happen often, fortunately.

Re:I like GOTO! [exceptions, FP and continuations]

[Anonymous Coward]

I've used exceptions as a control structure to great effect in a C++ program I wrote recently. The original implementation had many dynamically allocated objects, looked dangerous, and was untestable. The exception rewrite was done very much in a functional programming style. All objects are allocated on the stack (very safe), and the overall structure was vastly simpler and actually testable.

My inspiration for this approach came from learning about continuations in Scheme... a C++ exception is essentially a special case of a continuation.

Yes, exceptions are slow, but in many (most?) cases it just doesn't matter.

AOP has its uses (without going to production!)

[bsletten]

AOP is not the answer to everything, but one of the main points of a talk I give at the NFJS show is that you can find tons of uses w/ development aspects without ever having to migrate them into production.

You can enforce (and detect violations of) various architectural decisions (i.e. no direct JDBC connectivity without going through a facade), define and enforce contracts (and leave them out of production), detect threading issues (How would you find all Swing thread abuse cases in a large, multi-threaded application?), get a sense of code coverage, etc. around any arbitrary cut of your system.

If you take the time to build around interfaces and support Object decoration via some variant of factories, you can do some of these things using Decorator and Dynamic Proxies, but you don't always have that luxury.

Tool support has been fundamentally lacking until things like recent versions of the AJDT. It still isn't perfect, but should serve to answer many of the early critics complaining about debuggability and losing track of what is going on.

I am an advocate of AOP in production systems, but you don't have to drink the whole glass to find aspects tremendously useful in development alone. With support for Ant-based builds and whatnot, it isn't even really an onerous task to give it a try.

Don't use AOP for things it isn't a good fit for, but there are quite a few things that can't be done as easily and elegantly without it (at least in Java). As others have pointed out, languages like Lisp and Objective-C have support for AOPish things built in.

Re:AOP has its uses (without going to production!)

[tcopeland]

Go Brian! +1 Informative!

See you at the NovaJUG mtg on Tuesday, if you're going to it...

Re:AOP has its uses (without going to production!)

[rffrff]

let me understand: you're saying that you advocate usage of AOP because it allow you to: - enforce design decisions - detect design violations - define and enforce contracts - detect threading issues - get a sense of code coverage - turning stuff on and off at compile time So basically you're saying that Design by Contract is great but that instead of using Eiffel it is better to use a patented tool wich basically works as a preprocessor or as an ugly JVM hack ?

Re:AOP has its uses (without going to production!)

[bsletten]

Well, I am advocating the use of AOP for more than DSC, but, in essence, yes. You will note that I did mention that other languages do not require the use of a meta tool like AspectJ to provide similar features. Eiffel is a great language and I hope its use and influence continues to grow. Until then, 97% of the developers out there will wonder why you are talking about a tower in a programming discussion. :)

Re:AOP has its uses (without going to production!)

[mcbevin]

I guess this is a dumb question, but could you give an example or two of how AOP would be used to define/enforce contracts etc, just so I can get a better idea of what you're talking about? What you're saying sounds really interesting, but I can't quite get my head around how AOP as I understand it could be used to do such things.

Re:AOP has its uses (without going to production!)

[dangermouse]

The first I read about using AOP to enfoce contracts was an article by Gregor Kiczales in the Dec. 2004 issue of Software Development. I copied this example into my notes:

declare error: within (com.acme.lower..*)
&& call (com.acme.upper..*) :
"Lower layer should not call upper layer.";

I can't pull SD's website right now, but it looks (from Google) like the full article might be here.

Re:AOP has its uses (without going to production!)

[bsletten]

Not at all a dumb question. One thing you may not be familiar with is AspectJ's 'declare' keyword. This allows you to specify that any pointcut designator (PCD) actually represents a warning or an error. The AspectJ compiler will either emit a compiler warning or stop in its tracks if someone writes code that matches the PCD.

You could then use this to say that any call to the core JDBC classes that does not occur within the lexical scope of the database facade layer is a warning or an error.

So, Joe Schmoe developer ignores the mandate to use the facade. You can either push the aspect into the common build environment (which would cause error/warning annotations w/ tool tips to show up in Eclipse when using the AJDT) or catch it in the nightly build when he checks in the code.

This represents a static policy enforcement because it is detectable by the compiler. You can also associate advice that throws exceptions if something is not detectable statically but represents an error condition at run time this way.

For example, I was handed a body of code on a fixed price contract once that I discovered was loosey goosey about updating Swing components via the UI thread. I pulled my hair out in frustration for a few minutes before I realized I could catch all of these violations w/ an aspect.... at any call to any public method of any JComponent or one of its children, check to see if it is running on the UI thread. Throw an exception/dump the stack trace if isn't. I found seven violations that night. I left it compiled in for another month and never found any more. So, that could have been a bear of a code review without the ability to express the contract (must run on Swing UI thread) as code using AOP.

You sure you're not Tablizer?

[Latent Heat]

What problem does this aspects mechanism solve that isn't handled by a proper implementation of multiple inheritance. It seems you are trying to bolt on the same functions to a collection of classes (or perhaps methods on those classes) without having to make them part of the root class.

I don't have much experience with multiple inheritance, but I understand that introduces some pain of its own. With inheritance, you have some core functionality of the base class and then you add on functions. With mixins (adding a clump of functions), I suppose you could do those with multiple-inheritance, but with using object composition as a substitute, you have to write all of these stupid little forwarding methods (or confess to the sin of violating the Law of Demeter by having too many levels of the dot notation).

Re:You sure you're not Tablizer?

[hibiki_r]

Imagine that a program is misbehaving for some reason, and you decide that you want add a log statement whenever you enter and exist every function. The problemis, the original programmer was a slacker, and you really don't have much of a loggins system built in. You could either spend minutes/hours/days changing the code by hand, or you can create an aspect that attaches itself to all of the methods on a package/namespace, and writes the logging you want. You go froma few hundred/thousand lines to about 5.

read Burton report instead

[Anonymous Coward]

Burton has a much more substantive report, that comes to a much more balanced conclusion - AOP is a useful and powerful technology, that is rapidly gaining traction in Enterprise Java, and developers and managers should be a process of measured adoption.

WTF?!

[Anonymous Coward]

Free advertisment on Slashdot for a report that costs 250 bucks? My Ass.

As all technique everything has its use

[Portal1]

I am very sceptic about aspect oriented programming.
But I do see it's use in some very specific points. These are logging and memory checks. This code can be performed with having no side effect on the actual program, while adding (temporal) functionality.
Aspects that do change the program flow or the results (ie that do not just monitor) are in my point very dangerous. A samples of this is persistency where aspects are also used a lot. It is the same as I look at templates and goto, they can be usefull for some specific tasks but don't use them for anything else and only use them when you know what you are doing. (so most people should not use them :))

This doesn't deserve to be a Slashdot article

[PleaseDontBeTaken]

A story that refers people primarily to a uninformative abstract on a $249 for-purchase paper simply isn't worthy of being an article on Slashdot.

If I could mod down the story choice, I would.

Sorry to be a downer, but this needed to be said.

Did anyone else read it as

[Anonymous Coward]

Adult-Oriented Programming Considered Harmful?

Exceptions are HORRIBLE!

[Anonymous Coward]

This is a case of the cure being worse than the disease. Exceptions are more like COMEFROM than GOTO. They are not a reasonable or useful solution, and greatly complicate programming rather than simplifying it.

More importantly than replacing goto, they are an ugly patch for the problem that functions can only return one result (unless you do something like make a new struct for each function), so you can't return an error code along with the result. This is a fundamental error in language design that makes serious, fault-tolerant programming unreasonably difficult.

And before you say it, no, passing references to functions is not a reasonable substitute. Workarounds are not equivalent to features. Having to create temporary variables etc. for every function call isn't a reasonable option.

What exactly is "aspect oriented programming?"

[Anonymous Coward]

Seriously. There is imperitive, logic (declaritive), and functional programming. The way people discuss this is as if there is a subtype of imperitive programming that is "object oriented" and another that is "aspect oriented." Is there a way to write code only with aspects and nothing else?

What specifically is "object oriented programming." When is the coding style object oriented? When it inherits and groups procedures in to classes? When if reflects off of classes? When it uses polymorphism? When code is reused in a specific way or something? I read a message that said that they didn't do object-oriented programming in lisp, what exactly does that mean?

I could make an argument that all non-functional programming methods could be considered harmful, simply because they are so much more likely to have bugs and it's that much easier to prove a functional implementation, albeit probably a bit more difficult to create one. I'd also argue that anyone who thinks that there is such a thing as "object oriented programming" is full of shit or doens't have much CS background; it's imperitive programming, the modeling of the problem space is object oriented and chances are that if you're a believer in OOM then you'll model the problem that way regardless of whether the implementation is functional, imperative or imperitive with aspects. Unless of course someone has a sound definition for "object oriented programming." Same for "aspect-oriented programming" Now Aspects are cool, I can see them as really really easy ways to simplify some specific problems, I can also see how you can radically complicate matters by using aspects and not remembering them or have defects in them. Yeah, so harmful in the same way as any imperitive technique can be harmful only with aspects the code may not look at all like what it is actually doing.

AOP is...

[Mr. Underbridge]

I'm a fairly experienced coder, but I don't have any experience with AOP whatever. I don't even know what it is!

It's a buzzword intended to drive a lot of book sales and consultancy fees. Hell, throw that in your vocabulary along with "TCO", "ROI", "paradigm", etc, and ca$h in!

AOP Can Be Useful at times and should be available

[Eravnrekaree]

There are cases where AOP can play a useful and beneficial role and is a good feature to have. It is really up to the programmer to decide whether or not a feature would be useful or not in a particular setting. Programming languages should give users the freedom to make such determinations, since each application is different, each will have different needs. A set of language features that works great for one app may be insufficient for another. Some people criticise certian features because for the things that they have done they might not be useful, but in that case they shouldnt be obliged to use them. But the feature might be essential in another program, and if the feature is not avialable because someone else decided it didnt fit their needs for what they were doing and thus made the assumption that therefore no one else should be allowed to use it, the programmers task as been made more complex and barriers placed in their way and their job more difficult. The program language should give the programmer powerful tools to use so that if the programmers needs those tools they are avialable.

Re:Forrester is just another clueless IT consultan

[RebelWithoutAClue]

The question is, did "Six Sigma" ever work ?

We can see it doesnt work here, because its close to home ...

Maybe it never worked ?

Performance "Hit" For Exceptions

[BuildMonkey]

Using an old, and not very smart, C++ compiler (gcc 2.95 plus vendor patches) we recently measured the cost of throwing an exception as 8-10 cycles. This was an empty class, to avoid measuring construction overhead e.g.

class Exception {};

That doesn't strike me as an "obscene" performance hit.

Re:Performance "Hit" For Exceptions

[rikkus-x]

Mods, see parent.

Re:Performance "Hit" For Exceptions

[Keeper]

The cost of "throwing" an exception includes the cost of handling it. This includes object construction, generating a software interrupt, switching to OS code, unwinding the stack, and the various calls used to determine if there is a handler present which can handle the exception at the current stack level (which may or may not contain a trivial amount of code; it is the equivelent of a function call for each catch statement you may have, with a lot of logic thrown on top of it to convert the data made available with the exception into the form your C++ code expects).

There is no way in hell that takes 8-10 cycles. Most likely you're measuring the number of cycles taken by the instructions used to generate the exception, which would include allocating the exception object and an instruction to generate the interupt.

I'm not even considering the overhead imposed by registering/unregistering exception handlers for various blocks ...

Re:Performance "Hit" For Exceptions

[jelle]

Dude, look up "throw()" and "try {} catch()", they don't need all that bloat you're talking about.

If you're throw()-ing an exception in the same context, to a catch() in the same function, you'll likely see a 'goto' in the assembly output of your compiler.

Re:Performance "Hit" For Exceptions

[Keeper]

I will conceed the contrived case is effecient where exceptions are always caught in the method that throws them.

This would require code to be structured as follows:

result = call();
if (result == failed)
throw some exception

You'll note that this isn't an example of the recommended use of exceptions. Proper design involving the use of exceptions demands that methods thrown them instead of returning error codes. The typical use would be as follows:

call(); // can throw some exception

An error condition in this case incurs the full overhead of exception handling detailed in my previous posted.

Your suggested proposal for the use of exceptions in this manner is nothing more than an obscured goto.

Additionally, any non-stack based resources allocated during the try block will not be released after the exception is thrown, which is another strike against the use of exceptions in the manner you describe. This would be less of an issue if C++ provided for some sort of "finally" syntax, but it does not.

Here we go again

[whitroth]

Given OOP, and overloading (which also makes debugging hell, if you weren't the one who wrote it), one wonders if the comparison isn't GOTO, but worse: COBOL's ALTER.*

I also note that the poster who mentioned both structured and OOP found a problem with OOP...but not with structured.

IMO, OO design is interesting...but OOP is nothing more than trying to enforce Ye Olde Good Coding Standards by compiler.

As usual, you can't *force* folks who write spaghetti/crappy code to write better code - they'll learn, or they won't (and hopefully, then, won't be promoted to management).

There's also the viewpoint that seems to be associated with OO that everything should be stateless...sort of like saying all data should be normalized. (Duhhhhh...)

The bottom line: my vote is for OOD, but structured code.

mark "and it's still functions, subroutines,
and parameter passing, not methods
and messaging...."

* My boss at the time I discovered that verb and I agreed that anyone using ALTER should be defenistrated, *then* fired.

Re:Article is FUD against Common Lisp which has AO

[dmh20002]

hasn't use of Lisp been rising for about 50 years? When will it be used by more than 1% of programmers? I guess it hasn't reached the tipping point yet. at least its ahead of pascal.

Re:Advantages of COME FROM?

[big.ears]

Here's a link (http://en.wikipedia.org/wiki/Satire) that explains it all for you.

Ken Thompson goto quote

[justine_avalanche]

If you want to go somewhere, goto is the best way to get there. K Thompson

Better solution: toss OOP

[Anonymous Coward]

"Aspect-oriented programming (AOP) is intended to address common problems that object-oriented programming (OOP) doesn't address well, plus some problems that OOP itself created.

We have found another solution: Don't Use OOP. 99% of the bad things people attribute to procedural and database programming is wrong. It is usually because they were bad procedural programmers and bad database designers, and not the paradigm itself.

No paradigm has proven perfect, by the way. There is no silver bullet so far. Different paradigms just seem to be a personal preference.

Monads AOP?

[shapr]

From everything I've seen about Aspects, they look like a subset of Monads. Monads do the same sort of weaving of separated concerns, but as far as I can tell, monads are much easier to combine, have better granularity, simpler implementation, and a cleaner theoretical basis.
I realize I could be totally wrong, I never did finish reading all the papers on the Minimal Aspect Calculus article on lambda-the-ultimate.org.
Can you give me a better comparison between AOP and monads?

AOP is a two edged sword

[MemoryDragon]

Just like goto, which I would not totally consider harmful. Goto has its place in programs which need a precise command which maps directly to a processor jump instruction, therefore goto or similar constructs are widely used in system near programming.

I have to admit, I stayed away from AOP for a long time, but that stuff can be really useful if applied in the proper manner. The usual application has lots of sideconstraints which basically stain your algorithms up to a point, where you end up having 2/3rd side constraint code, 1/3rd algorithmic code. The side constraint is constantly the same over and over again, only altered slightly according to the state of the algorithm.

Now if you move that code in a well documented and clean manner into aspects, you can gain a lot. Aspects however are a deadly construct, if you go the AOP is everywhere manner and dont limit yourself to the basic rule, use it seldom and use it wisely but use it whenever you can achieve a cleaner code with it. If you go the aspect here aspect there route, you end up in a bigger mess than with a huge spaghetti code and 100 gotos in there.

Perfect examples for AOP are, to move the error handling code of checked exceptions out of the algorithms into aspects, another one would be to get a clean semi automatic transactional scope in methods which are called from the outside. Both things can be achieved with aspects in a much cleaner way, than with traditional programming, but if you use this stuff in that manner, document it and comment it, otherwise the persons who will follow you cannot see that the method is in a transactional scope.

So aspects are definitely worthwile using (I learned that once I jumped over the wall of considering it a deadly construct), but you really have to be careful to limit it to a few problem domains.

Rip-off

[Bubba Bui]

Step 1: sum up publically available research results from a university lab Step 2: advertise on /. Step 3: profit! Get it?

short summary

[nikster]

AOP sounds great for logging and debugging - and possibly all other things where you want to trace program execution.

Using AOP for pretty much anything else sounds like a recipe for disaster. Altering the program logic in invisible ways. Not good except to make yourself indispensable because no one can possibly understand your code.

The only thing worse would be to tell management all about AOP, so management can go to the programmers and tell them how to program. Better still, let the clients chime in on the debate. Oh, the fun!

But....and this is important...

[Rinzai]

...consider the source. Forrester Research is a bunch of do-nothing hacks where I'm concerned. One of our customers sent a report they'd gotten from Forrester on an aspect of our business, and it was filled with more half-baked assumptions, unresearched assertions, and self-generated opinions than you could shake a stick at. I sent a pointed rejoinder to Forrester to ask the authors of the report where they'd gotten their facts, and wondering where the backing research was for their assumptions, and so far I've heard nothing back. That was a year ago. Forrester Research can kiss my pale white overweight geek buttcheeks, early and often. (Point of order: I'm holding back. Don't get me started for real.)

You're the one that's being had.

[KZigurs]

After all it's clearly visible that we are dealing with integer variables here. C++ doesn't says anything to you?

So, of course, we have variables GOTO and OOP and post-incremented C.

But you are probably right about "==".

My Take on Aspects

[nimblebrain]

Aspects 'inject' behaviour into your classes. This is fine if the behaviour is completely orthogonal to the workings of your class, e.g. you're injecting enter/exit logging. If you start to inject functionality, however, the workings of the class can be substantially obscured. A number of the examples I've seen can be as properly done with more broken-down normal methods and a naming convention (e.g. before_x, after_x).

That said, chances are that the true benefits of aspect-oriented programming are not going to come from it being a mere curiosity to add to object-oriented programming. Someone is going to have to discover how to program in AOP where the focus is on AOP.

Possibly, it will have a journey like object-oriented programming. Started out with being used as object-based programming (just a more convenient way to associate data with functions), grew to some standard uses, then exploded into class libraries and eventually patterns.

Even 'interface-oriented programming' requires a slightly different tack than plain object-oriented programming does.

That's not to say that AOP will be the next actual big thing, or even really find its niche. There are plenty of good ideas that never really 'made it'. Time, and a whole passel of people with a lot of on their hands, will tell :)

Structured vs OOP

[suitepotato]

Structured: discipline required to remember where what was placed and how it works and where it goes and what it does and so on.

OOP: who cares where what is or how it works or where it goes or what it does or uses.

I used to write programs in old Dartmouth BASIC in a tenth of the time C takes to do the same thing. Then C took a tenth of the time C++ took. I mean, figuring in troubleshooting any and all mistakes and my concepts versus what the machine thought and so on.

The next big OOP language should just be called something honest. Like Obfuscation+. Or TimeWaster.NET.

Re:Structured vs OOP

[Anonymous Coward]

C takes a tenth of the time C++ takes eh? Interesting...

I guess manually handling memory for strings and writing your own data structures and algorithms is a lot quicker and less error prone than having that all done for you.

omg

[Anonymous Coward]

OMG OMG HERESY!!!! the aspect programmers MUST be CRUSHED!!!

Re:Forrester is just another clueless IT consultan

[the-build-chicken]

ack!!! The company I work for has just begun implementing the balanced scorecard approach!!! Do you have a link?

249$ FUD PR?

[Tharkban]

I don't understand how you can spread FUD for 250$ a pop. Perhaps just with the headline? I guess people don't usually read the article anyway, right? :)

throw is the name of GOTO in Java

[Anonymous Coward]

I use GOTO in Jave - it is just called "throw"

Hidden goto's

[Anonymous Coward]

Why don't you "try {} catch(something);" and use a hidden goto?

mod parent down

[cocoa moe]

How can that be called Insightful.

The idea is that you don't nest if-statement in a way that nobody is ever likely to understend, but to structure your code using more advanced means. And yes, using "exceptions" is not enough of an improvement.

Goto's use should be limited to very few performance-critical parts. And if you wrote those parts in assembler instead of C ... well that would be perhaps less portable :-(

You proved one of the deficiencies

[cocoa moe]

after err1: you just free the stuff allocated in "do something more", which has not happend if the first error happened. So your code is not working as you expected!

Plus: if you dont do a lot of testing, you are likely to miss the bug until your product is shipped!

Re:You proved one of the deficiencies

[evvk]

Get a life. Nowhere did I say that the words 'more' should match in the pseudo code.

No

[Peaker]

Functions are very different containers of code than small blocks in a function.

The conventions about interactions between functions are different. Functions have a name. Functions have clearly different scopes with their input/output well-defined.

Functions are reusable. Functions are in general understandable separately while goto blocks have to be understood all at once.

With tool support, AOP *is* structured

[JonathanAldrich]

The objection that AOP is unstructured becase it injects arbitrary code into your function is common, and it's absolutely correct if you consider editing code in a plain old text editor.

In reality, almost no one does this. Because of the nature of AOP, it requires IDE support--see the AJDT (http://www.eclipse.org/ajdt/) for one example of what this looks like.

With IDE support, you can see exactly where aspects might affect your code, and you can easily navigate to the definition of these aspects. Tool support essentially gives you the desired scoping back, even though it's missing in the language.

Gregor Kiczales and Mira Mezini have a nice paper on this (http://www.cs.ubc.ca/~gregor/papers/kiczales-icse 05-aopmr.pdf), and I've done some more theoretical work validating the claim that modular reasoning is possible in AOP, given the proper module system and tool support (http://www.cs.cmu.edu/~aldrich/papers/open-module s.pdf).

Re:With tool support, AOP *is* structured

[Bodrius]

Thanks for the links to the papers. I was vaguely aware of this as a known problem but I haven't been following the research as closely as I would like the last couple of years.

I still avoid thinking of the problem as "lack of structure" because the structure is there... it's just documented in an unexpected location in the source code. But I'm very wary of the IDE dependency as the solution to that problem, partly because it is a very heavy dependency to take, and partly because it does not 'click' in my mind as the most elegant solution.

IDE support is also only a solution for the static weaving problem, as in AspectJ. Dynamic weaving has some very tempting advantages for a good set of problems, such as services provided by hosting environments.

I understand the reluctancy to limit the "aspect obliviousness" because it limits the power and flexibility of the construct; but I find it interesting that in other methodologies obliviousness is something we have often moved away from as we develop richer security and correctness models. Your own work on ArchJava was a removal of participant obliviousness in component interaction, if I remember correctly from my grad school days.

It seems to me that a limitation in power will be very difficult to avoid if we want to solve the problem. Forfeiting dynamic weaving and taking the IDE dependency may be the solution, or maybe it will be adopting an explicit Advice/Advisee contract and a richer security model. I'm just glad research is active on the problem.

Re:Article is FUD against Common Lisp which has AO

[rffrff]

no it does not. The author of aspectJ is also the designer of the common lisp object system, but he enahanced it's initial ideas. That is the reason that AspectL exists.

This guy

[jmike]

http://en.wikipedia.org/wiki/Pointy_Haired_Boss

Somebody just got paid...

[The Panther!]

Apparently the way to make money selling e-books is to write something Slashdot will post, then charge an outrageous sum for it on Forrester.

I'd also like to point out that AOP is just a fancy term for globally-accessible singleton (GAS). I've got GAS, but I don't brag about it. Sheesh.

Re:Exceptions are more valuable for non-GC languag

[Anonymous Coward]

RAII solves those problems. You can create as many objects as you like in the same scope, and if any constructor throws (or signals the caller to return an error code immediately), the compiler takes care of cleaning up all the already-initialized objects (and not the unitialized ones). You should never see an allocation except inside the constructor of an object whose destructor will always release it. try/catch is for providing explicitly different behavior in the event of an error. try/finally is for brain-damaged languages without destructors or deterministic finalizers.

Slashdot needs no stinking real data

[Anonymous Coward]

The editors know that no Slashdotter can read more than 3 sentences on the same topic in a row without suffering brain death, so the fact that the headline article contained zero information and you have to pay for the real stuff was perfectly acceptable.

Re:Forrester is just another clueless IT consultan

[tyates]

Six Sigma works great - for certain types of defined, measurable processes. Six Sigma worked great for GE when it wanted to make better jet engines. Not so great when they took it to NBC and tried to use it to make better episodes of Seinfeld. It's one of those cases where when all you have is a hammer, everything looks like a nail.

AOP: Fix poor design in implementation?

[skeptictank]

That is what AOP really sounds like to me. I have looked at several primers and basically come to the conclusion that most of the problems that AOP is intended to fix are the result of poorly thought out architecture.

Re:AOP: Fix poor design in implementation?

[Anonymous Coward]

Thats not precisely true. There are certain problems that, because of the limitations of OOP, cannot be solved optimally without being difficult to understand. These problems are ones that cross-cut the system. You can think of well-designed objects as vertical lines, each cleanly separate from the other. There are certain problems, such as the typical logging example, that don't fit cleanly into one of your objects, and instead are horizontal lines, cutting through the system. Can you implement these using OOP? Yes, but the solution will either be convoluted and unmaintainable, or very inefficient, and there's nothing you can change about the design to fix it because cross-cutting concerns simply do not fit into your objects. AOP is being developed as a way to implement these concerns modularly, giving a clean and optimal solution.

softwarte quality assurance

[Anonymous Coward]

Yes you didn't say, and in a way that is the point.

It is easy to make a mistake when you use the goto construct in that way. And you didn't even think about the mistakes one is likely to make but assumed that any programmer will be sensible enough to figure the correct sequence of labels and do the cleanup properly.

My guess is that this works well in about 60% of the cases. The other 40% are buggy. About half of these cases don't lead to program termination in the other half it would have been better to use exit() instead of goto.

Re:softwarte quality assurance

[evvk]

Any programmer who can't figure out the ordering should not be programming.

Using exit in the middle of program is always wrong. One should always try to continue where possible or fail gracefully if not. Too many programs these days fail to handle memory allocation failures properly...

JavaBean properties are like advice

[Baby Duck]

If you have a JavaBean setter and getter that both do more than just set and return a field value, it's like writing advice around a "field".

Or think of a JavaBean as advice around the fields of a C struct.

This isn't "code-weaving", though, considering all the code is in one place.

Re:Forrester is just another clueless IT consultan

[MemoryDragon]

They always were... Every article or comment I read from one of those consultant companies, normally even lacked basic CS understanding you learn within the first 3 semesters of computer science. The output of them is usually from clueless or business people for clueless and business people, with some CS coloring on top of the garbage they write.

Re:Reminds me of my teen years

[Bill Dog]

As a teen I would booby-trap the Atari 800 computers at Gemco. A continous loop in Atari BASIC that went from 0 to 255 and back, that poked its value into the memory locations to change screen colors and sound pitch, initiaited when someone hit a key. Run it and turn the volume on the TV it was attached to all the way up, and then hide down the next aisle and wait for an unsuspecting victim to come by and witness them:
1) Jump out of their skin at the first touch of the keyboard, and
2) Cause a great scene and have to endure mucho embarassment, and
3) Make them wonder how they could've possibly "broke it".
Muwhahahaha.

Re:Buy this document? 249.00???

[Anonymous Coward]

I hope I never work for or with your company. It sounds like you et al are bunch of idiots.

Re:OfF course

[Anonymous Coward]

The only problem with your statement is you don't know c++.... (GOTO + OOP = C++ || (GOTO + OOP == C++)) But then who cares when lub is great. :D

You're winning when the big guys start FUD

[Anonymous Coward]

The first usage of "AOP considered harmful" was (surprise!) at a JavaOne panel where Sun cordially ganged up on Kiczales, et al. With AspectJ (read: IBM) having a commanding lead in AOP and threatening with the upcoming AspectJ 5 release (generics and annotations) to blow away even the mechanistic alternatives, it's time for some pre-emptive attacks. Remember, fear breeds in the ignorant, so unless you're talking with someone who has a good understanding of AOP and how new programmers behave, get out the salt. "I used it once for logging" is not qualifying any more.

It's about selling tools and services: for significant systems, you can't get a picture of the entire program by inspecting local code or abstract models, no matter how clean your design. So you will need something. AspectJ takes the language approach, of putting the crosscutting into the code; this is better than using XML or intentional software or generative software because it's closest to the model of looking at source and verbalizing what you want. In any case, whoever defines the language or tools by which significant programs are understood gets the prize. Let's hope that the language approach and free software keeps up, or we'll be back to the days where you have to pay just to play.