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 :) > > >
