Re: Falling for the same trap

When I read the conclusion, it immediately reminded of the assertion about the common Perl object orientation pattern (using an anonymous hash to store instance data) that Abigail strived to correct by inside out objects.

I think the problem Abigail addresses with Inside Out Objects is, although similar, a very different issue. Inside out objects solve the problem of classes vying for slots to put their instance data in and do it in such a way that retrieving instance data is still efficient (e.g. rather than multiple hash lookups) and strict checking becomes useful again. Your acquaintance's article looks like it is just a short note on one strategy for namespace partitioning within a Session object.

I've looked at some of the other articles on his site. In many cases, he seems to find profundity in a little semantic slight-of-hand... For instance, his assertion that there are no web objects and http requests should be thought of as functions. Well, I think that depends on the web application... Oh! But he goes on to suggest developers should think in terms of "request handlers" rather than "web applications." Ok... whatever. Sometimes you have to group together a few hundred request handlers and call them an application. It's mighty convenient when they act on the same data and even share code.

In other cases, his statements seem to be more academic than experienced. Like when he says, "GET requests should not have side effects while POSTs may." Well, yes and no. That's really a convention and it is often not followed. It makes sense in the context of getting the most out of caching... You've got to keep in mind though that almost every hit counter in the history of the web breaks this guideline.

I don't know what to say about his POST requests must always result in redirects idea...

Or his Put all interactive content into images with headers for immediate expiration idea...

I couldn't help but notice that he rolled his own templating system. Have you reviewed the code? (And you've accused me of writing in a C-ish style! ;-)

I don't doubt that this guy is bright and has some good ideas about programming in general and writing web applications specifically but I don't find a lot to be impressed by on that site. Frankly, when someone writes a "Thingamajiggie Considered Harmful" paper, I expect it to have some real meat. This one didn't.

-sauoq
"My two cents aren't worth a dime.";

Comment on Re: Falling for the same trap - since 1942

Replies are listed 'Best First'.
Re^2: Falling for the same trap - since 1942 by Aristotle (Chancellor) on Jul 15, 2003 at 08:49 UTC
I think the problem Abigail addresses with Inside Out Objects is, although similar, a very different issue. There are several issues they address. I'm specifically talking about just one of them. That's really a convention and it is often not followed. What he's saying is that it should be followed if you want to make your life easier. I don't know what to say about his POST requests must always result in redirects idea... Well, keeping in mind that it is assumed that your GETs never change server state, then it makes a lot of sense considering the problem he is trying to address. Yes, I saw that he rolled his own templating system. I was irked as well. I didn't review the code, no. Note that if you think I "accused" you of writing C-ish Perl, then at the same time I "accused" myself of writing LISP-ish Perl. I was simply commenting on our preferences. Makeshifts last the longest.	[reply]
Re: Re^2: Falling for the same trap - since 1942 by sauoq (Abbot) on Jul 15, 2003 at 19:17 UTC
What he's saying is that it should be followed if you want to make your life easier. Do you (or does he) care to elaborate? I think it depends on requirements. It is a convention, and so it often is followed. OTOH, it's just a convention, and it often is not followed. I think the current state of affairs has come about by real world pressures. Without explanation, I think the gentleman is, at best, oversimplifying. Well, keeping in mind that it is assumed that your GETs never change server state, then it makes a lot of sense considering the problem he is trying to address. I must be missing something. What's the problem he is trying to solve with redirects? Note that if you think I "accused" you of writing C-ish Perl, then at the same time I "accused" myself of writing LISP-ish Perl. Oh, I know. And I did take it a bit personally, I guess. Really, that's because of the associations to both C and LISP that I have in my own mind. Things like... LISP: pure, clean, fun. C: applied, messy, work. It's also ingrained into me that "writing C in Perl" is something to be avoided. I do know that your comment wasn't pejorative, though. ;-) -sauoq "My two cents aren't worth a dime.";	[reply]
Re^4: Falling for the same trap - since 1942 by Aristotle (Chancellor) on Jul 15, 2003 at 22:06 UTC
What's the problem he is trying to solve with redirects? Refreshing. If you POST to a URL, then get back a page, and then try to refresh that page, you have to resend the POST data. If on the other hand, any URL you POST to produces a redirect, then refreshing will reload from the URL the refresh pointed you to, rather than the one you POSTed to. It is in this context that following the GET/POST convention is most natural; of course, you can apply the general "redirect after everything that changes server state" even if you don't. Personally, I don't consider the "POSTs must have side effects" rule nearly as strong as the "GETs must never change server state" counterpart. LISP: pure, clean, fun. Don't forget "slow" and "memory hungry", esp in the case of LISP-ish Perl. And though I was referring to these connotations as well, I don't see what's so bad about being pragmatic? `:-)` Makeshifts last the longest.	[reply]


Welcome to the Monastery
	PerlMonks

Re: Falling for the same trap - since 1942