Class-ception

A friend posed an interesting question the other day.
Is it possible to create a class within a class in Python?
Honestly, I had no idea. It might be possible but what would I gain from doing so. Just off the the top of my head, I can imagine the code looking like this:

class Shape:

    def __init__(self):
        ...
    ...
    class Square:

        def__init__(self):
            ...
        ...
And I can imagine that you'd have to input Shape.Square() to create a Square object, which essentially seems the same as a method or a module.

Of course the true scientist would explore this possibility.
And turns out, you can create a class in a class. I will now coin the term describing such a practice as class-ception.
It also turns out that this is particularly useless; the only reason anyone might do this is because they only need their nested class for this one program and it doesn't require variables outside of the nested class.

What do I mean? Well, taking the example above, you might think that any variable defined in Shape or Square exists in the counterpart's namespace. It doesn't. You can't call Shape methods if the object is a Square and to call Square methods when the object is a Shape requires the Square prefix. So basically it has all the limitations of a module plus a bit of added confusion.

Moral of story: Don't bother nesting classes in Python.

Commence Object Instatiation

Object-oriented programming sounds more ominous than it actually is. With terms like polymorphism, encapsulation and instantiation, it's not hard to see why people get turned off from computers and programming. Frankly, I don't really understand all those terms, but I do have words that I use to describe what OOP is to me. (And hopefully, others understand how I use them)

From the Wikipedia entry of Object-Oriented Programming:

Object-oriented programming (OOP) is a programming paradigm that represents concepts as "objects" that have data fields (attributes that describe the object) and associated procedures known as methods.

If looking at the definition in the box doesn't really explain things to you, then that means you suffer from the affliction known as "Conversational English". Don't worry, it's a condition that afflicts many people, myself included. I have to make a constant effort to adapt my condition to the technical jargon that people expect me to know. It's not easy but with adequate support, I'm sure you can overcome it too.

Basically, a long long time ago, programmers used to do what is called Procedural Programming. That means that they would put in a programme that commanded the computer to do things in sequence. So a typical programme would look like this:

1. Do this action on this file
2. Do this on that
3. Do this on that....

It's like your mother telling you to your chores or to sit up right or to behave, with each instruction coming one after the other.

Then one day but still pretty long ago, programmers started to switch from thinking of code as instructions to thinking of them as representing objects. Instead of writing instructions for the computer to perform, programmers created objects and told the computer what can be done to the object. For example, I'm a programmer who wants to create a ball in my computer and use it like how I would use a ball in real life so my programme would look like this:

Create Ball:
    Ball is...
    bouncy, round, smooth, filled with air

    Ball can...
    bounce

    Ball can...
    roll

    Ball can...
    deflate

First I created the object Ball. Then, I assigned "attributes" (bouncy, round, smooth, filled with air) to Ball. After I set out what the Ball can do (bounce, roll, deflate), these actions are called "methods".

The idea behind OOP is to create a whole bunch of objects that you might want to make use of. And then tell the computer how to use them. Which in some ways can make life a lot easier for programmers, because a lot of programmes use the same methods on the same pieces of data so instead of telling the computer every single thing it has to do, you could just build an object, set some rules to it and tell the computer to do the same thing over again.

It's a neat idea. But let's face it, there will be times when we're going to find that it's much easier to tell people what to do. If I encounter one of those times, I'll try to have it up on this blog as an example.

SLOG Post 1

Let it be stated for the record that this SLOG was created as an assignment for CSC148. That's a first-year computer science course at the University of Toronto. The purpose is to write about my experience in programming, so this should be fun...