[PEAK] What do you use 'offerAs' for?

[Phillip J. Eby]

At 12:43 PM 9/26/2005 -0400, Erik Rose wrote:
>I can't think of any uses that wouldn't be served just as well by
>dynamic variables. There are presently 5 uses of offerAs in my
>project: they offer connections to SQL DB's, the logged-in user, the
>HTTP request, and one other thing I'm too ashamed to mention. ;-)
>
>So, just to make sure I'm getting this straight...
>
>To replace the use of `offerAs=[ISQLConnection]`, you'd do something
>like this...
>     with storage.iSqlConnection.push(someSqlConnectionIveGotAholdOf):
>         callStuffWhichUsesTheConnectionFromStorageDotISqlConnection()
>...where in the storage module it would say...
>     iSqlConnection = context.Variable()
>...?

Yeah, except that PEAK probably won't offer one for ISQLConnection.  It 
seems to me that you'll be more likely to have a higher-level component 
representing "my application's data", which just happens to include an SQL 
connection.

Also, you wouldn't use "with" and "push", because push() is the low-level 
API, so it'd be "with somevariable(somevalue):".  But that's nitpicking.  :)


>Do you propose to basically keep a global around for each interface,
>like I posit above, or do you have something whizzier in mind?

Yes and no.  I expect most uses to be more application-specific; in effect 
you'd use them in place of [Named Services].  As I see it, .ini files would 
migrate to simply using the left-hand side as an import string to find a 
dynamic variable and set it (or more precisely, set a factory for 
initializing it).  In effect, there'd be something like a "with 
load_config(...)" operation that would be used in peak.running.commands to 
start up an app, just like there is now, only using dynamic hierarchy 
instead of a component-based one.

At least, that's as far as I've thought on the subject to date.