But both such cases would be to protect the user, and not to force users to a certain development model favoured by the developer. The developer may well be right in his opinions, but users come from different backgrounds and would not understand they be limited because their way is not neat.
I am sorry if this sounds to harsh, but it really *is* hard enough to find functions which
do what you want them to do. If you then find out those functions are blocked for
some unfathomable (ideologic) reason, you would not be glad.
Well, given the fact that I wrote the bit you're responding to and not Guido I don't think he'll find it harsh ;-)
Oops -- Sorry Guido:)
I don't see much difference between marking something "private" vs. "not for normal access by end users"? In fact I think the "RAD flag" would be a little more liberal than private vs. public since if you needed you could always flag a script as using non-FOM objects, but if the object is private you're going to need the source of the Java object to make the change?
It is not the flag in itself, it is the reason why you would apply it. private as in Java or C++ is used in general for internal helper functions. They tend to be very implementation dependent. A component that really does something also tends to have implementation specific functions. And I do not think it's bad if they stay hidden just *because* their contract tends to fluctuate over versions. So removing them from the namespace is to protect the user. And in that sense - if a function is private, you'd not want other objects to play with the component internals - at all. It may break the component.
But it really could be that I misunderstood things. I understood that developers would make only a portion of the interface available to users, and another portion to developers. That seems quite artificial. Flagging a function needs to have a clear meaning, one readily understood by even the simplest of users (e.g. me). Strong potential to damage your environment, or your objects, as a side effect is something even I can understand.
Maybe I can give a small example: You have a component which can transform a given string into a Base64 encoded, MD5 transformed String. An implementer could just provide the user interface (non-flagged) String convert(String). And hide the utility functions Byte[] md5(Byte[]), String Base64(Byte[]). That would be a shame since then everyone needing a Base64 would have to roll their own (or, in my case, copy-paste from the component source).
The example is a bit artificial, and the syntax is disturbingly Java like:) but javascript does just not have the clear expressions to demonstrate what I want.
On a side note: is it possible to split your javascript file into multiple files, each holding a class-like thingy and integrate them in the main flowscript, using e.g. cocoon.load( uri )?
If I read to much in the statement above I am sorry. But I strongly feel that flow
is a more powerfull technology than xsp for many applications, and that it should be kept simple for users. And simple is not a limited set of functions, but
a feature rich environment which allows you to do what you want without to much
Java (a bit like xsp is now),
Personally, I tend to agree. However, if others feel the need to restrict the contract more than currently I think there should be some kind of escape hatch for developers...
The developer writes the code. The developer owns the code. He or she can do with it what he or she likes. Fortunately, the people who write code for Cocoon seem to be very user-oriented (apart from naturally striving to elegant solutions which is I think quite common to all people who write software), so I'm quite confident that in the end all restrictions placed by developers will truly make sense. I just hope that that sense of the restriction translates into documentation in the source (yes - I do read the source. Grep and find are among my best friends:)
Leon
