> It depends on how they interact. If you use ForeignKeys, MultipleJoins, > RelatedJoins, etc. then it is a hell lot more practical to *see* all classes > in the same file. Even with tabs or buffers or windows or ... it is easier to > see their relation if they are grouped together. Specially when making > changes that will interfere with this relationship.
The join relations are just explicit versions of the relationships you get between classes in an application anyway and I personally don't feel compelled to squeeze them into a single source file. I'll try and explain the class lumping issue: As an application grows it is natural to split it out into modules or sub-systems - purely for maintenence purposes if nothing else. For a website you can imagine modules that deal with administration, a blogging module, forum module, photo gallery module - that kind of thing. In this scenario it's likely we'll have a number of classes in each module addressing various aspects of our websites functionality. So, why not just shove it all in one file? Flat is better than nested right? This is taking to the extreme. Imagine the horror of coming to the system where it's just a 50k+ lines file. It's worse than that though. Because all classes are lumped into a single file it affects the way you extend the app. In a flat app everything is on tap - no need to worry about separation of concerns, module developement etc. Access anything from anywhere. Soon it becomes an untanglable mess requiring a huge amount of refactoring. Heaven forbid you're app goes large and has a sizable team working on it. 20+ programmers hacking and diffing/merging away on a monolithic source file. So, encouraging modular design is a good thing. It's about managability, ecouraging development of reusable components/libraries and a path way to scaling. > <[EMAIL PROTECTED]> writes: > > >>Interesting point about one model file - suppose a lot boils down to expected >>usage of SQLObject objects. > > > This is an interesting point. Another one is praticality. Where in > SQLObject's docs there are instructions about setting up multiple files and > integrating them? > > >>I'm really trying not to sound too preachy here (it's hard :-) ) but keeping >>lot's of classes inside a single file is just ... bad practice. > > > It depends on how they interact. If you use ForeignKeys, MultipleJoins, > RelatedJoins, etc. then it is a hell lot more practical to *see* all classes > in the same file. Even with tabs or buffers or windows or ... it is easier to > see their relation if they are grouped together. Specially when making > changes that will interfere with this relationship. > > >>I think the bottom line is that if quickstart had been written to create model >>and controller directories in the first place this wouldn't be an issue and >>you probably wouldn't be putting all your SQLObjects into a single source >>file. Nobody is complaining about the static directory. > > > Where are the docs? The only place where I saw it mentioned is > http://sqlobject.org/sqlobject-admin.html and in a warning that if you have it > in a different namespace then you'll have problems with the automation the > tool is doing. > > If we are going to change that, there is a lot of documentation to be written > on that and it has to be very clear so that the user gets what he expects, all > classes and their relationship can be maintained and we don't have to ignore > all of SQLObject's docs. So, more docs, tests and whatever for this, making > sure compatibility with SQLObject still goes on, to avoid surprising long date > users of SQLObject and projects already released. > > >>Ah, for example. In my web project I have several dozen SQLObject derived >>classes modelling my data with varying degrees of functionality in methods. >>Having that all in one file would be a very bad idea for a number of very well >>know anti-pattern reasons. Having fewer SQLObjects in one file seems ok but >>is just bad practice with the consequences waiting to happen. > > > Could you enumerate those well known anti-pattern reasons? And could you also > enumerate some of the bad consequences? When people are reasoning about > something it is much better to make things explicit than imply that all are > thinking the same way you are or have the same background you do. Today is my > Zen of Python (python -m this) citing day: "Explicit is better than implicit." > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
