Niclas Hedhman wrote:

On Thursday 18 March 2004 22:55, Berin Loritsch wrote:

You know, that article that Bruce Eckel produced
(http://mindview.net/WebLog/log-0051) was thought provoking.  Should
there be additional semantic meaning to an interface?  I used to think
so, but now I don't.

An interface is all you can enforce in code, and all you should expect
the user to respect.  But that's just me.


1. I start thinking you are on drugs. :o)

Sufedrin to be exact... ;D



2. As Jonathan points out, what is the method .remove() supposed to do? Start WarCraft and reformat the hard disk?

Did you catch the link to the WIKI describing enabling and restrictive approaches? There are two schools of thought here that we ascribe to. Neither are wrong, but they come from opposite minds.

Basically if someone is a true anarchist (not me mind you) then they will
find a way to circumvent all the controls you have put in place.  Eventually,
you can get to the place where all these preventative controls can actually
constrain someone who is trying to solve a legitimate problem so much that
they cannot use the project.

One of the key points there was that the actual occurance of abuse is lower
than many people seem to attribute.  I like software to enable me, not restrict
me.  Granted, if there is something truly damning that I can do inadvertently,
I would expect there to be problems and for the framework to alert me to it.
However, if the framework is designed properly I should really know when I am
circumventing it.

3. Service != interface -=-=> The Service carries with it a lot more than the Java interface, incl. the semantics, meta information, documentation, and preferably compliance tests.

Yeah, I was in that camp too. Think about it though. You cannot impose semantic meaning without actual code. Therefore, the only time there is semantic meaning is when there is code. In this case, the java interface and the compliance tests are the only thing with meaning. The meta information only gains meaning when the container respects it and acts accordingly.

Don't get me wrong, I am for a complete enough definition of a service to
actually get some work done, but I don't want to have to remember a hundred
different things to make it work.

You can't call yourself a proponent of re-use... Especially since re-use is also a restriction, and you seem to take everything to the extreme edge, such restriction can't be good, so don't use it. Make your own bolts to fit your holes, will ya...

Well, I can call myself one, but we have a difference of oppinion on what constitutes re-use. Perhaps I am jaded by the fact that up to now near 100% or even 80% re-use has been a pipe dream. There are many reasons for that. Some of them come down to legal/monetary/non-code related issues. Some of them come down to ignorance of what is available. More often than not, it comes down to something being close to what is needed, but not quite. So I take a more pragmatic approach and realize I can only re-use so much.

Change happens, if you don't plan for it, you are essentially nailing your
own coffin.  I like re-use, but I also like to do so in a way that can be
managed and provide for future growth.


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to