At 01:09 PM 7/22/2007 +1200, Greg Ewing wrote: >Phillip J. Eby wrote: > > I.e., customers usually don't give you a step-by-step, "well, first I > > check if the customer has an outstanding balance before I ship them > > anything." They say, "Don't ship stuff to people with an > outstanding balance." > >In my experience, customers often give you a vague, >incomplete and even contradictory set of rules. It >takes a lot of careful thought to refine them into >something complete and coherent, and it requires >considering all the rules together to see how they >interact with each other.
Which is why it's good to be able to group those rules *together* -- especially grouping one customer's rules separately from another's. Putting them both into your core code would make the system harder to understand, and harder to distinguish the rules applying to that customer. >The GF approach encourages scattering the rules >over different parts of the program, You seem to be saying that the ability to put things in different places encourages disorganization. I claim the contrary: being able to put GF methods in different places means that you are able to put things in a *more* logical organization than is possible with only classes. Yes, it certainly *enables* you to be more disorganized, if that's what you wish. But why would you *do* that? It makes no sense. It seems to me that by that argument, we shouldn't have modules, because people might put a class and its subclass in two different modules. But that's a *feature*, because it lets you organize things according to other dimensions that might be more important to understanding the program, than the inheritance relationship between classes. _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
