What are OOP's Jargons and Complexities?
in [Perl]
|
Prev: swift MT940 files
Next: Is there neq for strings?
From: Xah Lee on 25 May 2005 02:42 The Rise of “Static†versus “Instance†variables In a normal programing language, variables inside functions are used by the function, called local variables. In OOP paradigm, as we've seen, super-subroutines (classes) are assigned to variables (instantiation), and the inner-subroutines (methods) are called thru the variables (objects). Because of this mechanism, what's once known as local variables (class variables) can now also be accessed thru the assigned variable (objet) by design. In OOP parlance, this is to say that a class's variables can be accessed thru the object reference, such as in myObject.data=4. For example: mySurface = new a_surface(); mySurface.coordinatesList={...} // assign initial coordinates However, sometimes a programmer only needs a collection of variables. For exmple, a list of colors: black = "#000000"; gray = "#808080"; green = "#008000"; In pure OOP, data as these now come with a subroutine (class) wrapper: class listOfColors() { black = "#000000"; gray = "#808080"; green = "#008000"; } Now to access these values, normally one needs to assign this subroutine (class) to a variable (instantiation) as to create a object: myColors = new listOfColors(); // instantiation! (creating a "object") newColor = myColors.black; As a workaround of this extraneous step is the birth of the concept of “static†variables. (with the keyword “static†in Java) When a variable is declared static, that variable can be accessed without needing to instantiate its class. Example: class listOfColors() { static black = "#000000"; static gray = "#808080"; static green = "#008000"; } newColor = listOfColors.black; // no instantiation required The issue of staticality is also applicable to inner-subroutines (methods). For example, if you are writing a collection of math functions such as Sine, Cosine, Tangent... etc, you don't really want to create a instance in order to use. Example: class mathFunctions() { static sin (x) {...}; // a static method ... } print mathFunctions.sin(1); // no need to create object before use The non-static variant of variables and methods are called “instance variables†or “instance methodsâ€Â, or collectively “instance membersâ€Â. Note that static members and instance members are very different. With static members, variables and methods can be called without creating a object. But more subtly, for a static variable, there is just one copy of the variable; for instance variables, each object maintains its own copy of the variable. A class can declare just some variables static. So, when multiple objects are created from the class, some variables will share values while others having independent copies. For example: class a_surface() { static pi; // a static variable coordinatesList; // a instance variable ... }; a_surface.pi=3.1415926; // assign value of pi for all a_surface objects mySurface1 = new a_surface(); mySurface1.coordinatesList={...} // assign coordinates to one a_surface object mySurface2 = new a_surface(); mySurface2.coordinatesList={...} // assign coordinates to another a_surface object The issues of static versus instance members, is one complexity arising out of OOP. ---------- 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: Ray Dillinger on 25 May 2005 04:16 Wibble wrote: > Thats how common lisp specifies a vector. > > Andreas, your link indicates that lisp is a Weakly typed language not > strong. Theres no compile time type semantics, at least in CommonLisp, > MacLisp, ZetaLisp or FranzLisp. > > (setq foo #(1 2 3)) > (setq foo 1) > (setq foo "Whatever") > > > Theres no type associated with foo, only with what the variable is > currently referencing. > > From your link: > When the types detected or declared are strictly enforced by the > language's semantics, the language is strongly-typed. > when the semantics of the language allows for inconsistencies between > the compile-time type and the run-time type, the language is > weakly-typed. I think that such terms of art are sufficiently broad and subject to interpretation that it is now necessary for each researcher to say exactly what they mean by a claim placing a language in a category. That definition must be taken into account when interpreting the claims that particular paper makes about those language categories. That so many researchers have chosen to use the same terms (static, dynamic, strongly, weakly ... ) to describe subtly different things is distressing. Bear
From: John McGrath on 25 May 2005 05:49 On 5/23/2005 at 7:54:24 PM, alex goldman wrote: > I'm just curious, what do you mean by strong typing, and which strongly > typed languages do you know? "Strongly typed" is not a very useful term, unless your intent is to generate confusion or start an argument. Unfortunately, there is no consensus as to what the term means. -- Regards, John McGrath
From: Thomas G. Marshall on 25 May 2005 09:45 beliavsky(a)aol.com coughed up: > Thomas G. Marshall wrote: > *Missattributed* --Thomas G. Marshall (I) did /not/ write the following: >>> I am not familiar with modern Fortran. Surely it at least has >>> argument prototyping by now? > > Since the 1990 standard, if Fortran subroutines and functions are > placed in MODULEs, or if INTERFACEs are provided, the compiler checks > that procedures are called with the right types (int or float, scalar > or array, etc.) of arguments. > >> There are some fortran advocates that pop into here now and again. >> Frankly, I'm spooked by how far fortran seems to have come. There >> is even OO support now. OI. > > Some Fortranners think the language has gotten too big and > complicated, sounding a bit like C programmers complaining about C++ > (I don't mean that pejoratively). There are old-poops in every discipline. :) -- Unix users who vehemently argue that the "ln" command has its arguments reversed do not understand much about the design of the utilities. "ln arg1 arg2" sets the arguments in the same order as "mv arg1 arg2". Existing file argument to non-existing argument. And in fact, mv itself is implemented as a link followed by an unlink.
From: Thomas G. Marshall on 25 May 2005 09:47
Xah Lee coughed up: > The Rise of "Static" versus "Instance" variables You are clearly unable to form a proper argument, *AND* you have irritated nearly everyone frequently. <PLONK> Ah....the blessed silence.... |