cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@STJUDE.ORG>
Subject RE: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)
Date Tue, 20 Apr 2004 17:55:43 GMT
Leon Widdershoven <> writes:

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

I wasn't thinking of anything that granular, just an all or nothing
switch; script X can or cannot access things outside the FOM... 

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

Not sure quite what your asking or if it is possible...??


View raw message