cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leon Widdershoven <...@dds.nl>
Subject Re: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Date Tue, 20 Apr 2004 07:11:54 GMT
<snip/>

>>
>>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


Mime
View raw message