From: Dave Howell <groups.2009a@...>
Date: 2010-06-23T03:30:11+09:00
Subject: Re: Got to be a better way to code class variables....


On Jun 22, 2010, at 1:06 , Robert Klemme wrote:

> 2010/6/22 Joel VanderWerf <joelvanderwerf@gmail.com>
>> 
>> Dave Howell wrote:
>>> 
>>> I'm trying to set up an object with overridable defaults, so it will act like this:
> 
> Question is, do you really need this:

Good question. I'm not sure yet.

>>> I'd like to have other methods that worked the same on the class and the instance, but the only way I can figure out how is to type every single method twice. There has *got* to be some terribly clever ruby-esque way of including instance methods as class methods or vice versa, no?
> 
> ?  You only need setters on the class if you want to be able to modify
> the default.  If not, you can use a different approach (see below).

What I'm trying to do is save myself a bunch of time and effort coding a web site. The class will contain the 'default' web page, and then various routines will be able to tweak the title, or the main contents, to fit the specific page the user is on. But, I'd also like to be able to change the 'default' page properties as well, as conditions warrant. I could just store everything in some kind of cloud-y, tree-y, nest-y sort of structure, but the class/instance structure seemed like a good place to start.*

Then when I tried it, and ended up with rather goofy looking code, it became an opportunity to learn more about Ruby. Playing with Joel's code taught me something absolutely nifty-keen: the difference between "include" and "extend". 

I made a brief mention in my original post that I also wanted to have some methods that would also appear on both the class and the instance. I ended up with this solution:


module SmeeCore
	def pushmepullyu
		@back = @front
	end
	def double
		@front = @front * 2
	end
end

class Smee
	extend SmeeCore # including it for the _class_
	include SmeeCore # including it for the _instances_
end



* I suspect I'm going to discover that the class properties are more global than I'd originally thought, and my instance properties are going to have to become a lot more sophisticated and start handling 'regional' defaults: less than global, more than local.