lovely weekend except for my french, photography, haunting, bathing and chain-smoking.

and i broke a heel.

jimmy crickets i’ll get those photos  - AUTO HIGH CONTRAST -    make them into a film and posty wosty them on Monday night

Digital agency in west London is looking for a talented flash developer to join their Digital team, you’ll produce highly creative Flash on wide range of online projects.  Your work will demonstrate a balance of creativity, usability, and development expertise.  You’ll produce clean, well structured object orientated code in AS3, and regularly work with video and audio. You’ll spend your time working closely with user experience architects, designers and developers, and project managers, and will be a key member of the team.

Job  Responsibilities

• Take overall responsibility for Flash development for the agency.

• Produce high quality, creative, and technically robust Flash animations and applications

• Work on project teams alongside project managers, IAs, designers, and developers

• Lead and mentor junior and freelance Flash developers

• Constantly trial, shape and improve Flash methodologies and deliverables

• Keep abreast of latest Flash developments and communicate this to internal teams

Required skills

• You’ll have proven experience in Flash development, including animation, action-scripting, and video/audio production. Your specific Flash skills will include:

o  Expertise in AS3, AS2, and object orientated programming

o XML parsing and handling

o  Flash video creation compression and playback

o  JavaScript integration

o Flash accessibility

o Integrating 3rd party libraries and plug-ins

• You’ll have relevant design agency experience

• You’ll have a professional approach and good communication skills. Being organised, pro-active and efficient with excellent attention to detail is an essential aspect of this role.

• You’ll have experience of working with, and mentoring other Flash developers

• You’ll have experience in estimating timescales on Flash projects

Key points:

1. Some kind of portfolio site, even if it’s a play area.

2. Recent work demonstrating an artistic eye, great technical ability & design flair.

3. We don’t want see under-construction.

4. Variety of work is key.

5. They use flash for interaction, so a good user experience is important on your work.

Desirable skills

• Experience with PureMVC and/or FlashMVC frameworks

• Flash and/or Air experience

• Experience of Papervision, or another Flash 3d framework

Collating CV’s  now so if your interested send yours to: neil@majorplayers.co.uk

Object-oriented programming (OOP) is a programming paradigm that uses “objects” to design applications and computer programs. It utilizes several techniques from previously established paradigms, including inheritance, modularity, polymorphism, and encapsulation. Today, many popular programming languages (such as Ada, C++, Delphi, Java, Lisp, SmallTalk, Perl, PHP, Python, Ruby, VB.Net, Visual FoxPro, and Visual Prolog) support OOP.

Object-oriented programming’s roots reach all the way back to the 1960s, when the nascent field of software engineering had begun to discuss the idea of a software crisis. As hardware and software became increasingly complex, how could software quality be maintained? Object-oriented programming addresses this problem by strongly emphasizing modularity in software.

The Simula programming language was the first to introduce the concepts underlying object-oriented programming (objects, classes, subclasses, virtual methods, coroutines, garbage collection and discrete event simulation) as a superset of Algol. Smalltalk was the first programming language to be called “object-oriented”.

Object-oriented programming may be seen as a collection of cooperating objects, as opposed to a traditional view in which a program may be seen as a list of instructions to the computer. In OOP, each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent little machine with a distinct role or responsibility.

Object-oriented programming came into existence because human consciousness, understanding and logic are highly object-oriented. By way of “objectifying” software modules, it is intended to promote greater flexibility and maintainability in programming, and is widely popular in large-scale software engineering. By virtue of its strong emphasis on modularity, object oriented code is intended to be simpler to develop and easier to understand later on, lending itself to more direct analysis, coding, and understanding of complex situations and procedures than less modular programming methods.

Fundamental conceptsA survey of computing literature, identified a number of “quarks,” or fundamental concepts, identified in the strong majority of definitions of OOP. They are:

Class
A class defines the abstract characteristics of a thing (object), including the thing’s characteristics (its attributes or properties) and the things it can do (its behaviors or methods or features). For example, the class Dog would consist of traits shared by all dogs, for example breed, fur color, and the ability to bark. Classes provide modularity and structure in an object-oriented computer program. A class should typically be recognizable to a non-programmer familiar with the problem domain, meaning that the characteristics of the class should make sense in context. Also, the code for a class should be relatively self-contained. Collectively, the properties and methods defined by a class are called members.
Object
A particular instance of a class. The class of Dog defines all possible dogs by listing the characteristics that they can have; the object Lassie is one particular dog, with particular versions of the characteristics. A Dog has fur; Lassie has brown-and-white fur. In programmer jargon, the object Lassie is an instance of the Dog class. The set of values of the attributes of a particular object is called its state.
Method
An object’s abilities. Lassie, being a Dog, has the ability to bark. So bark() is one of Lassie’s methods. She may have other methods as well, for example sit() or eat(). Within the program, using a method should only affect one particular object; all Dogs can bark, but you need one particular dog to do the barking.
Message passing
“The process by which an object sends data to another object or asks the other object to invoke a method.”

Inheritance
In some cases, a class will have “subclasses,” more specialized versions of a class. For example, the class Dog might have sub-classes called Collie, Chihuahua, and GoldenRetriever. In this case, Lassie would be an instance of the Collie subclass. Subclasses inherit attributes and behaviors from their parent classes, and can introduce their own. Suppose the Dog class defines a method called bark() and a property called furColor. Each of its sub-classes (Collie, Chihuahua, and GoldenRetriever) will inherit these members, meaning that the programmer only needs to write the code for them once. Each subclass can alter its inherited traits. So, for example, the Collie class might specify that the default furColor for a collie is brown-and-white. The Chihuahua subclass might specify that the bark() method is high-pitched by default. Subclasses can also add new members. The Chihuahua subclass could add a method called tremble(). So an individual chihuahua instance would use a high-pitched bark() from the Chihuahua subclass, which in turn inherited the usual bark() from Dog. The chihuahua object would also have the tremble() method, but Lassie would not, because she is a Collie, not a Chihuahua. In fact, inheritance is an “is-a” relationship: Lassie is a Collie. A Collie is a Dog. Thus, Lassie inherits the members of both Collies and Dogs. When an object or class inherits its traits from more than one ancestor class, and neither of these ancestors is an ancestor of the other, then it’s called multiple inheritance.

Encapsulation
Conceals the exact details of how a particular class works from objects that use its code or send messages to it. So, for example, the Dog class has a bark() method. The code for the bark() method defines exactly how a bark happens (e.g., by inhale() and then exhale(), at a particular pitch and volume). Timmy, Lassie’s friend, however, does not need to know exactly how she barks. Encapsulation is achieved by specifying which classes may use the members of an object. The result is that each object exposes to any class a certain interface — those members accessible to that class. The reason for encapsulation is to prevent clients of an interface from depending on those parts of the implementation that are likely to change in future, thereby allowing those changes to be made more easily, that is, without changes to clients. For example, an interface can ensure that puppies can only be added to an object of the class Dog by code in that class. Members are often specified as public, protected or private, determining whether they are available to all classes, sub-classes or only the defining class. Some languages go further: Java uses the protected keyword to restrict access also to classes in the same package, and C++ allows one to specify which classes may access any member.

Abstraction
Simplifying complex reality by modeling classes appropriate to the problem, and working at the most appropriate level of inheritance for a given aspect of the problem. For example, Lassie the Dog may be treated as a Dog much of the time, a Collie when necessary to access Collie-specific attributes or behaviors, and as an Animal (perhaps the parent class of Dog) when counting Timmy’s pets.

Polymorphism
Polymorphism is the ability of behavior to vary based on the conditions in which the behavior is invoked, that is, two or more methods, as well as operators (such as +, -, *, among others) can fit to many different conditions. For example, if a Dog is commanded to speak() this may elicit a Bark; if a Pig is commanded to speak() this may elicit an Oink. This is expected because Pig has a particular implementation inside the speak() method. The same happens to class Dog. Considering both of them inherit speak() from Animal, this is an example of Overriding Polymorphism. Another good example is about Overloading Polymorphism, a very common one considering operators, like “+”. Once defined an operator used to add numbers, given a class Number and also given two other classes that inherits from Number, such as Integer and Double. Any programmer expects to add two instances of Double or two instances of Integer in just the same way, and more than this: Any programmer expects the same behavior to any Number. In this case, the programmer must overload the concatenation operator, “+”, by making it able to operate with both Double and Integer instances. The way it is done varies a little bit from one language to another and must be studied in more details according to the programmer interest. Most of the OOP languages support small differences in method signatures as polymorphism. it’s very useful, once it improves code readability, to enable implicit conversions to the correct handling method when apply add() method to integers, like in add(1,2), or to strings like in add(“foo”,”bar”) since the definitions of these signatures are available. In many OOP languages, such method signatures would be, respectively, very similar to add(int a, int b) and add(String a, String b). This is an example of Parametric Polymorphism. The returned type and used modifiers, of course, depend on the programmer interests and intentions.

History

The concept of objects and instances in computing had its first major breakthrough with the PDP-1 system at MIT which was the earliest example of capability based architecture. Another early example was Sketchpad made by Ivan Sutherland in 1963; however, this was an application and not a programming paradigm. Objects as programming entities were introduced in the 1960s in Simula 67, a programming language designed for making simulations, created by Ole-Johan Dahl and Kristen Nygaard of the Norwegian Computing Center in Oslo. Such an approach was a simple extrapolation of concepts earlier used in analog programming. On analog computers, such direct mapping from real-world phenomena/objects to analog phenomena/objects (and conversely), was (and is) called ’simulation’. Simula not only introduced the notion of classes, but also of instances of classes, which is probably the first explicit use of those notions.

The Smalltalk language, which was developed in the 1970s, introduced the term Object-oriented programming to represent the pervasive use of objects and messages as the basis for computation. Smalltalk creators were influenced by the ideas introduced in Simula 67, but Smalltalk was designed to be a fully dynamic system in which classes could be created and modified dynamically rather than simply using static ones. The ideas in Simula 67 were also used in many other languages, from derivatives of Lisp to Pascal.

Object-oriented programming developed as the dominant programming methodology during the mid-1980s, largely due to the influence of C++. Its dominance was further cemented by the rising popularity of graphical user interfaces, for which object-oriented programming is well-suited. OOP toolkits also enhanced the popularity of “event-driven programming”. Some feel that association with GUIs (real or perceived) was what propelled OOP into the programming mainstream.

OOP also became increasingly popular for developing computer games during the 1990s. As the complexity of games grew, as faster hardware became more widely available and compilers matured, more and more games and their engines were written in OOP languages. Since almost all video games feature virtual environments which contain many, often thousands of objects that interact with each other in complex ways, OOP languages are particularly suited for game development.

Object-oriented features have been added to many existing languages during that time, including Ada, BASIC, Lisp, Fortran, Pascal, and others. Adding these features to languages that were not initially designed for them often led to problems with compatibility and maintainability of code.

In the past decade Java has emerged in wide use partially because of its similarity to C++, but perhaps more importantly because of its implementation using a virtual machine that is intended to run code unchanged on many different platforms. This last feature has made it very attractive to larger development shops with heterogeneous environments. Microsoft’s .NET initiative has a similar objective and includes/supports several new languages, or variants of older ones.

Besides Java, probably the most commercially important recent object-oriented languages are Visual Basic .NET and C# designed for Microsoft’s .NET platform.

Just as procedural programming led to refinements of techniques such as structured programming, modern object-oriented software design methods include refinements such as the use of design patterns, design by contract, and modeling languages.

OOP in scripting
In recent years, object-oriented programming has become especially popular in scripting programming languages. Python and Ruby are scripting languages built on OOP principles, while Perl and PHP have been adding object oriented features since Perl 5 and PHP 4.

The Document Object Model of HTML, XHTML, and XML documents on the Internet have bindings to the popular JavaScript/ECMAScript language. JavaScript is perhaps the best known prototype-based programming language.

Problems and patterns

There are a number of programming challenges which a developer encounters regularly in object-oriented design. There are also widely accepted solutions to these problems. The best known are the design patterns codified by Gamma et al, but in a more general sense the term “design patterns” can be used to refer to any general, repeatable solution to a commonly occurring problem in software design. Some of these commonly occurring problems have implications and solutions particular to object-oriented development.

Gang of Four design patterns
Design Patterns: Elements Reusable Object-Oriented Software is an influential book published in 1995 by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, sometimes casually called the “Gang of Four.” Along with exploring the capabilities and pitfalls of object-oriented programming, it describes 23 common programming problems and patterns for solving them.

Object-orientation and databases
Both object-oriented programming and relational database management systems (RDBMSs) are extremely common in software today. Since relational databases don’t store objects directly (though some RDBMSs have object-oriented features to approximate this), there is a general need to bridge the two worlds. There are a number of widely used solutions to this problem. One of the most common is object-relational mapping, as found in libraries like Java Data Objects, and Ruby on Rails’ ActiveRecord.

There are also object databases which can be used to replace RDBMSs, but these have not been as commercially successful as RDBMSs.

Matching real world
OOP can be used to translate from real-world phenomena to program elements (and vice versa). OOP was even invented for the purpose of physical modelling in the Simula-67 programming language. However, not everyone agrees that direct real-world mapping is facilitated by OOP, or is even a worthy goal; Bertrand Meyer argues in Object-Oriented Software Construction that a program is not a model of the world but a model of a model of some part of the world; “Reality is a cousin twice removed”.

Formal definition
There have been several attempts at formalizing the concepts used in object-oriented programming. The following concepts and constructs have been used as interpretations of OOP concepts:

coalgebraic datatypes
existential quantification and modules
recursion
records and record extensions
F-bounded polymorphism

Attempts to find a consensus definition or theory behind objects have not proven very successful, and often diverge widely. For example, some definitions focus on mental activities, and some on mere program structuring. One of the simpler definitions is that OOP is the act of using “map” data structures or arrays that can contain functions and pointers to other maps, all with some syntactic and scoping sugar on top. Inheritance can be performed by cloning the maps (sometimes called “prototyping”).

Above article originally from wikipedia.org. Above article is available under GNU Free Documentation License.

A lot of resource out there about null object pattern. Fundamentally this is a design pattern that describes an object what behave like a null value, but it can be handled as a regular object in the given context.

Let’s see the benefit of this pattern with Doctrine.

Suppose we have a gallery with images. Every gallery have a “preview” image (one from the its images), which represents the gallery in lists (or anywhere else). How can we handle the situation when a gallery has no preview image? (We want to show a “no-image.jpg” there.)

Let’s start with the schema:

Gallery:
  tableName: gallery
  columns:
    id:
      type: integer
      unsigned: true
      notnull: true
      primary: true
      autoincrement: true
    name:
      type: string(200)
    preview_image_id:
      type: integer
      unsigned: true
      notnull: true
  relations:
    PreviewImage:
      local: preview_image_id
      foreign: id
      type: one
      class: Image
Image:
  tableName: image
  columns:
    id:
      type: integer
      unsigned: true
      notnull: true
      primary: true
      autoincrement: true
    gallery_id:
      type: integer
      unsigned: true
      notnull: true
    file:
      type: string(255)
    title:
      type: string(255)
  relations:
    Gallery:
      local: gallery_id
      foreign: id
      foreignAlias: Images
      onDelete: CASCADE

We have a working database schema, where gallery has a foreign key (preview_image_id) to its preview image. The set up of this field is up to the developers. What will happen when we want to show the preview image at this state of model?

First, we add some code to Image model class, to simplify the image handling.

class Image extends BaseImage
{
  const TYPE_ORIGINAL = 1;
  const TYPE_THUMBNAIL = 2;

  // ...
  public function getImageName($type = self::TYPE_ORIGINAL)
  {
    $info = pathinfo($this->file);
    $names = array(
      self::TYPE_ORIGINAL => $this->file,
      self::TYPE_THUMBNAIL => $info['filename'].'_thumb.'.$info['extension'],
    );

    if (!isset($names[$type]))
    {
      throw new InvalidArgumentException();
    }

    return $names[$type];
  }

  public function getImagePath($absolute = true)
  {
    $path = '/uploads/images';
    $absolute_path = sfConfig::get('sf_web_dir').$path;

    if (!file_exists($absolute_path))
    {
      mkdir($absolute_path, 0777, true);
      chmod($absolute_path, 0777);
    }

    return $absolute ? $absolute_path : $path;
  }

  public function getImageFile($type = self::TYPE_ORIGINAL, $absolute = false)
  {
    return $this->getImagePath($absolute).'/'.$this->getImageFile($type);
  }
  // ...
}

So what will happen when we want to show the preview image?

<img src="<?= $gallery->PreviewImage->getImageFile(); ?>" />

It depends on. If we have a setted up preview image, it works well. If not, we have a fatal error. So with this model, we always have to check the foreign field (preview_image_id), it’s a null value or an object. It would be convenient we just use that object ($gallery->PreviewImage), and the object can handle the special case (the null object).

We have to do two things for that:

1. set up Doctrine to give a “fresh” Image object, when we call $gallery->PreviewImage (this will be the null object)
2. have to handle the case when file field is empty

The first constraint can be done easily. Just remove the notnull instruction from the preview_image_id field of Gallery model. With this setup the Doctrine will return a new Image instacne.

The second constraint can be done by small modification of our model code:

class Image extends BaseImage
{
  // ...
  public function getImageName($type = self::TYPE_ORIGINAL)
  {
    if ($this->file)
    {
      $info = pathinfo($this->file);
      $names = array(
        self::TYPE_ORIGINAL => $this->file,
        self::TYPE_THUMBNAIL => $info['filename'].'_thumb.'.$info['extension'],
      );
    }
    else
    {
      $names = array(
        self::TYPE_ORIGINAL => '/images/no_image.jpg',
        self::TYPE_THUMBNAIL => '/images/no_image_thumb.jpg',
      );
    }

    if (!isset($names[$type]))
    {
      throw new InvalidArgumentException();
    }

    return $names[$type];
  }

  public function getImageFile($type = self::TYPE_ORIGINAL, $absolute = false)
  {
    if (!$this->file)
    {
      return $this->getImageName($type);
    }
    return $this->getImagePath($absolute).'/'.$this->getImageFile($type);
  }
  // ...
}

That’s it.

Pusing memahami OOP? ya gitu deh… saya juga mengalami hal tersebut, mungkin saya agak terlambat mempelajari OOP maklum terlalu asik belajar VB yang ga jelas OOP-nya. Setiap saya mempelajari teknik  OOP di java saya selalu membandingkannya dengan Visual Basic 6.0, walhasil saya selalu bingung untuk memulainya.

Untuk para programmer VB yang  mau mencoba pindah ke JAVA, saya berharap jangan putus asa terus berjuang biar bisa buat program yang full OOP.

Pada paragraf ke-dua mungkin saya terlalu berlebihan, tapi terus terang ketika pertama kali mempelajari VB peningkatan skill yang saya alami lebih cepat (ketimbang ketika mempelajari JAVA) mulai dari nol sampai dapat membuat games, program database. harapan saya melalui blog ini dapat membantu rekan-rekan yang mengalami kesulitan dalam mempelajari OOP dengan menggunaka bahasa pemrograman JAVA.

Regards,

Istiqomah Sumadikarta

I came upon this Javascript tutorial by jQuery inventor John Resig (nod to John Gruber). It covered several advanced Javascript topics with the goal of explaining to the reader the meaning of a particularly esoteric bind method from prototype.js. It was fun, and I followed most of it pretty well, although I got a little lost by the end in the section about Enforcing Function Context.

The tutorial included a lesson on pages 35–38 about Javascript constructors which interested me.

First a recap of basic Javascript OOP. In Javascript, objects are defined via functions. To construct an instance of this function, you use the new operator, like so:
function foo(x,y) {this.x = x; this.y = y; }
var instanceOfFoo = new foo(1,2);


Whereas if you want to use a function as a function, you simply call it, like so:

function bar(x,y) {return x + y; }
var valueOfBar = bar(1,2); //this is the standard function call
valueOfBar = bar.call(this,1,2); //this is a more reflective call
valueOfBar = bar.apply(this,[1,2]); //this is even more reflective


So new functionName() to construct an instance of functionName, the OOP object constructor usage of a Javascript function. And just functionName() to to call the function and gets its return value, the functional usage of a Javascript function. Note that if a function is to be used in the functional manner, it must include a return statement; otherwise the value of the function all will be undefined.

The two uses of a Javascript function have different syntax and different semantics. And if you use one where you’re supposed to use the other, your code can fail in unexpected ways. In particular, if you accidentally leave of the keyword new, you won’t get an object, instead you’ll get the return value of the function, or else undefined if there is no return statement.

In addition to the standard Javascript function call, I listed two additional ways to execute a function call which could be said to be more reflective, ie instead of requiring you to write the identifier for the function statically in the source code, it may be determined dynamically at runtime. The first of the two reflective function calls is the Function.call method, which requires you to list the parameters explicitly. The second is the Function.apply method. The second is the more reflective of the two, because it takes an array containing all the arguments, which can be constructed at runtime, rather than requiring they be listed explicitly in the time.

Of note for this blog post is that there isn’t a builtin method like Function.apply which works when using the function as an object constructor. There’s some syntactical incompatibility between the function call and the object constructor which precludes from saying something like new foo.apply(array).

End elementary Javascript recap.

So in the Javascript tutorial, Resig demonstrates some code which ensures that even if you accidentally leave off the new keyword when constructing an object:

function User(first, last){

if ( !(this instanceof User) )
return new User(first, last);

this.name = first + " " + last;
}

The addition of the two lines of code in red give us the functionality to preclude calling this function as a function instead of an object constructor. So if the context in the function is an instance of the calling function itself, then the function was called correctly as constructing an instance of the object. Otherwise, it re-calls the function correctly with the new keyword. Pretty straightforward.

But this code is too static. First we have to reference the particular function we’re in. Then we reference it again, as well as the argument list. If you wanted to rely on this functionality, you’d have to include these two lines in every object constructor in your code, and you’d have to modify the lines for the particular function name and argument list. A massive violation of the principle of DRY.

So then Resig changes the first of the two lines to remove the reference to the function:

if ( !(this instanceof arguments.callee) )
return new User(first, last);

arguments is an array-like object available within the scope of every function. (To make an honest array out of arguments, use Array.prototype.slice.call(arguments)). It contains a list of all the arguments passed to the function (arguments[i] is the ith argument passed to the function), as well as a reference to the function that was called (arguments.callee). We compare the function to the context of the function. The context is available in the function via the this object. If you call the function as an object constructor, then this stores the object instance being constructed, and that object is an instance of function which was called. This this instanceof arguments.callee is true. On the other hand, if you call the function as a standard function call, then this is the global context, usually the browser window where the code is executing, which is, needless to say, not an instance of the function called. So this instanceof arguments.callee is false.

So in the first of the two lines of code, we've successfully removed the reference to the particular function by replacing it with arguments.callee. But it's still present in the second line. We haven't really solved the problem at all. This is where Resig leaves the issue, but I wondered if we could do better. It turns out that we can also replace the reference to the function in the second line:

if ( !(this instanceof arguments.callee) )
return new arguments.callee(first, last);

This is a little better, we've removed all explicit references to the function. However, we still don't have complete generality, because in line two, we still have to list explicitly the arguments to the function, so the code can't be reused without modification. But since we have at our disposal an array containing all the arguments, I thought we should be able to accomplish it. Just like Function.apply allows you to make a function call with arguments taken from the contents of an array, we need something analogous for object instantiation. Something like new foo.apply(this,arguments).

Unfortunately, the obvious guess doesn't work, and after fucking around with different options for a while, I couldn't come up with anything that did. So I turned to The Google, which as always, had the answer. Someone poses the exact problem I'm investigating on stackoverflow, and Matthew Crumley posts a solution:

function construct(constructor, args) {
function F() {
return constructor.apply(this, args);
}
F.prototype = constructor.prototype;
return new F();
}

function User(first, last)
{
if ( !(this instanceof arguments.callee) )
return new construct(arguments.callee,Array.prototype.slice.call(arguments));
this.name = first + " " + last;
}


I've tested this out and it does the job. I imagine perhaps adding it to the Function prototype, so that every function can optionally call it to ensure that it's only used as an object constructor. I do have to say though, I haven't been able to completely understand how the construct function works. It seems to rely on knowing how Javascript internally turns a function into an object, or some other magic that is eluding me.

It's mostly a moot discussion for me. I don't think I would make use of this function. Although I feel like Javascript ought to have an apply method for constructors, or better yet the constructor syntax should be more natural, somehow so that the two uses of the Javascript function are not distinct. But whatever, this is the way Javascript works, and I feel like we should learn it, rather than forcing it to change, rather than correcting it. So I don't see using this method. But it is instructive as a purely academic exercise to learn how it works and think about how it can be extended.

Mac OS X es un hijo de padres muy distintos: NeXTSTEP y Mac OS. Aunque lleva menos de diez años con nosotros, en realidad su gestación ha sido bastante larga. Esta es una continuación del artículo que puedes encontrar aquí.

Como veíamos en la entrada anterior, la elección de la base para el nuevo Mac OS era NeXTSTEP. ¿Pero qué significaba esto? ¿De dónde salía? ¿Qué implicaba eso para la comunidad de usuarios de Macintosh?

El origen de NeXTSTEP

Cuando Steve Jobs salió, más bien poco dignamente, de Apple, decidió que crearía una nueva compañía de computación, inspirado por conversaciones con el ganador del Nobel de química, Paul Berg, acerca de la necesidad de un workstation barato, suficientemente potente para realizar simulaciones científicas en él, de modo que los estudiantes aprendieran ahí en vez de en costosos experimentos. Recordemos que en la época, la división entre computador personal y workstation era muy clara: un computador personal era un equipo con escaso poder, apenas suficiente para mover una aplicación, mientras que los workstation eran equipos muy potentes (para la época). Lo que Jobs se dedicó a crear era, entonces, una especie de intermedio a un precio razonable (lo que no consiguió, era bastante cara para un estudiante universitario).

Y, por supuesto, esta máquina debía tener un sistema operativo. Los ingenieros de NeXT crearon un sistema operativo basado en el núcleo Mach y en Unix BSD. Sin embargo, lo importante es que las capas del sistema destinadas a aplicaciones con interfaz gráfica estaban completamente orientadas a objetos.

¿Y qué es eso? La programación orientada a objetos es un tipo de programación, que en los años en que se fundó NeXT estaba empezando a aumentar en popularidad (dentro de lo que puede ser popular un paradigma de programación). Se trata de construir los programas a través de pequeños fragmentos, llamados objetos, lo que permite una mayor rapidez y fiabilidad al momento de crear las aplicaciones. Además, las interfaces gráficas de usuario se prestaban notablemente para esta forma de programar.

Y efectivamente, en NeXTSTEP este concepto estaba completamente entretejido en el sistema. Esto permitía crear aplicaciones de gran calidad y en un tiempo relativamente rápido. Por lo demás el sistema traía (y trae… pero eso más adelante) utilidades que facilitaban enormemente el desarrollo de aplicaciones, aprovechando algunas características un tanto especiales del lenguaje que usaban los programadores, Objective C.

Estos motivos, principalmente, hacían de NeXTSTEP un sistema bastante avanzado para la época. Mientras tanto, el negocio de computadores NeXT jamás despegó, salvo en ciertos nichos, como algunos bancos. Esto llevó a una redefinición de la compañía: ya no vendería hardware, concentrándose en producir el sistema operativo.

Un detalle importante es que el sistema era originalmente para procesadores Motorola, pero con esa reestructuración, fue necesario convertirlo en multiplataforma. Así, pronto tuvo versiones para SPARC, PA-RISC y, notablemente, procesadores Intel.

¿NeXT, OPEN, Open?

Así, el sistema fue evolucionando, desde la versión 0.8 en 1988 hasta la última, 3.3, en 1995. Pese a sus características, ninguna empresa estuvo mayormente interesada en el sistema. Finalmente, en 1993, fruto de una colaboración entre NeXT y Sun, saldría OpenStep. Esto era un API, es decir, una definición de las capas orientadas a objetos de NeXTSTEP que podía ser usada sobre distintos sistemas operativos (Unix, Solaris, e incluso Windows). La implementación de NeXT fue llamada OPENSTEP (siempre añadiendo confusión con las mayúsculas), lo que en la práctica era NeXTSTEP 4.0.

Sin embargo, pese a ser posible usar OpenStep (sin tanta mayúscula) en casi cualquier sistema operativo, en la práctica ello no ocurrió. Ni siquiera Sun, que había creado junto con NeXT la API la usaba. Es en este estado de cosas cuando ocurre la compra de NeXT por parte de Apple. Lo que haría Apple con OPENSTEP (¿o era OpenStep? ¿o NeXTSTEP? ¿o NextStep?) lo veremos en el próximo capítulo.

A modo de colofón

Ciertamente, podría decir muchas más cosas de NeXTSTEP. Aunque fue usado por muy poca gente, ciertamente tuvo un impacto que no estaba en proporción a la cantidad de usuarios. Por ejemplo, el concepto de World Wide Web y el primer navegador fueron creados por Sir Tim Berners-Lee en 1990 usando un computador NeXT. También otros programas, como Doom o FreeHand, fueron desarrollados principalmente en él.

Además, la interfaz de usuario era bastante avanzada. Antes que escribir sobre ella, prefiero dejar algunas capturas.

Reiniciando NeXTSTEP. La ruedita que sale en la esquina de la pantalla es el ancestro de la pelota de playa de Mac OS X.

En esta captura podemos ver Mail (sí, es de hecho el antecesor del programa que están pensando), con una de sus características más curiosas, lip service, que permitía insertar como adjunto grabaciones de voz hechas directamente en mail. También podemos ver el dock, en el borde derecho.

En esta imagen, además de la misma aplicación Mail (pero en otra versión), podemos ver cosas como el panel de tipografías, que guarda una semejanza sospechosa a otro panel de tipografías bien conocido…

Hablando de eso, quedan varias “reliquias” de NeXTSTEP en OS X. Por ejemplo, el ícono de cámara que aparece al sacar un screenshot de una ventana. Hay otras más, que veremos más adelante, cuando describamos en profundidad los componentes de OS X.

Finalmente, un screenshot de NeXTSTEP 4.0, proyecto que no alcanzó a ver la luz (muero de sueño, permítanme la cursilería)

]]> http://igeeku.wordpress.com/2009/11/19/crearea-plugin-urilor-jquery-partea-1/ Thu, 19 Nov 2009 13:55:44 +0000 igeeku http://igeeku.wordpress.com/2009/11/19/crearea-plugin-urilor-jquery-partea-1/

Scurtă introducere

Dacă te întrebi la ce or fi bune plugin-urile astea jQuery, îți voi spune eu: îți permite extinderea întregii librării jQuery prin adăugarea de noi metode și funcții la aceasta. De exemplu, ai putea crea un plugin care, printr-un singur apel, va parcurge toate link-urile unei pagini, și la fiecare link către un fișier PDF va adăuga o iconiță descriptivă. Apelul va arăta ceva în genul:

$("a").adaugaIconitaPDF();

Idei pentru plugin-uri sunt multe, prea multe chiar, și ca să te convingi poți intra pe pagina de plugin-uri jQuery unde le vei găsi ordonate după categorie. La momentul actual, acolo sunt 3684 de plugin-uri! Deci idei sunt cu tonele, și tot apar plugin-uri zi de zi. Așa că, ori poți sta să cauți plugin-ul care-ți trebuie, ori poți învăța să creezi propriile plugin-uri, lucru despre care voi discuta în următoarele câteva articole.

Să intrăm în pâine!

Pentru început, e nevoie de puțină teorie interesantă. În caz că nu știai deja, jQuery e renumit pentru faptul că poate fi folosit cu ajutorul unui singur caracter: simbolul dolar ($). De puține ori, însă, vei da peste probleme folosind simbolul $, fiindcă nu este singurul framework care face uz de acest simbol. Așa că, pentru a evita conflicte, când este cazul, se poate folosi cuvântul “jQuery“. De exemplu:

jQuery("a").fadeIn();
jQuery.variabila = 2;

Acum să îți spun și care sunt acele puține cazuri când pot apărea conflicte cu simbolul $: când creezi plugin-uri, și când folosești încă un framework împreună cu jQuery, de exemplu ExtJS + jQuery. Știind acum aceste lucruri, să începem cu plugin-urile! Pentru a putea crea plugin-uri, e nevoie să știi jQuery, evident, și care sunt obiectele extensibile din jQuery:

1. jQuery
   • se ocupă cu procesarea internă
   • extinde metode (în alte limbaje de programare sunt cunoscute ca metode statice, sau metode de clasă)
2. jQuery.fn
   • se ocupă de elemente HTML și interacțiunile dintre ele
   • extinde funcții (în alte limbaje de programare sunt cunoscute ca metode de instanță)

Ca să fiu sigur că nu mă vei pierde, îți voi explica ce reprezintă metodele și funcțiile. Dacă ai deja experiență în programarea orientată pe obiecte, poți sări peste paragraful acesta. Deci, metodele pot fi apelate direct, fără a instanția o clasă. Funcțiile, pe de altă parte, pot fi apelate doar asupra unui obiect ce reprezintă o instanță a unei clase. Dacă nu știi nici ce reprezintă instanțierea, e cazul să te oprești aici și să iei un tutorial de POO în C++ sau orice alt limbaj vrei.

Știind acum ce obiecte jQuery pot fi extinse, voi crea un simplu plugin care afișează un mesaj la încărcarea unor elemente HTML. Apelul va fi simplu:

$.mesaj("mesaj la comanda");     //metodă
$("div").mesaj("m-am incarcat"); //funcție

Și acum iată codul, trivial de altfel:

//codul pentru metodă
jQuery.mesaj = function(msg) {
   alert(msg);
};

//codul pentru funcție
jQuery.fn.mesaj = function(msg) {
   alert(msg);
}

Ți se pare complicat ? Dacă da, e grav, fiindcă în următoarele articole se mai complică, fiindcă voi discuta despre:

• variabile locale și globale
• ascunderea variabilelor
• orientarea pe obiecte
• setările plugin-urilor
• funcții cu opțiuni și parametri
• template-urile cele mai utilizate pentru plugin-uri
• și în final, o listă de guidelines, adică un mic ghid

Tim Matts over at his beautiful ecocritical, ecophilosophy blog, Violent Signs, has some updates on the RealPolitik involved in the positioning of SRism, Harmanism and the various splintering pieces of the imagined movement. He focuses on the disseminating instrument - the  ”Collapse” journal - and the coming and anticipated for eco-criticialists, Geo/Philosophy issue Collapse VI. It seems that in the editorial offices there is some worry that the journal will be swallowed up by this emerging Leviathan, ever mutating in its countless discoorinated hydra-heads. Can Collapse stand apart from this growing tide of commercialized thought, can it negotiate the path between meme-like viral fields condensing the aether into impromptu orthodoxy, and the possible failure to hook onto the Next Great Thing?:

Having recently spoken with editor Robin Mackay about the new volume, I can confirm that it is still in preparation, but an announcement will be made soon and advance orders will be possible at that time. Arriving some time in December, “late contributors and general perfectionism have held up publication…” Perhaps more interestingly, Mackay expressed concern over the journal’s affiliation with the latest philosophical trend, stating that “it’s not really centred on ‘SR/OOO’, indeed I’d be happy to distance Collapse from this apparent new orthodoxy!”

It seems that Tim jumped the gun in letting this “distancing” move of the journal out of the bag, and in doing so crossed the no-email-without-permission line that we find to be sacred. Tim felt that this was in good spirits and constructive, an interesting ethical topic in its own right, perhaps to be revisited. Its good to also post the “urbanomic” response, which does not refuse that such a distancing move is necessary, but that it needs to be clarified:

Hi Tim, to clarify – since you’re publicly quoting me from a hurried email response! – it’s not a matter of distancing Collapse from SR/OOO specifically – Rather, from the start the aim of Collapse was to avoid being associated with any philosophical ’school’, and to defy the tendency of philosophers to become jealous partisans of some particular camp or other and to spend their time defining and defending it; both by publishing important philosophical work that doesn’t fit into recognised academic categories – this was the reason for publishing Meillassoux et al in the first place – and by integrating work from outside philosophy.

Although this has always explicitly been its agenda, Collapse has inevitably been characterised in various places as being the ‘official journal of SR’ and suchlike, and even criticised for wavering from ‘real SR’. Whilst I’m more than happy with the association and with playing a part in disseminating that work, I don’t want readers to expect each volume to be some sort of ‘SR update’ and then to be disappointed. That’s why I mentioned it to you, since you were talking about reviewing the new volume as part of an overview of SR/OOO: Collapse played its part, but blogs and other publications will provide a much better overview of the current state of these developments.

I do think that we shouldn’t lose what’s important – the specificity and heterogeneity of each thinker’s work – in the excitement of a ‘next big thing’ and in the drive to determine affiliations and mark out territories.

Wrt your previous post, contrary to appearances, vol. 3 is in fact the best introduction, since it includes the full transcript of the original SR conference (year zero!)

And finally, one of the contributors to the ‘geophilosophy’ volume is Tim Morton, who you also discuss below (’speculative-realist-ecodeconstructionism’ set to become the next ‘next big thing?’

I’m not a great reader of Collapse (it was the home of Harman’s much discussed theory of Causation), but the coming issue certainly does strike a chord of interest, and Tim does a very nice job giving the context of the subject matter. For those of us interested in the local ethic which SR/OOP proliferation involves, the question of what substantive effect this loose theorizing and cadre-building (in particular the Harman/Levi variety) is having upon blogged philosophy, this new Orthodoxy associated chill is perhaps of abiding interest. In this way, as urbanomic says, if Collapse is an “SR update” I’m really not interested in reading it (though perhaps many people will be). Hopefully there will be other, more diverse ideas  involved. From the subject so described, I would have loved to have written on it.

Plus, I look forward to Tim’s promised comments on the question of Orientalization, either in Harman’s thinking (where it runs rampant) or in terms of ecophilosophy.

Levi has an interesting post about quantum mechanics and Speculative Realism. A whole slew of issues arises surrounding epistemological versus ontological realism particularly in regards to the issue of observation and the uncertainty principle. As the Dailykos post he references makes clear, decoherence does not assert that everything depends on observation, but that at some point quantum phenomenon appears as macroscopic reality.  While decoherence does not explain this transition it does not justify, as Gabriel Catren makes clear in his contribution to Collapse V, a mathematized transcendental couplet comprised of observer and experience (or correlationism).

Catren describes physics as a theory of objects made of a formalism (mechanics) and many kinds of objects (such as fields, particles, systems and so forth). The bulk of the essay is dedicated to showing how QM demonstrates objects and qualities as self synthesizing without the need to appeal to a transcendental subject. Objects are then defined as “a set of invariant objective properties that manifests itself through a phenomenological multiplicity of phases.”

But the source of objective or invariant components becomes problematic if objects only ever become other objects ad infinitum. Catren’s response to this is the utilization of universal operators which he likens to Whitehead’s eternal objects also refering to them as universal ideas.  These ideas which make ingressions into nature are discussed in terms of mathematics – any given object is an expression of certain universal measurements or other physical properties.

What I cant grasp is how the universal ideas (if they are to avoid anthrocentrism) can be separated from being a thinkable potentiality such as Deluze’s category of the virtual. Steven Shaviro made this connection some time ago here. It seems that there can be no guarantee as to the contours of conceptualization (via Brassier) or of transformation (against Meillassoux’s logical access to chaos).  This is the crucial importance of identity in the Laruelleian sense. Yet even in Laruelle there is the tension between the object and the point (the object being the zero-point of being).

The issue remains that the object (at least as it is used by Harman and Bryant) is a relocation and shrinkage of being (or ground in the Schellingnian sense) whereas the point (functioning in place of the object) is a formalization of an epistemological limit regarding becoming. For OOO/OOP it seems that being becomes de-humanized (flattened) whereas for tm/neo-vitalism it is the ignorance surrounding the absolute which is flattened or annihilated. The function of thinking in the former remains an enigma.

Also, see Michael’s excellent post here.

A null object mintáról sok helyen lehet olvasni. Alapvetően arról van szó, hogy abban az esetben, amikor egy objektum példányt kellene kapnod (mondjuk egy factory-tól), de az a feltételeknek megfelelő objektumot nem tud biztosítani, akkor nem null-t ad vissza, hanem egy úgynevezett null objektumot, amely típusában, viselkedésében megfelel egy “rendes” objektumnak.

A minta előnye, hogy nem kell folyamatosan vizsgálnunk a kapott értéket (null-e vagy objektum példány), egyszerűen csak használjuk. Hogy mire is jó, arra lássunk egy példát.

Tegyük fel, hogy van egy galériánk, amelyben (mily meglepő) képek találhatók. A galériának van egy kiemelt képe, amellyel megjelenik az oldalon. Feladat: hogyan tudjuk egyszerűen elérni, hogy azok a galériák, amelyeknek nincs kiemelt képe, egy “no-image.jpg”-et jelenítsenek meg?

Kezdjük az elején. A sémával.

Gallery:
  tableName: gallery
  columns:
    id:
      type: integer
      unsigned: true
      notnull: true
      primary: true
      autoincrement: true
    name:
      type: string(200)
    preview_image_id:
      type: integer
      unsigned: true
      notnull: true
  relations:
    PreviewImage:
      local: preview_image_id
      foreign: id
      type: one
      class: Image
Image:
  tableName: picture
  columns:
    id:
      type: integer
      unsigned: true
      notnull: true
      primary: true
      autoincrement: true
    gallery_id:
      type: integer
      unsigned: true
      notnull: true
    file:
      type: string(255)
    title:
      type: string(255)
  relations:
    Gallery:
      local: gallery_id
      foreign: id
      foreignAlias: Images
      onDelete: CASCADE

Ezzel a sémával már működni fog a galéria. Mint látható, a galéria tartalmaz egy preview_image_id mezőt, amely az előképre hivatkozás (ennek a mezőnek a kezelése a fejlesztőre hárul, általában egy, a galériába feltöltött képek közül). Mi történik akkor, ha most megprólájuk megjeleníteni az előképet?

Mindjárt meglátjuk, de előbb írjunk egy kis kódot. Készítsünk egy egyszerű API-t a képek kezeléséhez.

class Image extends BaseImage
{
  const TYPE_ORIGINAL = 1;
  const TYPE_THUMBNAIL = 2;

  // ...
  public function getImageName($type = self::TYPE_ORIGINAL)
  {
    $info = pathinfo($this->file);
    $names = array(
      self::TYPE_ORIGINAL => $this->file,
      self::TYPE_THUMBNAIL => $info['filename'].'_thumb.'.$info['extension'],
    );

    if (!isset($names[$type]))
    {
      throw new InvalidArgumentException();
    }

    return $names[$type];
  }

  public function getImagePath($absolute = true)
  {
    $path = '/uploads/images';
    $absolute_path = sfConfig::get('sf_web_dir').$path;

    if (!file_exists($absolute_path))
    {
      mkdir($absolute_path, 0777, true);
      chmod($absolute_path, 0777);
    }

    return $absolute ? $absolute_path : $path;
  }

  public function getImageFile($type = self::TYPE_ORIGINAL, $absolute = false)
  {
    return $this->getImagePath($absolute).'/'.$this->getImageFile($type);
  }
  // ...
}

Szóval mi történik, ha megpróbáljuk megjeleníteni az előképet?

<img src="<? echo $gallery->PreviewImage->getImageFile(); ?>" />

Hát az attól függ Ha van előkép, akkor megjelenik. Ha nincs, akkor viszont egy fatal error a jutalmunk. Tehát meg kell vizsgálnunk, hogy létezik-e az előkép. Sokkal kényelmesebb lenne, ha előkép beállítás nélkül is egy Image objektumot kapnánk (null object), amelyen meghívva a getImageFile() metódust, az alapértelmezett képet jelenítené meg.

Ehhez két dolog szükséges:

1. a doctrine, beállítás nélkül is egy Image példányt adjon
2. file megadás nélkül az alapértelmezett képet adja vissza

Az első pont könnyen teljesíthető. Változtassunk a sémán. A Gallery preview_image_id mezőjéről vegyük le a notnull előírást. Ekkor a doctrine egy frissen létrehozott Image példányt ad (roppant kellemes működés).

A második ponthoz kicsit át kell írni két metódust: getImageName(), getImageFile().

class Image extends BaseImage
{
  // ...
  public function getImageName($type = self::TYPE_ORIGINAL)
  {
    if ($this->file)
    {
      $info = pathinfo($this->file);
      $names = array(
        self::TYPE_ORIGINAL => $this->file,
        self::TYPE_THUMBNAIL => $info['filename'].'_thumb.'.$info['extension'],
      );
    }
    else
    {
      $names = array(
        self::TYPE_ORIGINAL => '/images/no_image.jpg',
        self::TYPE_THUMBNAIL => '/images/no_image_thumb.jpg',
      );
    }

    if (!isset($names[$type]))
    {
      throw new InvalidArgumentException();
    }

    return $names[$type];
  }

  public function getImageFile($type = self::TYPE_ORIGINAL, $absolute = false)
  {
    if (!$this->file)
    {
      return $this->getImageName($type);
    }
    return $this->getImagePath($absolute).'/'.$this->getImageFile($type);
  }
  // ...
}

Még egyszer kiemelném a Doctrine azon viselkedését, hogy az idegenkulcsról ha eltávolítjuk a notnull előírást, akkor a kapcsolt model lekérésekor nem null-t, hanem üres objektumot kapunk. A modelhez hozzáadott kód nagy előnye, hogy több képet szolgáltató objektum esetén alkalmazva egységes felületet kapunk. Emellett a getImagePath() nagyszerűen használható a feltöltő form validatorának path opciójaként.

Úgy gondolom ennyi. Várom a véleményeket, kritikákat

C++ and C :

C++ evolved from C, which evolved from two previous programming languages, BCPL and B.

BCPL was developed in 1967 by Martin Richards as a language for writing operating-systems software and compilers for operating systems.

The C language was evolved from B by Dennis Ritchie at Bell Laboratories. C uses many important concepts of BCPL and B.

C initially became widely known as the development language of the UNIX

operating system. Today, most operating systems are written in C and/or C++.

American National Standards Institute (ANSI) cooperated with the International Standardization Organization (ISO) to standardize C worldwide; the joint standard document was published in 1990.

C++, an extension of C, was developed by Bjarne Stroustrup in the early 1980s at Bell Laboratories. C++ provides a number of features that “spruce up” the C language, but more importantly, it provides capabilities for object-oriented programming.

Basic Program Construction :

Let’s look at a very simple C++ program. This program is called FIRST, so its source file is FIRST.CPP.

It simply prints a sentence on the screen. Here it is:

#include <iostream>

using namespace std;

int main()

{

cout << “We are TENNIN programmers\n”;

return 0;

}

Despite its small size, this program demonstrates a great deal about the construction of C++

programs. Let’s examine it in detail.

• Functions: Functions are one of the fundamental building blocks of C++. The “FIRST “program consists of a single function called main(). The only parts of this program that are not part of the function are the first two lines. the ones that start with #include and using. (We’ll see what these lines do in a moment.)

• Function Name: The parentheses following the word main are the distinguishing feature of a function. Without the parentheses the compiler would think that main refers to a variable or to some other program element. When we discuss functions in the text, we’ll follow the same convention that C++ uses: We’ll put parentheses following the function name. The word int preceding the function name indicates that this particular function has a return value of type int.

• Braces and the Function Body: The body of a function is surrounded by braces (sometimes called curly brackets). These braces play the same role as the BEGIN and END keywords in some other languages: They surround or delimit a block of program statements. Every function must use this pair of braces around the function body. In this example there are only two statements in the function body: the line starting with cout, and the line starting with return. However, a function body can consist of many.

• Always Start with main()

When you run a C++ program, the first statement executed will be at the beginning of a function called main(). The program may consist of many functions, classes, and other program elements, but on startup, control always goes to main(). If there is no function called main() in your program, an error will be signaled. In most C++ programs, as we’ll see later, main() calls member functions in various objects to carry out the program’s real work. The main() function may also contain calls to other standalone functions

• Program Statements

• cout << “We are TENNIN programmers”;
• return 0;

The first statement tells the computer to display the quoted phrase. Most statements tell the computer to do something. In this respect, statements in C++ are similar to statements in other languages. In fact, as we’ve noted, the majority of statements in C++ are identical to statements in C.

A semicolon signals the end of the statement. This is a crucial part of the syntax but easy to forget. In some languages (like BASIC), the end of a statement is signaled by the end of the line, but that’s not true in C++. If you leave out the semicolon, the compiler will often (although not always) signal an error. The last statement in the function body is return 0;. This tells main() to return the value 0 to whoever called it, in this case the operating system or compiler. We’ll learn more about return later.

• Whitespace

We mentioned that the end of a line isn’t important to a C++ compiler. Actually, the compiler ignores whitespace almost completely. Whitespace is defined as spaces, carriage returns, linefeeds, tabs, vertical tabs, and formfeeds. These characters are invisible to the compiler. You can put several statements on one line, separated by any number of spaces or tabs, or you can run a statement over two or more lines. It’s all the same to the compiler. Thus the FIRST program could be written this way:

#include <iostream>

using

namespace std;

int main () { cout

<<

“We are TENNIN programmers\n”

; return

0;}

We don’t recommend this syntax, it’s nonstandard and hard to read—but it does compile

correctly.

There are several exceptions to the rule that whitespace is invisible to the compiler. The first line of the program, starting with #include, is a preprocessor directive, which must be written on one line.

• Output Using cout

As you have seen, the statement

cout << “We are TENNIN programmers\n”;

causes the phrase in quotation marks to be displayed on the screen. How does this work?

A complete description of this statement requires an understanding of objects, operator overloading, and other topics we won’t discuss until later in the book, but here’s a brief preview. The identifier cout (pronounced “C out”) is actually an object. It is predefined in C++ to correspond to the standard output stream. A stream is an abstraction that refers to a flow of data. The standard output stream normally flows to the screen display—although it can be redirected to other output devices. We’ll discuss streams (and redirection) in Chapter 12, “Streams and Files”.

The operator << is called the insertion or put to operator. It directs the contents of the variable on its right to the object on its left. In FIRST it directs the string constant “Every age has a language of its own\n” to cout, which sends it to the display.

Although the concepts behind the use of cout and << may be obscure at this point, using them is easy.They’ll appear in almost every example program.

• Directives

The two lines that begin the FIRST program are directives. The first is a preprocessor directive, and the second is a using directive.

They occupy a sort of gray area: They’re not part of the basic C++ language, but they’re necessary anyway.

• Preprocessor Directives

The first line of the FIRST program,

#include <iostream>

The preprocessor directive #include tells the compiler to insert another file into your source file. In effect, the #include directive is replaced by the contents of the file indicated. Using an #include directive to insert another file into your source file is similar to pasting a block of text into a document with your word processor.

• Header Files

In the FIRST example, the preprocessor directive #include tells the compiler to add the source file IOSTREAM to the FIRST.CPP source file before compiling. Why do this? IOSTREAM is an example of a header file (sometimes called an include file). It’s concerned with basic input/output operations, and contains declarations that are needed by the cout identifier and the << operator. Without these declarations, the compiler won’t recognize cout and will think << is being used incorrectly. There are many such include files. The newer Standard C++ header files don’t have a file extension, but some older header files, left over from the days of the C language, have the extension .H.

Object Oriented Programing atau yang biasa dikenal dengan OOP adalah suatu pemrograman yang mengarah pada objek. Object oriented juga disebut sebagai paradigma pemrograman. Procedural Programming atau biasa disebut dengan pemrograman terstruktur adalah pemrograman yang disusun berdasarkan urutan tertentu. Perbedaan mendasar antara OOP dan pemrograman terstruktur adalah:

Dengan menggunakan OOP maka dalam melakukan pemecahan suatu masalah kita tidak melihat bagaimana cara menyelesaikan suatu masalah tersebut (terstruktur) tetapi objek-objek apa yang dapat melakukan pemecahan masalah tersebut. Sedangkan untuk pemrograman terstruktur, menggunakan prosedur/tata cara yang teratur untuk mengoperasikan data struktur Untuk tata nama, keduanya pun memiliki tatanan yang sama walaupun memiliki pengertian tersendiri: object oriented menggunakan “method” sedangkan terstruktur menggunakan “function”. Bila di OOP sering didengar mengenai “objects” maka di terstruktur kita mengenalnya dengan ” modules”. Begitu pula halnya dengan “message” pada OO dan “argument” pada terstruktur. “attribute” pada OO juga memiliki tatanan nama yang sepadan dengan “variabel” pada pemrograman terstruktur. Persamaan kedua pemrogaman adalah keduanya termasuk ke dalam pemodelan pemrograman yang digunakan dewasa ini. Mana yang lebih baik tidak ada yang dapat dikatakan lebih baik karena keduanya memiliki spesifikasi tersendiri dalam pemrogramannya. Hal ini juga tergantung pada bagaimana pribadi si pemrogram ingin menyusun program yang akan dibuatnya. Apakah lebih suka menggunakan yang berorientasikan pada objek maupun pemrograman yang terstruktur. Kapan sama2 baik Pemrograman prosedural akan dikatakan lebih baik apabila dalam segala situasi melibatkan kompleksitas moderat atau yang memerlukan signifikan kemudahan maintainability. Manfaat yang dirasakan dalam penggunaan pemrograman prosedural adalah kemampuan kembali menggunakan kode yang sama tanpa menggunakan kode yang berbeda ataupun mengkopinya kembali. Dengan menggunakan “goto”, memudahkan programmer melacak kumpulan data sehingga menghindarkan pemrograman terstruktur menjadi seperti spagethii code. Pemrograman berorientasikan objek dikatakan lebih baik apabila Model data berorientasi objek dikatakan dapat memberi fleksibilitas yang lebih, kemudahan mengubah program, dan digunakan luas dalam teknik piranti lunak skala besar. Lebih jauh lagi, pendukung OOP mengklaim bahwa OOP lebih mudah dipelajari bagi pemula dibanding dengan pendekatan sebelumnya, dan pendekatan OOP lebih mudah dikembangkan dan dirawat.