No... because you sound like you're on crack, which means I can win without even responding.
It's entirely possible for anti-MS rumormongers to sound very convincing. Just not for you.
(Although, the fact that Microsoft may have been losing a single lawsuit 5 years is hardly biased negatively or positively towards the company. It's rather meaningless, unless you want to be a stickler for details. And in the details- claiming "Microsoft settled a copyright lawsuit for $150 million"- you are wrong)
That's a joke, right? Point to someplace that doesn't mention something, and pretend that means it doesn't exist? Negatives are proven by evidence against, not lack of evidence for. "Omission is not proved by example".
(But notice that the reporter who wrote that article clearly believes an investment did happen. She calls it that.)
Wow! And look, there's even morepagesfrom Microsoft that don't mention piddling investments of less than 0.3% of their cash reserve. And there's many more that also don't mention it. It really must never have happened!
I thought that the Disney corporate logo was a stylized Disney signature?
That seems to be their current favorite logo, but I'm sure in the past some Disney products (like their cable TV channel) were identified by 3 circles forming a mouse head, with no text.
Characters are really a special case in trademarks.
Sure, characters are copyrightable. Everything is copyrightable, since 1987. Well, any visual or audible work is copyrighted, and that includes all the characters it contains. It was only recently that characters started becoming trademarks. The first big example I can recall is George Lucas), and that seems to have been more due to the fact that each character also represented a product (an "action-figure"). Their names represented a commericial product, and thus is an identifier for "trade".
Lets check with the USPTO to see if a movie character (who wasn't made into an action figure) is trademarked: Marty McFly. Nope, although his film was. The legal reason I can't publish a comic-book adventure with Marty and Doc Brown is not that they're trademarked, but because the film I saw them in is still copyrighted.
It'd be like trying to trademark 'Car' with regards to automobiles. That dog don't hunt.
What's that supposed to mean? Disney uses an image of Mickey Mouse (in a monochrome silloette) to identify themselves in some business dealings. This is a trademark, regarding many things beyond "cartoons with Mickey Mouse" (which is hardly a product they care about, anymore). If the character became PD, I could use it in original drawings and animations- just so long as I did not attempt to cause consumers to mistake me for the Walt Disney corporation.
I'm also allowed to make pictures of Apples or Windows- and I can even use them in a computer context. Just as long as I don't name my company that, or try to confuse the public, I'm safe. And the trademark-holders aren't threatened.
(Well, mega-corps can feel threatened at anything, and may fire off lawsuits at a whim, but by legal theory, it shouldn't bother them)
Yeah, and look at what a profitable company Mirabilis became because of it!
This is irrelevant, the point is that innovation occured, without needing the incentive of patents, or any kind of guarantee of income.
However, Mirabilis was very profitable. They got a big cash buy-out from AOL. The internet-craze jackpot. $100s of millions for a handful of employees. Much more than they were worth, and so far AOL still hasn't figured out how to earn money on that stuff.
(Note, if you read the press release, it is incorrect about some things. The developement of ICQ wasn't "accelerated", it was halted (on the desktop platform), so that it wouldn't lure customers away from AOL's nascent offering. AOL felt it was absorbing what could've been a major potential competitor, 5 years later)
Can you produce any newspaper story, then, to prove that there ever was a Microsoft/Apple copyright lawsuit ongoing in 1997, when this alleged "settlement" occured? Microsoft firmly won a copyright suit in 1994, were there more since then?
MS spun press release over sealed court documents.
And why should I belive anything about a "sealed" court document? There's no way you can (legally) prove it ever existed.
Apple co-authored those press-releases too, you know. It was during their MacWorld speech that the "investment" was announced. I guess you call them liars too.
How many more examples would you like to try and dispute?
(I had been using "instant messaging" in quotes in acknowledgement of the fuzzy ways the boundaries of that idea can be interpreted)
However, the critical advancement of Mirabilis ICQ was not the messaging part- it was the "presence indicators" (or "buddy list", it's popularly called). A truely GUI innovation- unobtrusively allowing people to indicate to others when they were able to chat, with little affirmative effort from either party.
The achievement of the "Contact List" was more technically difficult, and required more imagination and inventiveness, than the actual sending of messages.
ICQ is not similar to "talk". In fact, "finger" comes closer to being prior art for it. (And "watch finger" comes closer still, although it still lacks the distributed nature which scales the idea up to thousands of hosts and makes the lists truely useful)
Get your facts right before correcting someone on history.
The 1997 investment (what else can you call buying shares on the stock market?) of $150 mil wasn't a lawsuit settlment. And there had been no copyright lawsuit between the two companies anyhow.
That transaction was a deal between the CEOs of the two companies. Amoung other things, it included an agreement to share patents, which lead to a patent lawsuit being dropped. And, it got Microsoft's Internet Explorer preinstalled on every Mac, which was a tactical move to stifle development of competing web browsers.
(We can only speculate as to what other private arrangements were made to secure that cash- it might've included Apple withholding damaging evidence for the anti-trust trial)
it was micro$o~1 that stole the idea and look of the recycle bin
To "steal" something, the original owner mustn't have it anymore. Microsoft using a similar look didn't stop Apple from using it.
Also, they obviously didn't copy the look (or name) of the recycle bin, since Apple never had something looking like that (or called that!)
And the feel isn't identical either. (No Windows(tm) user drags a floppy or CD into the Recycle Bin)
Defeating the Look & Feel lawsuit was one of the best things Microsoft ever did for the computer programmers of the world. Otherwise, every competing program would be forced to use an entirely different interface from every other.
When a new user sat down at a new spreadsheet or checkbook program, the one thing she'd be sure of is that the controls work differently from every single program of that category she'd ever used- that would be illegal.
Things like Instant Messaging and weighted search results are of such obviously high usefulness that they would be invented, regardless of the inventor thinking he would be able to get patent protection.
In fact, your very example has disproved you, for ICQ very willingly invented and published "Instant Messenging" techniques without any protection, and there were many immediate copies (AOL, Microsoft, and others). Yet, even knowing they had no way to prevent clones, Mirabilis still went ahead and created the field.
It's not used to identify someone for purposes of trade, though. The name of a company, or images used to represent a specific company (logos or mascots) may be trademarks.
But the Apple Wastebasket isn't used as an identifier in any commercial situation- it represents neither a saleable product, nor anyone who can sell a product.
Also, trademark infringement only occurs if you duplicate the image for "trade". Thus most trademarked images are also copyrighted. That's why Disney was worried about Mickey Mouse's copyright expiring- that would've allowed people to duplicate their corporate logo, as long as it wasn't used to identify a company or product.
(That's also related to how Apple was able to get the trademark "Apple", even though there already was a company of that name. But their products didn't overlap at all...)
Quibbling over 2-3 lines from simple macros isn't valuable. However, if I had written debug macros like that, I'd have gone like this: // Master enable/disable #define LOG_SOUND 1// Specific logging #if LOG_SOUND == 1 #define LOG_SOUND_UPLOAD 1 #define LOG_SOUND_CREATE 0 #define LOG_SOUND_PLAY 0 #else #define LOG_SOUND_UPLOAD 0 #define LOG_SOUND_CREATE 0 #define LOG_SOUND_PLAY 0 #endif
That transitions a little complexity (and code size) out of each function, and concentrates it at the macro setup in the top of the file. Then as an additional step, I'd do this:
In this case, each function only has 1 line added to it, instead of 3. And instead of having #if going out to column 0, everything in the function body is indented consistently. (The all-caps is still a sufficient hint to readers that they're looking at a macro, not a function-call)
You don't need a DEBUG_LOG in *every* function. Only the ones that you are interested in.
The idea is, that in a multi-programmer project, the guy who writes the functions doesn't know what other people might care about. He's either got to add a debug macro to each one, or expect other people to do this for him later.
In many projects, that isn't a problem at all. But some people will get disturbed by this, it depends on your organization. Developers of real-time systems are less likely to care.
The logging doesn't add THAT much to the code size
The size of the outputted program isn't what we're talking about. I mean the size of the source code.
The supposed advantage of Aspect Orientation is that when you add logging (or some other "cross-cutting" feature) to a class, it only takes a constant number of lines of of code. Otherwise, it would take lines of code proportional to the number of methods in the class. And when more methods are added, more lines.
Ideally, AO should allow a Bob to add features to all the functions Adam wrote in a class, and later when Adam writes more functions, Bob's features will automatically apply. (Without Adam ever needing to know that someone else is logging his calls)
I don't know details like that (AOP is not 100% defined yet, implementations may vary).
And AOP is used more during program building, so this problem would apply to a commercial library, not a finished executable. (Otherwise, it's just like asking "What keeps an end user from from calling functions in my programs?"- the fact that they're completely undocumented and unsupported, that's what)
Now, regarding a library written with AOP style- maybe there is nothing to stop the user from extending it. And maybe this is a good thing.
(In all likelihood, though, AOP can only work if you have the source code, or a least a non-obfuscated binary like Java classes. In which case, the user could effect his changes anyhow by just modifying the code, or de-compiling it and editing that)
They certainly wouldn't approve of manually adding hooks everyplace, which is what AOP tries to avoid (while still giving the programmer the power as if that had been done)
How far would AOP meet with his approval? Good enough, it seems. Dijkstra's criteria for allowing a feature into a language was how much it complicated the description of the "cursor position" ("textual index point") of a program at a certain time. Gotos are bad, because they make the size required to describe that position unbounded (the full history of all previous goto jumps). Structured programming, with nested blocks and function calls, keeps the size limited, because the position-descriptor shrinks when you leave a block. (As long as there's no infinite recursion, but even that can sometimes be handled)
AOP's effect on the execution graph is the same as function calls. It's just the calling of functions, but the calls themselves are implicit and invisible. The textual index size is only increased by a small constant factor per aspect called, and that size is recovered when it's done.
Like when taught recursion with the factorial example.
That all depends on if the student is a math major, or in software-eng. Math guys find induction functions clear and beautiful.
For the logging example, macros (I'm thinking in C++) seem to work better.
C++ preprocessor macros are a reasonable way to emulate some AOP behavior, but they have many drawbacks. Using something like your DEBUG_LOG means that as all the functions are written, a programmer has to remember to add these macros to each one. Negative effects:
This creates an opportunity for human error. If DEBUG_LOG is forgotten from a function, you might not realize it, and falsely trust a logfile that says it wasn't called
Limited flexibility. Ok, you've got DEBUG_LOG in every function. What if you want to change the logging to only happen on one function, on functions that write to data structures (not read it), on functions that are suspected to be slow? To support this kind of thing, you'd need to change the DEBUG_LOG in every single call. (Some people do this. They give DEBUG_LOG an integer argument, which is masked against a debugging variable set at program startup. That's still limited)
Once every single function has a macro in it, the total length of the program has increased. ("Yay! More SLOC, I've met this week's quota"). But the length the functions have gained is not related to computing the output of the function, it is for a totally different purpose. It makes the code (slightly) harder to read, write, and understand. (Do you love it when an argument to DEBUG_LOG accidently gets a side-effect in there? I sure do!)
With only one kind of macro, it's no big deal, readers see the macro as just "another standard piece of every function definition". But if more flexibility is desired, then other kinds of macros float in, increasing ugliness and raising the percentage of each function body that doesn't directly contribute to the output of the function.
But yes, logging and santity checking are prehaps too simple examples to present the concept's power. (Drawing circles and square's is also a poor demonstration of the benefits of OOP, but all introductory lessons use it)
With aspects the code would read like a book with the first and last few dozen pages missing.
The output of the program is still fully determined by the source code, so no pages are missing. Instead (this is how it should work, IDK in practice), the authors gave general directions on how to perform a category of tasks, rather than repeating those instructions in each and every recipe. ("And if you're diabetic, do this. And for kosher food, do this. And if you're at above 3km altitude...")
The "delegation pattern" may be somewhat similar, but because it's a "pattern"- a repetitive process that a programmer does again and again- it's still bad.
There's quite a bit of repetitive code created (copied & pasted, then search & replaced) when you make a delegator. Hopefully, Aspect-Oriented would let you skip the mechanical work of writing a delegator, and just get on to using it.
You might describe it as the programming language compiler becoming aware of a pattern, and learning to implement it when told.
Seems in a large project it would be real easy to forget about code that executes that you cant see.
The nice thing, then, would be a smart editor which is aware of aspects, and can draw flags on top of the source code you're reading so that the programmer is warned that an Aspect will be sticking it's nose in.
Even better, you could click those flags to apparently expand the aspect's code inline, revealing exactly what statements will execute when the function runs. Of course, this can't be reliably done in all cases, if the Aspects are something that can be toggled on/off as the program runs.
In that case, the editor might have to be pessimistic, and assume "an Aspect might apply here...". But that might not work well either. In the end, you need smart programmers, both writing the aspects, and using them.
That only works in OOP if you actually are creating a derived class (and, depending on language, if the other programmer didn't make it a "final" method)
In AOP, you can decide to apply pre/post behaviors to a bunch of methods without needing to first create inherited classes, and then change the construction-calls ("new MyOverRiddenObject") to make those new classes.
I've read a few papers, but never managed to pay much attention. However I tried to put it in terms of how you might accomplish such effects with a traditional programming langauge.
Basically, imagine if you wrote a program which had "hooks" scattered through it. As you write your code, you place hooks for before/after doing many things: reading user input, transmitting network data, accessing preference files, checking permissions, etc. (Imagine wrapping all your function calls with dynamically-bound functions which you don't yet know if map to an identity function, or have some effect)
Other parts of the program can then hook into these things and effect how your program runs, without them having to go through and modify your code. (Example: if they want to log a message to file everytime your "CastRay()" function is called, they can do this without going in and editing your code).
Now, imagine than rather than the programming having to plan ahead to scatter hooks all around his code (uglifying it towards readers who don't care about them), they are inserted automatically by the compiler.
So a person can create a function which will be automatically called whenever some other set of 3 different functions is called, without having to go modify each one. Instead of going to each function body and adding a call, he at one position attaches his code to functions of that kind. The program is shorter, but has more effects. This may mean, when all goes well, that if someone adds a new function with similar effects, those hooks may still get called.
Now, is all this a code idea? It's hard to say, Aspect-Oriented programming (like OO programming) is yet another way for a program to do things without the source code making it abundantly clear. In OO, if you see one method A call method B, you must check the source code for all base classes to see if and how B was virtually overridden, a complexity that didn't exist before. Now, with AOP, you must be aware "is this behavior creating a context which will cause some Aspect to add in more effects"?
In both those cases, the program is doing things that the source code doesn't make 100% clear to a programmer reading a single function body. This can be either good or bad. The usage of editing tools which evaluate the code and alert the reader to these facts (analogous to "class browsers" in several IDEs) shift it much further towards "good".
Sure I don't like having lasers in orbit any more then anyone else but just like Air Superiority is important, so is space superiority.
It's not a matter of getting them into orbit (the shuttle isn't needed to launch satellites, in fact it never could launch a military satellite), but of inventing them. Laser-weapon satellites do not exist, and won't exist anytime soon.
And, if they're ever created, they'll be so vulnerable to ground-based lasers that they'll be militarly worthless (unless they are simply used to cement a pre-existing Pax Americana)
Satellites with laser weapons will always be more vulnerable to attack from the ground than ground targets will be from them.
We can build a laser weapon today, but it's huge, and the power-supply needs are enormous. Size and electricity aren't problems on the ground, but they are in space.
If at any point someone manages to build a laser satellite, he'll already have the technology to construct ground-based laser defenses, which have the added benefit of being hidden below-ground until being needed.
By the time the US got a laser satellite in orbit, North Korea could have equivalently powerful laser beams in underground chambers. A few months before the attack, their astronomers can pinpoint the location of every satellite in the sky. If there's any suspicion there are weapons up there, destroying all enemy satellites will be the first step of any aggression.
Weaponizing space will ensure that in any future combat between 2 advanced nations, our existing civilian satellite infrastructure will be devastated. It might be better for everyone if orbits could be declared a safe zone- as many sensors and transmitters as anybody wants, but no weapons.
Slashdot Mirror
Giving in so easy?
No... because you sound like you're on crack, which means I can win without even responding.
It's entirely possible for anti-MS rumormongers to sound very convincing. Just not for you.
(Although, the fact that Microsoft may have been losing a single lawsuit 5 years is hardly biased negatively or positively towards the company. It's rather meaningless, unless you want to be a stickler for details. And in the details- claiming "Microsoft settled a copyright lawsuit for $150 million"- you are wrong)
That's a joke, right? Point to someplace that doesn't mention something, and pretend that means it doesn't exist? Negatives are proven by evidence against, not lack of evidence for. "Omission is not proved by example".
(But notice that the reporter who wrote that article clearly believes an investment did happen. She calls it that.)
Wow! And look, there's even more pages from Microsoft that don't mention piddling investments of less than 0.3% of their cash reserve. And there's many more that also don't mention it. It really must never have happened!
I thought that the Disney corporate logo was a stylized Disney signature?
That seems to be their current favorite logo, but I'm sure in the past some Disney products (like their cable TV channel) were identified by 3 circles forming a mouse head, with no text.
Characters are really a special case in trademarks.
Do you have any source on this? I sure don't.
Characters aren't copyrightable, they're trademarked.
Sure, characters are copyrightable. Everything is copyrightable, since 1987. Well, any visual or audible work is copyrighted, and that includes all the characters it contains. It was only recently that characters started becoming trademarks. The first big example I can recall is George Lucas), and that seems to have been more due to the fact that each character also represented a product (an "action-figure"). Their names represented a commericial product, and thus is an identifier for "trade".
Lets check with the USPTO to see if a movie character (who wasn't made into an action figure) is trademarked: Marty McFly. Nope, although his film was. The legal reason I can't publish a comic-book adventure with Marty and Doc Brown is not that they're trademarked, but because the film I saw them in is still copyrighted.
It'd be like trying to trademark 'Car' with regards to automobiles. That dog don't hunt.
What's that supposed to mean? Disney uses an image of Mickey Mouse (in a monochrome silloette) to identify themselves in some business dealings. This is a trademark, regarding many things beyond "cartoons with Mickey Mouse" (which is hardly a product they care about, anymore). If the character became PD, I could use it in original drawings and animations- just so long as I did not attempt to cause consumers to mistake me for the Walt Disney corporation.
I'm also allowed to make pictures of Apples or Windows- and I can even use them in a computer context. Just as long as I don't name my company that, or try to confuse the public, I'm safe. And the trademark-holders aren't threatened.
(Well, mega-corps can feel threatened at anything, and may fire off lawsuits at a whim, but by legal theory, it shouldn't bother them)
Yeah, and look at what a profitable company Mirabilis became because of it!
This is irrelevant, the point is that innovation occured, without needing the incentive of patents, or any kind of guarantee of income.
However, Mirabilis was very profitable. They got a big cash buy-out from AOL. The internet-craze jackpot. $100s of millions for a handful of employees. Much more than they were worth, and so far AOL still hasn't figured out how to earn money on that stuff.
(Note, if you read the press release, it is incorrect about some things. The developement of ICQ wasn't "accelerated", it was halted (on the desktop platform), so that it wouldn't lure customers away from AOL's nascent offering. AOL felt it was absorbing what could've been a major potential competitor, 5 years later)
Can you produce any newspaper story, then, to prove that there ever was a Microsoft/Apple copyright lawsuit ongoing in 1997, when this alleged "settlement" occured? Microsoft firmly won a copyright suit in 1994, were there more since then?
MS spun press release over sealed court documents.
And why should I belive anything about a "sealed" court document? There's no way you can (legally) prove it ever existed.
Apple co-authored those press-releases too, you know. It was during their MacWorld speech that the "investment" was announced. I guess you call them liars too.
How many more examples would you like to try and dispute?
None, those are totally irrelevant to this topic.
(I had been using "instant messaging" in quotes in acknowledgement of the fuzzy ways the boundaries of that idea can be interpreted)
However, the critical advancement of Mirabilis ICQ was not the messaging part- it was the "presence indicators" (or "buddy list", it's popularly called). A truely GUI innovation- unobtrusively allowing people to indicate to others when they were able to chat, with little affirmative effort from either party.
The achievement of the "Contact List" was more technically difficult, and required more imagination and inventiveness, than the actual sending of messages.
ICQ is not similar to "talk". In fact, "finger" comes closer to being prior art for it. (And "watch finger" comes closer still, although it still lacks the distributed nature which scales the idea up to thousands of hosts and makes the lists truely useful)
Get your facts right before correcting someone on history.
The 1997 investment (what else can you call buying shares on the stock market?) of $150 mil wasn't a lawsuit settlment. And there had been no copyright lawsuit between the two companies anyhow.
That transaction was a deal between the CEOs of the two companies. Amoung other things, it included an agreement to share patents, which lead to a patent lawsuit being dropped. And, it got Microsoft's Internet Explorer preinstalled on every Mac, which was a tactical move to stifle development of competing web browsers.
(We can only speculate as to what other private arrangements were made to secure that cash- it might've included Apple withholding damaging evidence for the anti-trust trial)
it was micro$o~1 that stole the idea and look of the recycle bin
To "steal" something, the original owner mustn't have it anymore. Microsoft using a similar look didn't stop Apple from using it.
Also, they obviously didn't copy the look (or name) of the recycle bin, since Apple never had something looking like that (or called that!)
And the feel isn't identical either. (No Windows(tm) user drags a floppy or CD into the Recycle Bin)
Defeating the Look & Feel lawsuit was one of the best things Microsoft ever did for the computer programmers of the world. Otherwise, every competing program would be forced to use an entirely different interface from every other.
When a new user sat down at a new spreadsheet or checkbook program, the one thing she'd be sure of is that the controls work differently from every single program of that category she'd ever used- that would be illegal.
Things like Instant Messaging and weighted search results are of such obviously high usefulness that they would be invented, regardless of the inventor thinking he would be able to get patent protection.
In fact, your very example has disproved you, for ICQ very willingly invented and published "Instant Messenging" techniques without any protection, and there were many immediate copies (AOL, Microsoft, and others). Yet, even knowing they had no way to prevent clones, Mirabilis still went ahead and created the field.
It's not used to identify someone for purposes of trade, though. The name of a company, or images used to represent a specific company (logos or mascots) may be trademarks.
But the Apple Wastebasket isn't used as an identifier in any commercial situation- it represents neither a saleable product, nor anyone who can sell a product.
Also, trademark infringement only occurs if you duplicate the image for "trade". Thus most trademarked images are also copyrighted. That's why Disney was worried about Mickey Mouse's copyright expiring- that would've allowed people to duplicate their corporate logo, as long as it wasn't used to identify a company or product.
(That's also related to how Apple was able to get the trademark "Apple", even though there already was a company of that name. But their products didn't overlap at all...)
Your name almost looks like the guy on #debian who argued about RTFM last night...
That's Sun's opinion, but disregard for operator-overloading is by no means universal.
Only dumb programmers become any more confused by operator overloading than by other kinds of overloaded functions.
I don't want to reduce the effectiveness of the smart ones by sheparding the stupid.
Quibbling over 2-3 lines from simple macros isn't valuable. However, if I had written debug macros like that, I'd have gone like this:
// Master enable/disable // Specific logging
:
// Master enable/disable // Specific logging
:
#define LOG_SOUND 1
#if LOG_SOUND == 1
#define LOG_SOUND_UPLOAD 1
#define LOG_SOUND_CREATE 0
#define LOG_SOUND_PLAY 0
#else
#define LOG_SOUND_UPLOAD 0
#define LOG_SOUND_CREATE 0
#define LOG_SOUND_PLAY 0
#endif
Sound::Play()
{
#if LOG_SOUND_PLAY
printf( "Playing..." )
#endif
}
That transitions a little complexity (and code size) out of each function, and concentrates it at the macro setup in the top of the file. Then as an additional step, I'd do this:
#define LOG_SOUND 1
#if LOG_SOUND == 1
#define LOG_SOUND_UPLOAD(x) printf x
#define LOG_SOUND_CREATE(x)
#define LOG_SOUND_PLAY(x)
#else
#define LOG_SOUND_UPLOAD(x)
#define LOG_SOUND_CREATE(x)
#define LOG_SOUND_PLAY(x)
#endif
Sound::Play()
{
LOG_SOUND_PLAY(("Playing..."));
}
In this case, each function only has 1 line added to it, instead of 3. And instead of having #if going out to column 0, everything in the function body is indented consistently. (The all-caps is still a sufficient hint to readers that they're looking at a macro, not a function-call)
You don't need a DEBUG_LOG in *every* function. Only the ones that you are interested in.
The idea is, that in a multi-programmer project, the guy who writes the functions doesn't know what other people might care about. He's either got to add a debug macro to each one, or expect other people to do this for him later.
In many projects, that isn't a problem at all. But some people will get disturbed by this, it depends on your organization. Developers of real-time systems are less likely to care.
The logging doesn't add THAT much to the code size
The size of the outputted program isn't what we're talking about. I mean the size of the source code.
The supposed advantage of Aspect Orientation is that when you add logging (or some other "cross-cutting" feature) to a class, it only takes a constant number of lines of of code. Otherwise, it would take lines of code proportional to the number of methods in the class. And when more methods are added, more lines.
Ideally, AO should allow a Bob to add features to all the functions Adam wrote in a class, and later when Adam writes more functions, Bob's features will automatically apply. (Without Adam ever needing to know that someone else is logging his calls)
I don't know details like that (AOP is not 100% defined yet, implementations may vary).
And AOP is used more during program building, so this problem would apply to a commercial library, not a finished executable. (Otherwise, it's just like asking "What keeps an end user from from calling functions in my programs?"- the fact that they're completely undocumented and unsupported, that's what)
Now, regarding a library written with AOP style- maybe there is nothing to stop the user from extending it. And maybe this is a good thing.
(In all likelihood, though, AOP can only work if you have the source code, or a least a non-obfuscated binary like Java classes. In which case, the user could effect his changes anyhow by just modifying the code, or de-compiling it and editing that)
They certainly wouldn't approve of manually adding hooks everyplace, which is what AOP tries to avoid (while still giving the programmer the power as if that had been done)
How far would AOP meet with his approval? Good enough, it seems. Dijkstra's criteria for allowing a feature into a language was how much it complicated the description of the "cursor position" ("textual index point") of a program at a certain time. Gotos are bad, because they make the size required to describe that position unbounded (the full history of all previous goto jumps). Structured programming, with nested blocks and function calls, keeps the size limited, because the position-descriptor shrinks when you leave a block. (As long as there's no infinite recursion, but even that can sometimes be handled)
AOP's effect on the execution graph is the same as function calls. It's just the calling of functions, but the calls themselves are implicit and invisible. The textual index size is only increased by a small constant factor per aspect called, and that size is recovered when it's done.
That all depends on if the student is a math major, or in software-eng. Math guys find induction functions clear and beautiful.
For the logging example, macros (I'm thinking in C++) seem to work better.
C++ preprocessor macros are a reasonable way to emulate some AOP behavior, but they have many drawbacks. Using something like your DEBUG_LOG means that as all the functions are written, a programmer has to remember to add these macros to each one. Negative effects:
With only one kind of macro, it's no big deal, readers see the macro as just "another standard piece of every function definition". But if more flexibility is desired, then other kinds of macros float in, increasing ugliness and raising the percentage of each function body that doesn't directly contribute to the output of the function.
But yes, logging and santity checking are prehaps too simple examples to present the concept's power. (Drawing circles and square's is also a poor demonstration of the benefits of OOP, but all introductory lessons use it)
With aspects the code would read like a book with the first and last few dozen pages missing.
The output of the program is still fully determined by the source code, so no pages are missing. Instead (this is how it should work, IDK in practice), the authors gave general directions on how to perform a category of tasks, rather than repeating those instructions in each and every recipe. ("And if you're diabetic, do this. And for kosher food, do this. And if you're at above 3km altitude...")
then you and everyone else on your team are doing AOP in a bad way.
You'd think my team uses it? We're CMM SEI Level 5, man. We don't touch a new paradigm until it's got 12 years of proven applications under it's belt!
The brackets are the code!
The "delegation pattern" may be somewhat similar, but because it's a "pattern"- a repetitive process that a programmer does again and again- it's still bad.
There's quite a bit of repetitive code created (copied & pasted, then search & replaced) when you make a delegator. Hopefully, Aspect-Oriented would let you skip the mechanical work of writing a delegator, and just get on to using it.
You might describe it as the programming language compiler becoming aware of a pattern, and learning to implement it when told.
Seems in a large project it would be real easy to forget about code that executes that you cant see.
The nice thing, then, would be a smart editor which is aware of aspects, and can draw flags on top of the source code you're reading so that the programmer is warned that an Aspect will be sticking it's nose in.
Even better, you could click those flags to apparently expand the aspect's code inline, revealing exactly what statements will execute when the function runs. Of course, this can't be reliably done in all cases, if the Aspects are something that can be toggled on/off as the program runs.
In that case, the editor might have to be pessimistic, and assume "an Aspect might apply here...". But that might not work well either. In the end, you need smart programmers, both writing the aspects, and using them.
That only works in OOP if you actually are creating a derived class (and, depending on language, if the other programmer didn't make it a "final" method)
In AOP, you can decide to apply pre/post behaviors to a bunch of methods without needing to first create inherited classes, and then change the construction-calls ("new MyOverRiddenObject") to make those new classes.
I've read a few papers, but never managed to pay much attention. However I tried to put it in terms of how you might accomplish such effects with a traditional programming langauge.
Basically, imagine if you wrote a program which had "hooks" scattered through it. As you write your code, you place hooks for before/after doing many things: reading user input, transmitting network data, accessing preference files, checking permissions, etc. (Imagine wrapping all your function calls with dynamically-bound functions which you don't yet know if map to an identity function, or have some effect)
Other parts of the program can then hook into these things and effect how your program runs, without them having to go through and modify your code. (Example: if they want to log a message to file everytime your "CastRay()" function is called, they can do this without going in and editing your code).
Now, imagine than rather than the programming having to plan ahead to scatter hooks all around his code (uglifying it towards readers who don't care about them), they are inserted automatically by the compiler.
So a person can create a function which will be automatically called whenever some other set of 3 different functions is called, without having to go modify each one. Instead of going to each function body and adding a call, he at one position attaches his code to functions of that kind. The program is shorter, but has more effects. This may mean, when all goes well, that if someone adds a new function with similar effects, those hooks may still get called.
Now, is all this a code idea? It's hard to say, Aspect-Oriented programming (like OO programming) is yet another way for a program to do things without the source code making it abundantly clear. In OO, if you see one method A call method B, you must check the source code for all base classes to see if and how B was virtually overridden, a complexity that didn't exist before. Now, with AOP, you must be aware "is this behavior creating a context which will cause some Aspect to add in more effects"?
In both those cases, the program is doing things that the source code doesn't make 100% clear to a programmer reading a single function body. This can be either good or bad. The usage of editing tools which evaluate the code and alert the reader to these facts (analogous to "class browsers" in several IDEs) shift it much further towards "good".
Sure I don't like having lasers in orbit any more then anyone else but just like Air Superiority is important, so is space superiority.
It's not a matter of getting them into orbit (the shuttle isn't needed to launch satellites, in fact it never could launch a military satellite), but of inventing them. Laser-weapon satellites do not exist, and won't exist anytime soon.
And, if they're ever created, they'll be so vulnerable to ground-based lasers that they'll be militarly worthless (unless they are simply used to cement a pre-existing Pax Americana)
Satellites with laser weapons will always be more vulnerable to attack from the ground than ground targets will be from them.
We can build a laser weapon today, but it's huge, and the power-supply needs are enormous. Size and electricity aren't problems on the ground, but they are in space.
If at any point someone manages to build a laser satellite, he'll already have the technology to construct ground-based laser defenses, which have the added benefit of being hidden below-ground until being needed.
By the time the US got a laser satellite in orbit, North Korea could have equivalently powerful laser beams in underground chambers. A few months before the attack, their astronomers can pinpoint the location of every satellite in the sky. If there's any suspicion there are weapons up there, destroying all enemy satellites will be the first step of any aggression.
Weaponizing space will ensure that in any future combat between 2 advanced nations, our existing civilian satellite infrastructure will be devastated. It might be better for everyone if orbits could be declared a safe zone- as many sensors and transmitters as anybody wants, but no weapons.
Do you know what != means?
"Old engine is not equal to bad game"