Feeds:
Posts
Comments

Archive for January, 2005

The dark side of Visual Basic

I have been looking into Object Orientated programming in Visual Basic 6 . Why look for something that isnt there, you might say. But you will be kinda surprised, as I was. There is support for Object Oriented programming in VB6 as opposed to popular belief. You can have encapsulation, polymorphism and inheritance (to some particular extend, as I will explain now).
To support encapsulation VB has a class module where you can group some data and methods which act on the data. Access control can be enforced using keywords Public, Private and Friend. Usage of this feature is highly recommended. While I am at it, I would like you to know that there is no support for static methods or data (methods and data belonging to the class as opposed to those belonging to an object of a class). That is restrictive to quite some extend, I agree.
Before speaking of inheritance we can group inheritance into 2 categories based on a single criteria – implementation inheritance and interface inheritance. In implementation inheritance, the derived class inherits all the implementation of the base class while in interface inheritance only the signature of the base class is recieved by the derived class. VB natively supports only interface inheritance. The keyword Implements is used to show that a class inherits the interface of another class. I have found that there is way to simulate implementation inheritance in VB by using composition. We can keep a private member object of the base class and delegate methods to that object if we dont want to implement any particular inherited method.
Support for polymorphism is rooted partly in this interface inheritance. That said, I would like to say there are 2 types of polymorphisms here. One happens when we have a base class and subclasses implementing the interface of the base class. We can refer to derived class objects using a reference variable of base class type and use it to achieve polymorphic calls to methods. The second way is when we keep object references as type Object (we can keep reference to objects of any class in a variable to type Object). Why I would like to differentiate between these two is because, in the first way, compiler can verify whether the object actually implements a particular interface thus preventing runtime error when method resolution fails. In the second way there is no way compiler can know if the object referred to by the Object variable actually has a particular method until runtime, when it is too late. I would suggest that whenever possible we should go for the first type of polymorphic calls.

loveable 😉
I had plans to include some code here, but I feeling sleepy and lazy 🙂

Read Full Post »

Freedom of Speech ?

If u haven’t yet heard about an abusive call made by 2 prominent radio jockeys in US to call centre in India, read this. You can read the transcript here and download the mp3 file here.
I wonder whether this is the American way of exercising freedom of speech/expression ?

Read Full Post »

Friends are forever

The friend access for a function is a constant source of debate among C++ programmers. Inside a class declaration, we can specify an external function as friend and this function has access to all member variables of that class. Quite extra-ordinary decision in the language design, dont u think so ? One can say that this breaks the encapsulation, which is one of the primary goals for an object oriented language. Private members of a class are supposed to be accessed only by members of that class. Naturally. So the concept of friend is not at all advisable or so it seems. Atleast I thought so. But Bjarne Stroustrup could see that in a language with pointers, manipulating the private members is always possible. So the access control in C++ is designed to protect programmers from unintentional errors while coding (comiler can let them know when they access something they shouldnt) and not for protecting private members from programmers who intentionally want to access them. friend access to a function is explicitly granted by the class author. A function cannot declare itself as friend of a class and go ahead and access private members of any class it likes. Hence the class author is aware of another function which can access its private members and hence everything here is intentional. Suppose if there was no friend access, then the class author should either make the members public or provide methods for reading and writing to the private members. Actually this corrupts the public interface of the class. The author usually wouldnt want to do this just because another function needs access to its private members. If he does this, now the private members are read/write enabled from anywhere. Having friends are not that bad after all 😉
I would say that friend access should be used with discretion, if ever. But in some cases you can have a better design by using friend functions instead of avoiding them because OO purists think that it will break encapsulation, but choose them with diligence..

Read Full Post »

Welcome 2005 !

On looking back, the year 2004 has brought so many changes to my life. For instance, I have started blogging ;-). Lol, on a serious note, the biggest event for me in 2004 was joining Tavant. That certainly changed my life for the better. For the first time in my life, I didnt feel bad staying away from home.
I spent new year eve with Sanjeev, Girish, Hari, Vineeth. We missed Binil. After lots of phone calls to wish our near and dear ones Happy New Year, we settled down for beer, wine and an old mallu movie “Boeing Boeing”. On new year day, Deepa and Sindhu came over and we cooked food for lunch. Had a great time over the New Year weekend.
I wish that 2005 will bring peace,happiness and joy to all…

Read Full Post »