Now thats a nice extension of my analogy!

And it also leads me to some more thoughts on this.. What you have described seems to be the industrial type coffee machine like the big one standing in the kitchen at work, which is installed by a company, which gets hooked up to a water pipe, the electricty, etc. and refilled with cups, coffee by them, with no interaction from me (the user), whatsoever..

My point is that the article seems to suggest that this is the only way to do it, at all. Suppose I also have a coffee machine at home. This is a much more simple affair, its not a complete-in-itself application, its just part of my kitchen, like the toaster or kettle, an object. We are still light-years away (says I), from the fully automated kitchen (or replicator), in which I just say 'make me a coffee', and it happens. In this situation I just have to get the jug, fill it from the tap, and fill the machine, etc.

I think there's plenty of opportunity in the real programming world for complete applications-as-objects, but also for simple objects which can be included as parts of other things.

To go back to the analogy: The part I was describing is more like your Authorisation object, which can (presumably), be used other machines as well (candy/sweet machine, anyone?). *This* object has to have some sort of in/ouput, even if its just an 'isOk', 'isNotOK'.. Am I making any sense here.. ?

I'm all for not just using objects to hold data, but to actually manipulate that data and just say 'yes/no', but they still have to get the data from somewhere.. (Where's your 'User' Object? :)

C.