Additions about O.O.P

        After this week's latest class I should probably comment on some of the more technical parts of O.O.P.

        Often when creating an overriding subclass method it is useful to utilize the corresponding method of the master class such that the overriding method derives all the information from the original method. Then you can build around it to specialize that new overriding method. In this instance calling that method requires the following syntax:

 MasterClass.method(self, arguments...)

Similarly if you simply want to use the more general method and not the specialized version the syntax required is MasterClass.method(subclass_object, arguments...).

        Another less technical point made was that when designing an __eq__ method, it must encompass three qualities.

The simplest is symmetry.

 If a == b, then b == a

The next is that it is reflexive.

a == a

The last quality, which is also the easiest to overlook,  is transitivity.

If a == b and b == c, then a == c.

That's all for this week.

Assignment Topic One: Object Oriented Programming

         It would certainly seem that the UofT undergraduate CS teaching staff are doing their utmost to mix up early undergraduate computer science  and I applaud them for such attempts. Whether all these attempts are successful in providing a "better" education is still to be determined. I personally feel that the flavor of the changes is largely dependent on the audience, and when comparing fourth year students to first year undergraduates I feel this is a field where skill levels differ immensely.

    

        This first year is largely characterized by gaining a solid foundation in programming and the nature of the science. This would be a curriculum encompassing techniques (certainly not language specific), computational thought, and building confidence in a world that is foreign to most of us even though we utilize computers all the time. This was accomplished astoundingly well in the prerequisite course in which experiential learning was paramount. Before a larger assignment or test, concepts were thrown at you in parts combined with small problems all revealing new information about it upon discovery of the solution. 

    

        This is what introductory CS should be about, grasping these ideas through self discovery (we've got to play at this stage of infancy!), and then drilling them until they're second nature. I feel that deeper discussion of concepts is a great exercise for those who already have this foundation and can extrapolate from the material even when removed from the computing environment. The latter notion is a skill derived from a great deal of experience that many of us in CSC148 do not yet boast.

        So, to refrain from proliferating excuses and complaints about this assignment I will attempt it. Though I cannot promise that details won't be sparse.

        Object Oriented Programming is a readily accessible aspect of python that, as has been imposed upon me in lecture, is much more so than other languages. Implementing classes and their associated methods whether they're completely new or they inherit from another class are far from tedious. All classes though technically inherit from the grandfather class the "object", for which the most basic methods have been defined in a very general way. Not much else has been elucidated with respect to the "object". Most of our early discussion has been about formatting classes such that the methods and attributes can be organized in an intelligible way. It is possible to augment the behaviour of classes whenever, but such things are highly discouraged as it can be difficult for other programmers to ascertain as to how the class works and how it relates to other objects. 

        Finally when designing new classes, writing about the abstract data type is a great way of collecting your thoughts and to avoid building on a class in an unintelligible way. No discussion of implementation or the type's relationship to the digital world is made, only that the type is based on a real world device or entity that can be used to interact with information or other entities. It is this interaction that is the subject of a brainstorm. What actions (methods) can the type perform? These different actions are to be so clear that any competent programmer in any language could understand what you're describing and be able to implement it in their language/space with little to no ambiguity.