Comments on: On Beauty in Code http://avdi.org/devblog/2008/04/27/on-beauty-in-code/ Sat, 19 Jul 2008 20:26:05 +0000 http://wordpress.org/?v=2.3.1 By: Kabari http://avdi.org/devblog/2008/04/27/on-beauty-in-code/#comment-66 Kabari Mon, 19 May 2008 00:40:36 +0000 http://avdi.org/devblog/2008/04/27/on-beauty-in-code/#comment-66 @PIERS and @RONNY the article isn't about the functionality, it's about effectively placing and using methods. Ramaze routing is regex based, not key based like Rails etc, that is why some of things you both are mentioning aren't there. PIERS and RONNY the article isn’t about the functionality, it’s about effectively placing and using methods. Ramaze routing is regex based, not key based like Rails etc, that is why some of things you both are mentioning aren’t there.

]]> By: Silvermonkey http://avdi.org/devblog/2008/04/27/on-beauty-in-code/#comment-61 Silvermonkey Tue, 29 Apr 2008 09:11:54 +0000 http://avdi.org/devblog/2008/04/27/on-beauty-in-code/#comment-61 10 PRINT "DISCO DUMP!" 20 GOTO 10 Now that ladies is beauty! 10 PRINT “DISCO DUMP!”
20 GOTO 10

Now that ladies is beauty!

]]> By: Ronny Pfannschmidt http://avdi.org/devblog/2008/04/27/on-beauty-in-code/#comment-59 Ronny Pfannschmidt Tue, 29 Apr 2008 08:05:32 +0000 http://avdi.org/devblog/2008/04/27/on-beauty-in-code/#comment-59 imho this implementation lacks a very important feature generating a url from a rule + some values, preferable based on the current "mount point" of the application imho this implementation lacks a very important feature

generating a url from a rule + some values,
preferable based on the current “mount point” of the application

]]> By: Piers Cawley http://avdi.org/devblog/2008/04/27/on-beauty-in-code/#comment-58 Piers Cawley Tue, 29 Apr 2008 05:53:45 +0000 http://avdi.org/devblog/2008/04/27/on-beauty-in-code/#comment-58 I'm not sure that I'm such a fan of the code to be honest. The fact that the if/ifelse cascade can't be replaced with a <code>case</code> statement is a bit of a worry. Combine this with the use of <code>is_a?</code> and <code>respond_to?</code> and the fact that every consequence has its own nested if and it starts to smell of structural code. I realise that it's going to increase the line count, but I'd prefer to introduce a few subclasses of Route (FilteredRoute, ProcRoute and StringRoute, say) and parcel the conditional logic out appropriately. Stick the key/value stuff in a <code>make_route</code> method, called from <code>[]=</code> and the path munging into <code>subclass#resolve</code> methods and you start to have a collection of objects interacting with each other rather than a bunch of code messing with datastructures. It may not be a refactoring worth doing when there's only three route types, but I would definitely be inclined to do it if the need arose for another kind of route. I’m not sure that I’m such a fan of the code to be honest. The fact that the if/ifelse cascade can’t be replaced with a case statement is a bit of a worry. Combine this with the use of is_a? and respond_to? and the fact that every consequence has its own nested if and it starts to smell of structural code.

I realise that it’s going to increase the line count, but I’d prefer to introduce a few subclasses of Route (FilteredRoute, ProcRoute and StringRoute, say) and parcel the conditional logic out appropriately. Stick the key/value stuff in a make_route method, called from []= and the path munging into subclass#resolve methods and you start to have a collection of objects interacting with each other rather than a bunch of code messing with datastructures.

It may not be a refactoring worth doing when there’s only three route types, but I would definitely be inclined to do it if the need arose for another kind of route.

]]>