But not in the way it is implemented. It's much more like a service, in that it's not the protocol handler which decides when it is appropriate to use it. Or so it seems to me.--Ilja Preuss You are perfectly right and that's why I quoted the word "aspect". In the most general sense, an aspect is a unit of modularization for a crosscutting concern. This unit might as well be proactive or completely passive, it all depends on how it is implemented and which goals it pursues. Today, we suffer from AspectJ's definition of an aspect and we fail to recognize other kinds of aspects (and realizations thereof) when they come up. Moreover, the way something is implemented does not drive the way the paradigm should be interpreted but the other way around. To follow up on the protocol handler example, in J2ME you use a Connection object and you don't really know what protocol underlies your connection, all you know (and what matters) is that you have a connection and that you can communicate with the rest of the world. The protocol handler in CLDC decides how to handle the bytes you send to it. Finally, from thefreedictionary.com:
[...] But many systems have properties that don't necessarily align with the system's functional components, such as failure handling, persistence, communication, replication, coordination, memory management, or real-time constraints, and tend to cut across groups of functional components. [...]
In other words, the aspect-oriented paradigm tends to see communication (which are handled by protocol handlers) as a crosscutting concern of a system, and thus, an aspect of the system in the AOP sense. [ May 11, 2004: Message edited by: Valentin Crettaz ]
Originally posted by Valentin Crettaz: I don't know about you, but I really enjoy this discussion.--Valentin Crettaz Ditto! --Ilja Preuss Your sympathy for this debate seems to be fading way, or so it seems :roll:
It's more a matter of time constraints - answering your earlier post is still on my todo list, but I want to give it the time it deserves...
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Partly! The programming language is just one means we have invented to communicate our ideas to computers. I feel that the way we use programming languages these days is very limitative. Maybe I ask too much from them, but you have to agree that as soon as the system grows in size and becomes substantially big (50-100'000 LOC) you cannot have an overall view of the system, and thus, you cannot be sure that your code properly reflects what it has been written for. All I'm saying is that the code is good but we really lack *something* to assess it against. Nowadays we use test cases, this is good, but still not enough.
[ May 03, 2004: Message edited by: Valentin Crettaz ][/QB]
Big code is an issue related to brain power and code design. I can get my head around a million lines of well written code, but about what you specified of poorly written code.
Some very famous people from history have used the term "my brain is full". I have had that feeling before, but in reality you can learn more at the cost of old information access. The older memories don't go away they just usually get harder to recall once you get that full brain feeling. It hit me when I was around 30. Most famous people in history when they where 50 or older, but they did not have near the information we deal with. In a few more years you will have kids getting that full brain feeling.
This has been a huge limiting factor for foreign language people for a long time. Usually most people are limitied to seven human languages. Only a few make the ever increasing effort to learn beyond the full brain feeling.