Por ahí acá resulta medio contradictorio lo que digo, siendo que es inevitable para mi hablar de reusabilidad cuando hablo del paradigma de objetos. En parte esto es porque no considero como un uso apropiado del paradigma aquello que no busque una buena reusabilidad de los algoritmos creados. Sin embargo hay que evitar enseñar a los que introducen en este paradigma que la reusabilidad se obtiene sin costo alguno. En particular hay que evitar dar a entender la reusabilidad como una característica del OOP. Se puede hacer tanto código reusable como pasta-code en OOP como en paradigma procedural o en el paradigma funcional.

En pocas palabras, la reusabilidad no es una característica del OOP, no hay garantías de ello prácticamente en ningún paradigma. PERO, diseñar a partir de simular los procesos reales (característico de OOP), sumado a un cuidado diseño orientado a la reusabilidad, generalmente concluyen en un sistema fácilmente mantenible.

En el foro de ADVA tuvimos con algunos usuarios una discusión bastante acalorada sobre el lenguaje C++ y en general sobre ciertos aspectos del paradigma de objetos. Uno de los temas tocados fue sobre la reusabilidad. Quiero extraer algunos fragmentos de esta discusión. Por ejemplo acá comento sobre la crítica academica al OOP en temas de reusabilidad y la propuesta del GoF y los patrones de diseño:

Algo en lo que insisto siempre es en destronar el mito del OOP como facilitador de la reusabilidad. Usar OOP no garantiza reusabilidad, por el contrario, una de las críticas académicas más fuertes al OOP es que la reusabilidad por herencia resulta en malas prácticas que afecta la mantenibilidad (esa palabra es un trabalenguas) del sistema. En contraposición, el paradigma procedural tiene un modelo de reusabilidad mucho más organizado, que genera una mayor independencia entre componentes.

Sobre esto, el "Grupo de los Cuatro" (Gang of Four) popularizo los términos de "white-box reuse" (reusabilidad a caja abierta) y "black-box reuse" (reusabilidad a caja cerrada). La reusabilidad a caja abierta, o reusabilidad por herencia, es la que es criticada por generar dependencias entre los componentes a la hora de hacer tareas de mantenimiento. La reusabilidad a caja cerrada, o reusabilidad por interfases, es la usada en el paradigma procedural y la que el GoF propone recuperar en el paradigma OO mediante patrones de diseño.

Ahí tengo que admitir que elegí mal las palabras. Puntualmente el OOP, bien usado, puede resultar un facilitador de la reusabilidad. El punto importante es que la reusabilidad no es una garantía, en ningún paradigma de la programación. En particular es una crítica académica que el OOP favorece practicas incorrectas de reusabilidad, pero esto está originado en el mismo ámbito académico que enseña mal el paradigma de objetos.

Acá hay otro extracto de esa discusión donde observo los comentarios de Stroustrup sobre el lenguaje C++ y el paradigma de objetos:

Me tome el tiempo de releer los capítulos iniciales del libro de Stroustrup. En ningún momento plantea el paradigma de objetos como una mejora a la reusabilidad, lo cual era de esperarse, sería una promesa ridícula. En el prefacio habla del OOP como una técnica de abstracción de datos más "flexible y eficiente", lo cual es cierto. Dice "Cuando se les utiliza bien, estas técnicas producen programas más cortos y más fáciles de comprender y mantener". Esto último es en general cierto con el paradigma de objetos. El punto clave es el "buen uso". Después habla del type safety sobre todo.

En el primer capítulo hace una reseña filosófica sobre el lenguaje, donde dice que el lenguaje C está pensado como un "lenguaje cercano a la máquina", y los agregados que se hicieron en C++ son para hacer un "lenguaje cercano al problema a resolver". Hace una reseña bastante interesante que quiero compartir:

"El lenguaje proporciona al programador un conjunto de herramientas conceptuales; si éstas resultan inadecuadas para una tarea, sencillamente se las ignorara. (...) No se puede garantizar el buen diseño y la ausencia de errores sólo por la presencia o ausencia de características específicas del lenguaje."

Es rescatable esto último que dice Stroustrup, y sobre como la intención de C++ es acercar al programador al problema a resolver, esto es en realidad cierto no solo para C++ sino para el paradigma de objetos en general.

Continuo más adelante sobre el tema para no alargar innecesariamente el post.

Mas allá del charlatanerio, hay mucho que se dice sobre la programación orientada a objetos, que realmente no lo es. Cosas como esta superan la norma:

La persistencia es uno de las caracteristicas del POO.

La programación orientada a objetos es solo UNO de los tantos paradigmas para el modelado de algoritmos, y la persistencia NO es una de sus características.

Sus características son:

1. La abstracción orientada a la simulación de los procesos reales.
2. La encapsulación de los actores (objetos/entidades que participan del algoritmo), o sea, la distinción entre interfase y funcionamiento interno.
3. La herencia y el polimorfismo, o sea, la organización taxonómica de los actores y su capacidad de actuar como cualquiera de los tipos que la herencia le permita.

Eso es todo. Cualquier otra cosa que se diga del POO es hablar demás.

A Feladat:

• PHP alapú nemzetközi portálrendszerek fejlesztése egy professzionális csapatban
• Meglévő rendszerek továbbfejlesztése, illetve kreatív új ötletek kidolgozása
   

Szakmai elvárások:

• Min. 3+ év fejlesztési tapasztalat
• Magas fokú PHP (5) ismeretek
• Erős és alapos SQL ismeretek (MySQL 5.x)
• Objektum Orientált programozási háttér (Java vagy C++) vagy OOP teljes körű ismerete
• Javascript és Javascript könyvtárakban szerzett tapasztalat (jQuery, prototype, ExtJS)
• SVN vagy CVS tapasztalat
• Nyílt forráskódú technológiák az alapos ismerete (PHP, MySQL, memcache)
• CSS és HTML részletes ismerete
• Kiváló csapatjátékos, specifikáció alapján önálló, koncentrált munkavégzés
• Junior fejlesztők munkájának koordinálása
• Jó szóbeli és írásbeli kommunikációs készség
• Megbízható, megfontolt személyiség
• Szakmai angol szöveg megértése
   

Előnyt jelent:

• Szakirányú végzettség, szakmai képzések
• PHP-s keretrendszer vagy keretrendszerek használatában szerzet tapasztalat
• Szoftverfejlesztésben szerzett tapasztalat (UML nem követelmény, de előny)
• Szakmai cikkek olvasása, szakmai tudás önállóan történő szinten tartása, fejlesztése
   

Amit kínálunk:

• A legmodernebb technológiák használata
• Fiatal, dinamikus csapat
• Szakmai támogatás és tudásbázis a munkavégzéshez
• Folyamatos fejlődés, kihívások
• Nemzetközi karrierlehetőség
• Kiemelkedő bérezés: Tapasztalattól és szakmai tudástól függően.
• Cafeteria rendszer, céges tréningek, szakmai utak
   

Munkaidő, helyszÍn:

• Modern, jól felszerelt iroda Budapest központjában
• Napi fix, nyolc órás munkaidő

laszlo_spiller@kellyservices.hu

Feladatok:

• Flash Media server, Flash appletek programozása
   

Szakmai elvárások:

• Flash action script (esetleg Java vagy C++) nyelv ismerete
• Több éves programozási, szakmai tapasztalat
• Objektum-orientált szemléletmód
   

Amit kínálunk:

• Kiemelkedő bérezés
• Fiatal, dinamikus, ugyanakkor professzionális csapat
• Szakmai támogatás és tudásbázis a munkavégzéshez
• Folyamatos fejlődés, kihívások
• Nemzetközi karrierlehetőség
• Cafeteria rendszer
   

Munkaidő, helyszín:

• Modern, jól felszerelt iroda Budapest központjában
• Napi fix, nyolc órás munkaidő

laszlo_spiller@kellyservices.hu

Feladatok:

• Nagy látogatottságú, PHP alapú portálrendszerek, illetve közösségi oldalak fejlesztése egy professzionális csapat tagjaként

Szakmai elvárások:

• Szakirányú felsőfokú végzettség
• PHP tapasztalat
• Objektum-orientált fejlesztésbeli jártasság
• SQL ismeretek
• Szakmai angol szöveg megértése
• A feladattal, illetve a munkával kapcsolatban érzett szenvedély és igényesség
• Új technológiák megtanulására való hajlandóság 
   

Előnyt jelent:

• MySQL ismerete
• CSS és HTML ismerete
• JavaScript ismeretek, ezen belül kiemelten JQuery, illetve ExtJS használatában szerzett tapasztalat
• Verziókezelő rendszer ismerete (CVS, SVN)
   

Amit kínálunk:

• Kiemelkedő bérezés
• Fiatal, dinamikus, ugyanakkor professzionális csapat
• Szakmai támogatás és tudásbázis a munkavégzéshez
• Folyamatos fejlődés, kihívások
• Nemzetközi karrierlehetőség
• Cafeteria rendszer
   

Munkaidő, helyszín:

• Modern, jól felszerelt irodánk Budapest központjában található
• Napi fix, nyolc órás munkaidő

laszlo_spiller@kellyservices.hu

A feladat:

• Nagy terhelésű, elosztott rendszerek kiszolgálását végző alkalmazások fejlesztése
• Erőforrás-hatékony alkalmazások fejlesztése
• Fejlesztett eszközök tesztelése
• Fejlesztések folyamatos dokumentálása
• Már meglévő alkalmazások refaktorizálása

Szakmai elvárások:

• Komoly OOP és OOD ismeretek, algoritmikus szemléletmód
• UML tervezési ismeretek
• Hálózat-programozási ismeretek
• Min. 2 éves szakmai tapasztalat
• Szoftverfejlesztési módszertanok és kódolási standardok követése
• Erős háttér Unix/Linux rendszerekre való fejlesztésben

Amit kínálunk:

• A legmodernebb technológiák használata
• Fiatal, dinamikus csapat
• Szakmai támogatás és tudásbázis a munkavégzéshez
• Folyamatos fejlődés, kihívások
• Nemzetközi karrierlehetőség
• Kiemelkedő bérezés: Tapasztalattól és szakmai tudástól függően.
• Cafeteria rendszer, céges tréningek, szakmai utak

Munkaidő, helyszín:

• Modern, jól felszerelt iroda Budapest központjában
• Napi fix, nyolc órás munkaidő

laszlo_spiller@kellyservices.hu

Header file hell. Much like DLL hell on windows, or RPM hell (before yum), header file hell is, I suspect, quite common in C++, and is one of the main reasons it's not my favorite language.

Typically, with C++, as you try to solve whatever problem you're trying to solve (means: get the computer to do some useful work) you are kind of forced to do a bunch of "extra" work, figuring out how to frame the problem in terms of objects and classes, not really that big a deal. But, C++ being, (or trying to be) a strongly typed language, encourages the use of custom enumerated types (over #defines, say), That means, if you want classes to communicate with each other without converting from, say, ints to these enums, both classes have to include the header file that defines these enumerated types. Which means there's a good chance the typedef for the enumeration cannot reside in the header definition file for either class, at least not without putting some thought into it, and moving things around a bit. Why? Because, lets say both (of a mere two) classes define some custom enumeration types, and each class needs to communicate with the other in some way using those types. In that case, if each class includes the header file of the other, and the header file contains guard #ifdefs to prevent being included twice. Well, if there is a circular dependency, things get a bit sticky and non-obvious. You've got to sort it out in one of a number of ways. The easiest way is probably to take these types and separate them out into their own headers. Fine. But look at the time it takes to sort all this out. In C, the params would have been ints, everybody automatically knows what an int is, and #defines would do the job pretty effortlessly, albeit with less compiler meddling to make sure you're doin' it right.

So, anyway, when I left work today, I was in that particular corner of header file hell, from which I will have to extricate myself tomorrow.

There are other corners of header file hell. Suppose you want to try to reuse some C++ code. If you are very lucky, the code will have been designed to be reused, and designed to have been reused in just the manner you're wanting to reuse it. More likely, the code isn't quite so well designed. Instead, it is within a class which is designed such that it fits in well with whatever application it's embedded in. This embedding entails references to all sorts of other classes in the application, types, etc. As you try to extricate the code you're interested in for reuse, you find yourself dragging along more and more header files and classes in an ever expanding network, until, in an epiphany, you realize that this approach will lead you to suck in the entire application eventually. At that point, you start cutting and pasting bits, and reworking the code to fit into your problem space.

Well, that's the bigger of the nuisances I've been facing. There are some smalelr ones as well.
whoDecidedThatIdentifiersLikeThisAreEasyToRead? WasItSomeGermanGuy? iHearGermansTendToBuildCompoundWordsInThisWay. ByWhichIMeanCapitializingWordsButOtherwiseJustCrammingThemTogether. VeryReadableDon'tYouThink?

Why do C++ people like identifiers like that? Are they retarded? Brainwashed? I mean, English sentences, in general, consist mostly of uncapitalized words separated by spaces. That is the most readable way of writing text, and that's what you will find in every instance of fiction, newspaper journalism, magazines, etc., (except possibly some very esoteric and pathological exceptions which are deviating only to make some weird point. ) The closest approximation to this for C or C++ identifiers is lowercase words separated by underscores (as spaces are not an option.)
I_mean_like_this. This_is_far_more_readable_than_the_insane_cramming_method.

So, why, oh why, are C++ programmers so fond of this crazy way of naming variables and functions? I have no idea.

Another nit. I have become used to the linux kernel way of formatting code in the last 6 or 8 years or so. This way of formatting code involves indenting code with tabs, not spaces. And tabs indicate and indent of 8 spaces, not 4, not 3, not 2. When I started on this project, I asked around, "hey, are there any coding conventions, style guidlines, etc., that I should be following? By default, I'm apt to write code formatted like what you'd see in the linux kernel, is that ok?" "Sure, we're not religious about that," I was told. Hmm. Well, today, I get a call. "Hey, I noticed you're using tabs." "yeah.... is that ok?" "well, we'd prefer not." Oooookay. Could've told me that earlier. The problem with this is, my editor of choice is vi. Vi, by default, is very tab friendly, provided you agree that a tab means an 8 space indent. It has various commands that know that (e.g. "<<" will move a line over by one tabstop, "10>>" will move ten lines right by one tab stop, etc. These things are habits that are hardwired into my fingers by now.

Anyway, I converted all my C++ files to use 3 spaces in place of every tab. And, I found (via codeblog that I can add some stuff to the end of the file like this:

// Local Variables:
// c-basic-offset: 3
// indent-tabs-mode: nil
// End:
//
// vim: et sts=3 sw=3

The above teaches vim that, around these parts, there is no such thing as a tab, when you think "tab", put 3 spaces. It even makes "<<" and ">>" work as well. So I'm glad to have found that. I don't have to retrain my fingers. (I couldn't retrain my fingers anyway, as there's plenty of code I still have to work on that adheres to the "no spaces, only tabs" doctrine, so I'm doubly happy that I found a solution that automatically (once implemented) limits its application to only those files which need it, and leaves default behavior alone.)

I had another idea today, while thinking about the C++ identifiers and using capital letters vs. lowercase, and underscores (or not.) It occurred to me that both the underscores and the capital letters require one to use the shift key, which is, although easily learned, an inefficient and overly strenuous finger move, given how frequently it must be executed. I started thinking about those keyboards with the split space bar they had for awhile, the ones where half the space bar was made into a backspace key. Evidently that didn't go over too well, as I don't recall having seen those around lately, but they were around for about a year... maybe that was 2 years ago? I can't remember. Anyway, it occurs to me that if you could get one of those keyboards, and, for whichever thumb you don't normally use for space (I tend to use my right thumb exclusively for space, so for me, the left half of the space bar is unused), dedicate that to the underscore. This way, C style identifiers could be typed in very nearly the normal fashion, just use the "wrong" thumb to hit the space bar... Brilliant idea, no?

First of all, how big is your project? How many projects do you work on? How much functionally are you looking for?

Second of all, do you have enough time and knowledge to build your own framework?

The first step is listing a few features that you need:

• Basic XHTML document generation with the ability to add HTML titles, CSS, JavaScript, Icons etc.
• A global template(or multiple templates) that can changed from page to page or stay static throughout the whole site.
• Simple content placement, pages(determined by the URI)-would be loaded into the template.
• Quick database access.
• Data Sensitization.

...and go from there.

I like using OOP(Object Orientated Programming) for my framework because it makes things so much easier.

It's only as complicated as you make it. Just integrate the features that you need, keep it secure and keep tweaking it until it meets up to your personal standards.

The things that you should look for in any framework before it's used in public:

• Freedom and flexibility
• Quality and performance
• Security

The ultimate goal for your framework should be to save time as well as to give yourself a little extra freedom. All you need to do is write up a plan and start coding:)

Oh, and you might find this site helpful from time to time: PHP.NET

Have Fun!

This has been a great year for me as I was given the opportunity to learn the inner workings of the Drupal CMS. While Drupal is a great CMS/Framework, it is inherently still a prepackaged CMS designed for things that 99% of the community needs. CitySquares unfortunately falls within that other 1%. I must say that we have accomplished quite a bit using Drupal's community modules in conjunction with our own custom written ones. However, there are plans in the works that we would like to implement but just cant within the Drupal framework.

Although all is not lost. With the current iteration running and stable and gaining traffic every week I have the opportunity to turn the page and begin work on the next phase of development. This is an exciting time and I will use this medium to convey the successes as well as the issues as development here continues.

That said, we have decided to scrap our Drupal based architecture in favor of a more extensible framework, Symfony. Symfony is a PHP based OO architecture that resembles Ruby on Rails. Not only will we gain the benefit of switching to a OO style framework but we will be using Doctrine as our ORM and Smarty as our template engine.

The idea is that this combination of technologies will help us alleviate two of the major problems we have  with Drupal, essentially scalability and codability. Ive been toying with some ideas to help eliminate these two thorns in our side that I will discuss at a later time but look forward to hearing my ideas on a full stack horizontal architecture.

I've started realizing I'm a coupon-a-holic, at night I dream about coupons and scenarios - I wake up exhausted because my mind has been crunching numbers all night long. However, when my plan follows through with an amazing savings I realize it's all worth it. I love the intoxicating feeling it gives! This week I had a savings of 82.36 %, now that's what I call success in Game The System!

Purchases:

Savings:

Also, Kroger has ecoupons that you can load to your Kroger Plus Card, they allow you to use the ecoupons for your purchase along with MC's. Three different companies offer these coupons, go here, here, and here to start loading your ecoupons today!

-Game The System!

Here is some example code:

When a generic method overrides another generic method, it inherits the constraints of that method. The overriding method cannot change the inherited constraints.

The following code correctly overrides a generic method:

1. Work on the collection designs prototypal before determining on the fine ordering of operations. Many programmers flamboyant themselves as doing object-oriented programming, but in reality, they ingest organic planning with some outside object-oriented trappings. Ideally, digit should prototypal superior a ordered of cipher objects that wage a formal conception of the software, then impact on the ordering of operations. (This is by no effectuation an unconditional conception though, as the impact of nonindustrial this ordering ofttimes reveals structure in which the goal organisation crapper be refined.)

2. Think in cost of organisation patterns. Design patterns earmark someone to entertainer on eld of problem-solving undergo within the machine power community. Instead of reinventing the wheel, ground not meet garner digit soured the shelf?

3. Use ‘const’ objects and ‘const’ functions whenever possible. If you undergo that an object’s accumulation is never questionable to be modified, then tell the goal to be ‘const’. This module preclude you—or worse, a na๏ve colleague--from unexpectedly modifying its land after on. Of course, digit should also tell the pertinent member functions to be ‘const’ as well, to right oblige this rule.

4. Avoid using open ‘get’ and ‘set’ member functions. Getters and setters are not inherently bad; however, they are ofttimes a clew of slummy cipher abstraction. ‘Get’ and ‘set’ functions implicitly obligate the individual to conceive in cost of the object’s interior accumulation (i.e. some these functions are effort or setting), and such info should ideally be unseeable from the object’s user. Getters and setters hit their place, but gratify ingest them sparingly.

5. Avoid threefold indirection. C programmers are unnatural to impact with pointers, and so they are utilised to having pointers to pointers throughout their code. This crapper ofttimes advance to unclear code, cod to the all-too-familiar problems of NULL references and indicator arithmetic. In contrast, C++ programmers are low no such constraints, cod to the built-in hold for uncertain references in C++; that is, digit crapper ever ingest references to pointers instead, which makes the cipher such easier to understand. (Hint: If a C++ technologist uses threefold indirection, that’s a country clew that he’s ease intellection same an fledgling C hack!)

About the author:

V. B. Velasco Jr., Ph.D. has worked as an electrical and cipher organise for more than a decade. He currently entireness for a biotech concern that provides cryopreserved PBMCs, ELISPOT analyzers and ELISPOT expertise.

In the following code, ZClass is a generic type. It has a single type parameter (T) that has three constraints: YClass type derivation, IA interface derivation, and the constructor constraint. An instance of the T parameter is created in the method called Cast. The instance is then cast in succession to the YClass, IA, and IB interface. The first two casts work as expected. The third cast fails spectacularly. The type parameter is not related to IB. However, the compiler does not notice. Therefore, an exception is raised at run time, which is the worst possible time and underscores the type-unsafe nature of interface cast of generic types.

Generic type parameters cannot be assigned a null or zero. There is no assurance that a type parameter is either a reference or value type, which prevents safely assigning a null or zero value to a type parameter. However, you can test a type parameter against null but not zero. If the comparison succeeds, the type parameter is a reference type. Otherwise, the type parameter is a value type.

This sample code shows some of the permitted and not permitted combinations:

 When inheriting an open constructed type, the constraints of the base class must be repeated in the derived type. Furthermore, the derived type can provide additional constraints on type parameters declared at the base type. This is not applicable to closed constructed types because closed constructed types do not have type parameters or constraints.

Here is sample code combining inheritance of generic types and constraints:

As we surely use the newer version of PHP and want to make our applications cool we'll make it the OOP way. Let's start with writing a simple class to handle our caching. Basically we just want to store information about the directory where to put cached files, amount of time to keep them cached and the actual content of the cache. Our class could look like this:

[sourcecode language="php"]

require_once('ACacheException.php');
require_once('AIOException.php');
class ACache
{

private $strDirectory;

private $intCacheTime;

private $strContent = '';

public function __construct( $strDirectory, $intCacheTime )
{

$this->setDirectory( $strDirectory );
$this->setCacheTime( $intCacheTime );

}

public function setDirectory( $strValue )
{

if( is_dir( $strValue ) )
{

$this->strDirectory = $strValue;

}
else
{

throw new AIOException( 'Not a valid directory: '.$strDirectory );

}

}

public function getDirectory()
{

return $this->strDirectory;

}

public function setCacheTime( $intValue )
{

$this->intCacheTime = intval( $intValue );

}

public function getCacheTime()
{

return $this->intCacheTime;

}

public function startCaching()
{

ob_start();

}

public function stopCaching()
{

$this->strContent = ob_get_contents();

ob_end_clean();

}

public function getCachedContent()
{

return $this->strContent;

}

public function saveCache( $strFilename )
{

$strFullFilePath = $this->getDirectory().$strFilename;

$fp = fopen( $strFullFilePath, 'w+' );

if( $fp )
{

fwrite( $fp, $this->strContent );

fclose( $fp );

}
else
{

throw new AIOException( 'Could not open file for writing: '.
$strFullFilePath );

}

}

public function getCache( $strFilename )
{

$strFullFilePath = $this->getDirectory().$strFilename;

if( file_exists( $strFullFilePath ) &&
filemtime( $strFullFilePath ) > time() - $this->getCacheTime() )
{

return file_get_contents( $strFullFilePath );

}
else
{

throw new ACacheException( 'File '.$strFullFilePath.
' does not exists or is older than '.
$this->getCacheTime().' seconds' );

}

}

}

?>

[/sourcecode]

That was the code, now I will try to explain it a bit. The two "Exception" files included just contain definitions of blank classes extending the Exception class. It's just for us to be able to catch those and know what has actually happened. Then there is a constructor and some setters and getters. Then there are the methods that actually "do something".

startCaching() - starts to cache the output.  Using the ob_start() function we actually turn on the buffer output. This means that everything after it will not be displayed but will be just stored in the buffer.

stopCaching() - yep, you guessed it. We store the contents of the buffer in local variable using ob_get_contents() and then delete the buffer by calling ob_end_clean().

saveCache( $strFilename ) - we would like to save our cached output to a file so we can load it when the next request occurs. The method just tries to create the file and write the data into it.

getCache( $strFilename ) - the method looks for the cached file. When found and the file is not older than our caching time specifies the content is returned.

Simple, isn't it. The very simple example of using this class could look like this:

[sourcecode language="php"]

require_once( 'classes/ACache.php' );

// set up the cache directory and keep files cached for 10 seconds
$cache = new ACache( 'cache/', 10 );

try
{

    $content = $cache->getCache( 'index.html' );

}
catch ( ACacheException $e )
{

    $cache->startCaching();

    echo 'Doing some costy operations in time'.time();

    $cache->stopCaching();

    $cache->saveCache( 'index.html' );

    $content = $cache->getCachedContent();

}

echo $content;

?>

[/sourcecode]

And that's it. Of course you don't need to cache just html output, images or any other files can be cached the same way. That's all folks, until next time.

This code does not compile. The problem is the default constructor. Although prevalent, not every type has a default constructor. A default constructor, or a constructor with no arguments, assigns a default state to an object. The default constructor is called with a parameterless new operator. However, because a default constructor is not guaranteed, the new operator is not universally applicable. Therefore, the new operator is disallowed on type parameters.

The solution is the constructor constraint. The derivation constraint does not help with constructors because derived types do not inherit constructors for the base class. Constructor constraints mandate that a type parameter have a default constructor, which is confirmed at compile time. This allows the new operator to be used with the type parameter. The constructor constraint is added to the where clause and is a new operator. When combined with other constraints, the default constructor constraint must be the last item in the constraint list. The constructor constraint applies only to the default constructor. You are still prevented from using constructors with arguments.

Here is sample code of the constructor constraint. The constructor constraint is used on the ZClass.

The following code has a reference type constraint. Although this code is similar to the code presented in the previous post, a reference type constraint is used instead of a value type constraint. For this reason, the illegal line has moved. You cannot use an integer type with a reference type parameter.

The following code demonstrates the value type constraint. The commented source line uses a reference type, which would cause compile errors because of the value type constraint.

!! PHP5

• http://blog.roodo.com/jaceju/archives/3517185.html
• http://blog.roodo.com/jaceju/archives/5781987.html
• http://blog.roodo.com/jaceju/archives/3549457.html
• http://www.php.net/manual/en/language.oop5.php

Interface and derivation constraints share many of the same rules and restrictions, such as the visibility of the interface constraint exceeding that of the type parameter.

In the following code, the find capability has been added to the Sheet collection. The Find method returns an array of cells that contain a certain value. A comparison is made between the cell and value, where both are the type indicated in the type argument. Types that implement the IComparable interface support comparisons. If a comparison is equal, IComparable .CompareTo returns 0. To support this behavior, an interface constraint for IComparable is added to the type parameter. This is a partial implementation of the Sheet collection that shows Find and related methods. (Some of the code shown previously is omitted.)