Replying briefly offlist because, well, I agree with you & don't want to waste more bandwidth. This list *has* gotten dull. To be honest, from my perspective a lot of it is from this Puneet guy posting good but kinda naive questions, like these about coding style, and Bill -OSX- Jones doing much the same stuff. You're right, maybe this isn't the best forum for all that, but at the same time I have a feeling that OSX is a lot of peoples' first exposure to having all this development software, and I'd rather err on the side of being welcoming than standoffish. Personally, anyway.
It seems like at first a lot of people signed up looking at OSX specific issues -- getting this or that working as it does on Linux or BSD, etc -- but many of them seem to have quit or gone into lurk mode, and now it's mainly this sort of stuff. Oh well. I'd also like it to be a bit more advanced (it's much more fun to lurk & learn than answer beginner questions over and over while not getting much out of it...) but that's not where things are currently. *shrug* Lists evolve, all one can really hope to do is push them where we'd like them to go :) On Mon, 15 Apr 2002, ashley wrote: > Date: Mon, 15 Apr 2002 21:02:20 -0700 > From: ashley <[EMAIL PROTECTED]> > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > X-Mailer: Apple Mail (2.481) > Content-Type: text/plain; charset=US-ASCII; format=flowed > Subject: Re: good practice subroutine coding in web context > > this list is becoming nearly useless if os x is supposed > to be its focus. if most of us wanted style guides, coding > advice, or the best way to lay out a calendar, we'd have > the good grace to seek those answers on lists and locations > where they are discussed. > > a few off topic threads are natural to any list but this is > becoming goofy and insulting (i'm one of those who leans > toward "idiot show-off code" like a certain hypocrite who > shares responsibility for the original show-off code: the > schwartzian transform; and have you seen damian > conway's code!? man, he must be the king of the idiots > b/c i don't understand half of it). > > i heard this was a great place to get answers from a co-worker > when i was having trouble with Tk on os x. to my amazement, > the answers were there as soon as i joined; along with more > off topic editorial than i've ever seen on another list. > > i was just gonna unsubscribe but the hell with that. this is > a great list usually and it would be all the time if the off topic > and editorial stuff would end. > > On Monday, April 15, 2002, at 08:39 , Chris Devers wrote: > > > On Mon, 15 Apr 2002, Puneet Kishor wrote: > > > >>> Separating layout, logic & data is a virtue in any programming > >>> situation [which is why HTML is such an abomination, but I digress]. > >> > >> I guess I should have clarified that that is what I believe in already > >> (the separating part, not necessarily the HTML as an abomination part). > > > > Well the problem with HTML -- and the reason it's such a &(&$%%&()^ pain > > in the ass to get things to work well on different browsers -- is that you > > have an intermingling of structural elements (body, head, table), semantic > > elements (emphasis, strong), and style elements (i, b). Scattershot, in > > other words. > > > > XML is supposed to fix this by forcing you to have one document that only > > has data -- semantic elements, really -- and you pair it with some other > > document to generate a strategy for presenting that data -- stylesheets, > > for example. XML is hardly perfect, but it's a step back in the right > > direction, in that it separates data from layout -- as should have been > > the case all along. > > > >> now, I can't really use a template in the "form letters" kind of sense. > >> I mean, take month... months can have 28, 29, 30 or 31 days, they would > >> be put in a table 7 across but sometimes 4, sometimes 5 rows. > > > > Well that just brings up another programming rule of thumb (two variants) > > : > > "Be generous in what you accept, and strict in what your produce." or "Be > > liberal in what you accept, and conservative in what you produce." One of > > your jobs, as a programmer, is to make these sorts of formatter functions > > dynamic & robust enough that they can handle edge cases like this well. > > Maybe you assume that all months are five weeks & 31 days, and just pad as > > needed (that's what paper calendars seem to do). > > > >> there are many occasions in which the display is determined by the data > >> received and maybe certain other conditions. At those times should I > >> bung the data inside the sub so it spits out a preformatted chunk of > >> displayable code, or should I get the raw data out of the sub and then > >> apply the logic. > > > > Well that's the big question, isn't it? My instinct is to have good > > control over your data structures -- or wrap 'em up in objects and pretend > > not to worry about such messy details -- and set up your functions so that > > they can emit & receive these structures as cleanly as possible. Somewhere > > between the two options you suggest here: rather you just have one element > > that knows how to generate a certain kind of list or hash, and another > > that knows what to do with one of those variables when it sees one. But > > this is all very hand-wavy & theoretical -- in the end you just have to > > try it against the problem[s] at hand, and go with whatever seems like the > > cleanest, most efficient, most elegant, or whatever solution to things. > > > >> I also learned that instead of putting a bunch of print statements, I > >> should make a variable out of the display code, and then return the > >> display variable. > > > > Yeah, that's not a bad idea, because it plays into the idea that certain > > kinds of sub are just data processing units, and shouldn't be burdened > > with formatting their results -- after all, maybe you want to hand those > > results off to another sub, or an HTML post-processor, or make a graph out > > of them or who knows? As long as the data processor processes data and > > does so reliably, leave it be & let other components do that work. > > > >> That is a good summary, no? > > > > Yep :) > > > > > > > -- Chris Devers [EMAIL PROTECTED] Apache / mod_perl / http://homepage.mac.com/chdevers/resume/ "More war soon. You know how it is." -- mnftiu.cc
