Daniel McBrearty wrote:
You generally design systems with initial constraints in mind.
*sigh*
Perhaps, but ideally you codify as few of these in as required assumptions as
well. Not doing that tends to mean that you end up in a situation where if one
of your assumptions turns out to be incorrect ("640k should be enough for
anybody") or if one of your assumptions is incorrect in a new use to which you
want to put your application ("I wonder if I can re-use my Catalyst handler to
power an IRC bot") then you end up spannered.
Avoiding making assumptions where not absolutely necessary is also how you get
emergent properties out of systems - people have done some awesome things with
DBIx::Class that worked not because I even remotely foresaw they might do it,
but simply because I did my best not to rule out anything unless I *really*
had to.
Of course, in a single-purpose application this isn't nearly so important as
in library/systems dev, but food for thought nonetheless
--
Matt S Trout Offering custom development, consultancy and support
Technical Director contracts for Catalyst, DBIx::Class and BAST. Contact
Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information
+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +
_______________________________________________
List: [email protected]
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
