Leon,

Being a developer is like ... being a Jedi Knight. You seek the good and thrive on it, but are forever tempted by the dark side. Eventually, you give in to it and learn why it's evil and then go back to the light. That is, unless you're so enthralled by the dark side that you become consumed by it. Such actions my well lead to one's demise though - especially if a Skywalker is around.

To put it different, it's like being a woodworker. The machines you use are stupid and emotionless. They have guards in place for a reason. The woodworker can remove the guards because they're "in the way", but he has nobody but himself to blame when he cuts his finger off.

I've heard this argument too many times.  "The language should ... "

Yes, I realize that there are folks who'd probably kill themselves in an afternoon if they were the woodworker above, but that's their business. Some people like living on the edge and think it's cool to write obfuscated code. Their reward will be dismissal if they don't mend their ways before someone comes along that can write clean implementations that people can come behind and maintain.

Shift responsibility to where it belongs - to the critter that has grey matter keeping its skull from collapsing - the developer. Yes, yes, make use of the tools a language gives you to write better, cleaner, more maintainable code ... but having the power to slit your wrists can actually come in handy sometimes. Pointer arithmetic (the one feature missing from Java. Yes, java has pointers, and please don't bore me by trying to prove otherwise :-) is the one feature I miss from the old "C days", and it can be a very elegant solution to certain problems --- just like recursion (which I try to use sparingly as well).

Enough :-) I like power. Java has enough, and makes up for what it doesn't have by adding other cool functionality. In the end, it's the responsibility of the developer to do what's right.

Peace All,

Eddie

----- Original Message ----- From: "Rosenberg, Leon" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Monday, November 15, 2004 7:44 AM
Subject: AW: talking about paradigms





> No, but what about
>
> <c:out value="${library.books[25].page[5].title}" /> ?
> (not sure about the syntax).
whats the problem?
 MVC usually allows 'read-only access to model' for the view
Also the question is, what you expose to the view.
If you are afraid that somebody will misuse the library entries -
don't
expose them.
I suppose MVC was the reason for JSP EL not to allow arbitrary method
invocations. But I'd love to have such anyway ;)

>...
> And what about database access tags?
You mean the jstl tags? They are there for quick and dirty.
If you don't change anything in the database though, it still okay to
MVC.
If you don't want it, don't expose your database in the first place ;)



The problem is, that if you give a user the possibility to misuse your framework - he will. And EL gives jsps more power than a dumb view should have. And if your view isn't just layouting out the data, but performing nearly complex operations, it's not dumb anymore, and a smart view doesn't fit into the MVC.

If the user is allowed to break the paradigm he will.
If you have an architecture, which is built on a paradigm (and any good
architecture is) you can't allow the developers to break the paradigm,
or
the architecture will stop working one day, without obvious reasons.
It's probably why there are no pointers in java, even pointers adds cool
features to the language.

Regards
Leon


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



---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0447-0, 11/15/2004
Tested on: 11/15/2004 8:26:28 PM
avast! - copyright (c) 2000-2004 ALWIL Software.
http://www.avast.com




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



Reply via email to