> I want to buy cheddar cheese. When I go to the store, there are a
> bunch of gray boxes with no labels that I have open to find out
> whether I've got the box of cheddar cheese right? And, I also don't
> have to whack of a bit to chew on and hope that I got the cheddar
> cheese, and not the orange bacterial culture.
There are problems when we try to make analogies between technical
solution alternatives and the "real world". Here is my counter
example: I want to buy cheddar cheese. I walk through the door and
find the box labelled "cheddar cheese". I don't have to walk through
the "cheddar cheese door" rather I walk through a general door.
OK, so I think neither your analogy nor mine help the discussion.
> Thus, I would choose a service interface named BuyCheddarCheese
> instead of BuyGoods that received a Goods parameter that was
> CheddarCheese extends Goods.
The question then becomes how far you take this approach. i.e. if
BuyCheddarCheese is better than BuyGoods, then is
BuyShardCheddarCheese & BuyMildCheddarCheese better than a more
general BuyCheddarCheese? Where does this stop?
> Only through specific typing systems can production software make
> exacting requests and have well formed requirements that can be met.
That seems to be an extreme claim.
> The people implementing really strict typing languages are, from my
> perspective, the people that grew up with the UNIX shell environment
> in the 70's and 80's and learned all about how bad "everying's a
> string" can be.
There is a difference between the "everything is a string" languages
(TCL, Bash, etc.) and the "everything is a well-defined object"
languages (Lisp, Smalltalk, Ruby, Python, Linda, JavaSpaces, etc.)
-Patrick
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
