wasteful < extend

I have seen many times, we have to give needless extensions to our classes for the sake of using a framework. Evident quite enough, this makes our classes glued to the framework. I spend my precious time designing my classes and taking of all the precautions I can, to make it reusable, reusable many will consider as an over rated thing, but I think they need to do some serious stuff before even thinking that way. If you think in a proper direction many of your artifacts YES can be reused. I have done that and seen people do that.

Well back to the point, but at times flexibility built right into the language can be silver bullet for many causes. Have a look at the code snippet above. I have two modules module A and module B, I have one class Foo.

Now I want to add behavior into the instance of class Foo and the class Foo itself. Easiest way possible extend to a fraking SUPER class and have fun and worship it as your DSL, losing all the flexibility to the LORD. As your LORD is one ruling you wont mind sacrificing to the stickiness, but growth in different fileds sooner or latter might change the things.

So what to do? sagasious latteral thinking lead me to above solution. I coud add methods without touching my class. Ruby has beautiful methods to kill the burden of the LORD.

Rest is just another story.... !!!! Have Fun ..... !!!!!

air around ruby singleton

Though there are many articles out there regarding singletons in ruby, I am goin to explain my version of it. In the beging singletons baffled me a lot, but a little reading of hack book of ruby and experiments, helped me get over the edge. To start with, we all know ruby is pure object oriented language, everything is an instance of something.

Here we have defined a class A which is instance of Class, and shown the tree it follows. class A inherits from Object and Object includes module Kernel. Class inherits from Module following Object and the Object including module Kernel.

Any object is an instance of its class, A.new i.e an instance of class A. Now, an object encapsulates state and behaves accordingly as defined in the methods. All objects have their own set of instance variables. As defined in the ruby source code.



// Structure for a general object
struct RObject {
struct RBasic basic;
struct st_table *iv_tbl;
} ;


st_table is the hash table where this information is stored.
But if we notice, what about the behavior specification? what about the methods? where are they?


// Structure for a general class
struct RClass {
struct RBasic basic;
struct st_table *iv_tbl;
struct st_table *m_tbl;
VALUE super;
};


here the from the definition of class from ruby code(ruby.h) we find that instance methods are placed in the "Class" of which the current object is instance of.

So to say if I have a class Person, then all instance methods will be manged in Person class. This is no surprise as all objects are unique so at individual level they need to maintain their own state, but method definition is common to all objects so its best to be kept at a single place i.e its class.

Now if you think more you'll start getting into the quagmire. What about the class_methods of Person class.
Where will be they?

Think ..................... !!!!!!!!!!!!!!!!!!

Hmmm the Class, oh yeah thats what the ruby Class source code we see.
BUT................ in that case all the classes will have all the other classes methods, as all classes are instance
of Class.

We are in a snake pit.

To breathe it easy "Ruby Singletons" come into the picture. These have different names not a surprise as we have different names for GODS ;).

Every class has a hidden class called singleton class as this class belongs uniquely to one class only hence the name.

It can be extracted as follows.


Here we see that the return value is a "Class" which is attached to "Class A", this is the class where class methods reside. These singleton classes follow the same tree as the actual Class.


Lets see the theory in action. Here we are defining a class named A with a class method "pingC".


In above steps, we have first extracted the exclusive class i.e the singleton and by using "class_eval" added instance method "pingEXC" to the singleton class.



As is evident from the result above "class A" has got "pingEXC" as its class method.




Interestingly we see that exclusive class is having "pingEXC" as instance method while "class A" is having it as class method. To get a list of instance methods for an object we query its class for instance methods(instance_methods method on the class of object in question).

self.send reader.join :rails_bridge

I wont be taking time mentioning how/where of recent rails activity. Main idea is to make people know about new community that has come up The Rails Bridge. Initiated by people like Mike Gunderloy its a good initiative to represent one self in Rails community with a different view for things. You can join the Rails Bridge Google Group and participate in discussions and volunteer for the projects community has for the group. You can follow the group on Railsbridge Twitter for the latest announcements and happening in the group.

Happy Railing Folks !!!!!!!!!!!!!!!!!! Bridge the gap...............