What are OOP's Jargons and Complexities?
in [Perl]
|
Prev: swift MT940 files
Next: Is there neq for strings?
From: Xah Lee on 31 May 2005 05:44 the Rise of “Access Specifiers†(or, the Scoping Complexity of OOP) In programing, a variable has a scope — meaning where the variable can be seen. Normally, there are two basic models: dynamically scoped and lexically scoped. Dynamic scoping is basically a time based system, while lexical scoping is text based (like “what you see is what you getâ€Â). For example, consider the following code: subroutine f() {return y} {y=3; print f()} In dynamic scoping, the printed result is 3, because during evaluation of the block all values of y is set to 3. In lexical scoping, “y†is printed because any y in the block is set to 3 before f is called. With regards to language implementation, Dynamic Scoping is the no-brainer of the two, and is the model used in earlier languages. Most of the time, lexical scoping is more natural and desired. Scoping is also applicable to subroutines. That is to say, where subroutines can be seen. A subroutine's scope is usually at the level of source file (or a concept of a module/package/library), because subroutines are often used in the top level of a source file, as opposed to inside a code block like variables. In general, the complexity of scoping is really just how deeply nested a name appears. For example see in the following code: name1; // top level names. Usually subroutines, or global variables. { name2 // second level names. Usually variables inside subroutines. { name3 // deeper level names. Less often used in structured programing. } } If a programing language uses only one single file of commands in sequence as in the early languages such as BASIC, there would be no scoping concept. The whole program is of one single scope. OOP has created a immense scoping complexity because its mode of computing is calling nested subroutines (methods) inside subroutines (classes). We detail some aspects in the following. In OOP, variables inside subroutines (class variables) can also be accessed thru a reference the subroutine is assigned to (that is, a object). In OOP parlance: a variable in a class has a scope, while the same variable when the class is instantiated (a objet) is a different scoping issue. In other words, OOP created a new entity “variable thru reference†that comes with its own scoping issue. For example: class a_surface() { coordinates={...}; // a variable } class main() { mySurface = new a_surface(); mySurface.coordinates = {...}; // the same variable } In the above code, the variable “coordinates†appears in two places. Once as defined inside a_surface, and once as a instantiated version of a_surface, that is, a object. The variable as thru the object reference apparently has a entirely different scoping issue than the same variable inside the subroutine (class) definition. The question for OOP language designers is: what should the scope be for variables referred thru objects? Within the class the object is created? within the class the variable is defined? globally? (and what about inherited classes? (we will cover OOP inheritance later)) As we've seen, methods are just inner-subroutines, and creating objects to call methods is OOP's paradigm. In this way, names at the second-level programing structure often associate with variables (and inner-subroutines), is now brought to the forefront. This is to say, the scoping of subroutines are raised to a level of complexity as the scoping of variables. (they are now both in the 2nd level of names (or deeper).) All in all, the scoping complexities of OOP as applied to different OOP entities (classes, class variables, class's methods, object variables and methods) is manifested as access specifiers in Java. In Java, access specifiers are keywords “privateâ€Â, “protectedâ€Â, “publicâ€Â, used to declare the scope of a entity. Together with a default scope of no-declaration, they create 4 types of scope, and have entirely different effects when used upon a variable, a method, a constructor, and a class. See this tutorial of Java's access specifiers for detail: http://xahlee.org/java-a-day/access_specifiers.html ----- to be continued tomorrow. This is part of an installment of the article “What are OOP's Jargons and Complexities†by Xah Lee, 20050128. The full text is at http://xahlee.org/Periodic_dosage_dir/t2/oop.html © Copyright 2005 by Xah Lee. Verbatim duplication of the complete article for non-profit purposes is granted. The article is published in the following newsgroups: comp.lang.c,comp.lang.c++,comp.lang.lisp,comp.unix.programmer comp.lang.python,comp.lang.perl.misc,comp.lang.scheme,comp.lang.java.programmer comp.lang.functional,comp.object,comp.software-eng,comp.software.patterns Xah xah(a)xahlee.org ∑ http://xahlee.org/
From: Dale King on 31 May 2005 07:27 David Formosa (aka ? the Platypus) wrote: > On Tue, 24 May 2005 09:16:02 +0200, Tassilo v. Parseval > <tassilo.von.parseval(a)rwth-aachen.de> wrote: > >>Also sprach John W. Kennedy: > > [...] > > >>Most often, languages with strong typing can be found on the functional >>front (such as ML and Haskell). These languages have a dynamic typing >>system. I haven't yet come across a language that is both statically and >>strongly typed, in the strictest sense of the words. I wonder whether >>such a language would be usable at all. > > > Modula2 claims to be both statically typed and strongly typed. And > your wonder at its usablity is justified. I used a variant of Modula-2 and it was one of the best languages I have ever used. That strong, static type checking was a very good thing. It often took a lot of work to get the code to compile without error. Usually those errors were the programmers fault for trying to play fast and loose with data. But once you got it to compile it nearly always worked. -- Dale King
From: Tassilo v. Parseval on 1 Jun 2005 00:09 Also sprach Dale King: > David Formosa (aka ? the Platypus) wrote: >> On Tue, 24 May 2005 09:16:02 +0200, Tassilo v. Parseval >> <tassilo.von.parseval(a)rwth-aachen.de> wrote: >> >>> [...] I haven't yet come across a language that is both statically and >>>strongly typed, in the strictest sense of the words. I wonder whether >>>such a language would be usable at all. >> >> >> Modula2 claims to be both statically typed and strongly typed. And >> your wonder at its usablity is justified. > > I used a variant of Modula-2 and it was one of the best languages I have > ever used. That strong, static type checking was a very good thing. It > often took a lot of work to get the code to compile without error. > Usually those errors were the programmers fault for trying to play fast > and loose with data. But once you got it to compile it nearly always worked. I am only familiar with its successor Modula-3 which, as far as I understand, is Modula-2 with uppercased keywords and some OO-notion bolted onto it (I still recall 'BRANDED' references). I have to say that doing anything with this language was not exactly a delight. Tassilo -- use bigint; $n=71423350343770280161397026330337371139054411854220053437565440; $m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
From: Anno Siegel on 1 Jun 2005 07:03 Tassilo v. Parseval <tassilo.von.parseval(a)rwth-aachen.de> wrote in comp.lang.perl.misc: > Also sprach Dale King: > > > David Formosa (aka ? the Platypus) wrote: > >> On Tue, 24 May 2005 09:16:02 +0200, Tassilo v. Parseval > >> <tassilo.von.parseval(a)rwth-aachen.de> wrote: > >> > >>> [...] I haven't yet come across a language that is both statically and > >>>strongly typed, in the strictest sense of the words. I wonder whether > >>>such a language would be usable at all. > >> > >> > >> Modula2 claims to be both statically typed and strongly typed. And > >> your wonder at its usablity is justified. > > > > I used a variant of Modula-2 and it was one of the best languages I have > > ever used. That strong, static type checking was a very good thing. It > > often took a lot of work to get the code to compile without error. > > Usually those errors were the programmers fault for trying to play fast > > and loose with data. But once you got it to compile it nearly always worked. > > I am only familiar with its successor Modula-3 which, as far as I > understand, is Modula-2 with uppercased keywords and some OO-notion > bolted onto it (I still recall 'BRANDED' references). > > I have to say that doing anything with this language was not exactly a > delight. I've been through Pascal, Modula2 and Oberon, and I agree. These languages had an axe to grind. They were designed (by Niklas Wirth) at a time of a raging discussion whether structured programming (goto-less programming, mostly) is practical. Their goal was to prove that it is, and in doing so the restrictive aspects of the language were probably a bit overdone. In the short run they succeeded. For a number of years, languages of that family were widely used, primarily in educational programming but also in implementing large real-life systems. In the long run, the languages have mostly disappeared from the scene. It has been discovered that "structured programming" is possible in about any language. It turns out that programmers prefer the self-discipline it takes to do that in a liberal language over the enforced discipline exerted by Papa Pascal and his successors. Anno
From: David Formosa (aka ? the Platypus) on 1 Jun 2005 08:30
On Wed, 1 Jun 2005 06:09:43 +0200, Tassilo v. Parseval <tassilo.von.parseval(a)rwth-aachen.de> wrote: [...] > I am only familiar with its successor Modula-3 which, as far as I > understand, is Modula-2 with uppercased keywords and some OO-notion > bolted onto it (I still recall 'BRANDED' references). Modula-2 also overused caps, I recall the irratation I found programing it was irratating, streaching my finger to hit the shift key or taking me hands of the home keys to bump the CAPSLOCK key quick became phisically painfull. -- Please excuse my spelling as I suffer from agraphia. See http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more. Free the Memes. |