Leon Widdershoven <[EMAIL PROTECTED]> writes: <snip/> > > > 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...?? <snip/>
