Posts Tagged ‘PHP’

« Older Entries
Newer Entries »

SPL Iterator Helper Functions

Monday, April 7th, 2008

Introduction

These PHP 5.1 functions are to help handle Iterators.

There is no current information on the speed benchmarks of these functions compared to userland functions. These functions are C implementations, so one could assume they would be quicker.

Iterator Count

Counts the elements in any Iterator. Clones the Countable interface functionality for Iterators that don’t implement Countable.

$array = array('key1' => 'value1', 'key2' => 'value2');

echo iterator_count(new ArrayIterator($array));

Iterator To Array

Copies an Iterator to an array.

$array = array('key1' => 'value1', 'key2' => 'value2');

$newarray = iterator_to_array(new ArrayIterator($array));

Possibly Related Posts:


Tags: , ,
Posted in General | Comments Off

SPL IteratorAggregate

Sunday, April 6th, 2008

Introduction

Iterator Aggregation allows you to develop without rewriting a lot of the same code for classes. It is simple to implement with only one method in the interface. The method getIterator must return an Iterator object for it to work in foreach.

Interface

interface IteratorAggregate
{
   function getIterator();
}

Example

You can aggregate to PHP extensions that implement a iterator object. If you need to pass XML, you can create a new SimpleXML class giving XML iteration without having to implement it yourself. 

class XmlPageViewer implements IteratorAggregate
{
    // My Methods here	 

    public function getIterator()
    {
        return new SimpleXMLElement($this->xml);
    }
}

Possibly Related Posts:


Tags: , , ,
Posted in General | Comments Off

SPL Iterator

Saturday, April 5th, 2008

Introduction

The SPL Iterator allows for an object to be used in foreach loops.

foreach($object as $current)
{
    // Do Stuff.
}

Iterator Interface

interface Iterator
{
    function key();

    function current();

    function next();

    function valid();

    function rewind();
}

The execution path of the Iterator is as follows:

  1. Rewind() : Only called at the start of the Iteration and won’t be called until it is used in another foreach loop.
  2. Next()
  3. Valid()
  4. Current()
  5. Key() : Called Last because it is ”Optional”.

Rewind

For every foreach loop that you use the Iterator Object, rewind will be called to reset the elements. This method is called before the iteration starts. For example, it is like this.

$iterator->rewind();

while($iterator->valid())
{
    $key = $iterator->key();
    $current = $iterator->current();

    $iterator->next();
}

Except, you only have to give the variables for the key and current. Saves a lot of work in the long run.

Next

You don’t have to check whether there is another element after the current one, do the checking in the valid method. Just move to the next element.

Valid

Return true if there is a ”’current”’ element available or false when the end has been reached.

Current

Most used method and you can return any information that the user needs here. Don’t return multiple elements for the user.

Key

The key entry is optional in the foreach loop, so if you are going to use it to return data, you should specify in the manual. Most likely candidates for key are if you have multiple levels of iteration

foreach($iterator as $key => $currentObj)
{
    echo $key;
    foreach($currentObj as $key => $current)
    {

    }
}

Others are for returning the number of iterations that were preformed or what number the row is at. I used it to return the table name for one project. Carefully consideration should be taken for what is returned in the key method. Return nothing and only use current if you are unsure.

Examples

”’There is no guarantee that the code is functional.”’

Array Iterator

class MyArrayIterator implements Iterator
{
    protected $dataStore = null;

    // Array hinting was added in 5.1.x,
    // in PHP 5.0.x, is_array($data) should be used
    public function __construct(array $data)
    {
        if(is_array($data)) { // For PHP 5.0.x
            $this->dataStore = $data;
        }
    }

    public function key()
    {
        return key($this->dataStore);
    }

    public function current()
    {
        return current($this->dataStore);
    }

    public function next()
    {
        return next($this->dataStore);
    }

    public function rewind()
    {
        return reset($this->dataStore);
    }

    public function valid()
    {
        // When Next passes over the end of the array,
        // current() should return false. Needs to be tested.
        return (bool) $this->current();
    }
}

Mysql Iterator

class MysqlIterator implements Iterator
{
    protected $row = null;
    protected $query = null;

    public function __construct($query)
    {
        if(is_string($query)) {
            $this->query = mysql_query($query);
        } else if(is_resource($query)) {
            $this->query = $query;
        }
    }

    public function key() { } // Not Implemented

    public function current()
    {
        if($this->row != null)
        {
            return $this->row;
        }
    }

    public function next()
    {
        $this->row = mysql_fetch_assoc($this->query);
        return $this->row;
    }

    public function rewind()
    {
        $this->row = mysql_data_seek($this->query, 0);
        return $this->row;
    }

    public function valid()
    {
        if($this->row == false) {
            return false;
        }

        return true;
    }
}

Possibly Related Posts:


Tags: , ,
Posted in General | 1 Comment »

Talk at WordCamp Dallas 2008

Thursday, April 3rd, 2008

I think my session has more in common with Mike Naberezny’s talk at OSCON. The video will be coming out, but you’ll probably realize that Mike knows more than me on the subject. I am just guessing, but you can compare and contrast.

My focus was to get more people to build test cases for the Automattic WordPress Tests automated test suite, which focuses more on integration testing (what I commonly call functional testing, albeit inaccurately, but it is a habit).

I look forward to slides for Mike’s talk, which hopefully is released afterwards. I’ll like to be able to go next year, if another testing methodology presentation is given. I’ve been learning about automated testing for the past year and what the different methods can offer. I hope to graduate to understand what smoke tests and all of the other testing that Mozilla does. It would be interesting to apply those methods to other projects of mine and find out whether or not the quality improves.

My hope is that such a talk won’t be needed again next year, because WordPress would have finally grown up and completed several Quality Assurance projects. It would be nice to not have to read how poorly written the application I use is, because then I feel as if they are somehow implying that my code is also bad.

As an aside, when did Planet PHP syndicate, so many great blogs? Wow, just wow.

Possibly Related Posts:


Tags: , , , ,
Posted in General | Comments Off

Loading PHP Files in a PHP Extension

Saturday, March 8th, 2008

Just so I don’t forget again. Special thanks to Johannes S. on the PHP Internals list.

However, my problem is that I want to have the included PHP files with every PHP process, but only do that once. If the PHP files were in the include path, then they would still have to be included, but somehow I want the extension to include them and have them available.

First Method

The first method is not so much that it is impossible as it is impractical. Mostly when an extension is made, it is either a DLL or a SO file, or it is compiled into PHP. The PHP files can’t be included in the compilation, so they won’t make it in the DLL or SO or be compiled into PHP.

Therefore, it can be assumed in that case, that providing a relative link from C++ is impossible, because there is no way to know where the files will end up (unless you use PEAR, but even then it isn’t absolute). So you can’t just say.

PHP_MINIT(something)
{
    // Get file handle by using zend file handle struct

    zend_execute_scripts(...); // Run in a loop to include all files.
}

Unless you could get the PHP include path (which I believe you can, but I’m unsure how) and check each of those for the files. Then however, the reason you would use PEAR is to automate everything. Somehow, the PHP files how to end up in the PEAR directory or some directory that PHP has access to or is in the include path.

Second Method

The second method is using PEAR to automate the process of moving the PHP files, however if the files are in the include path, then there is no need to use zend_execute_scripts().

In this way, if the User didn’t know about the files, they wouldn’t have to try to include them. If they don’t try to include them, then my extension can do so and during the PHP_MINIT() process.

So the process then becomes:

  1. Build PEAR package
  2. Get PHP include Path
  3. In MINIT(), Search for files and if they exist loop through zend_execute_scripts()

Best Method

The best method would be to just rewrite the files as C/C++ which would increase performance better. However, it is in my opinion, that while that is the case, if you are depending on an external PHP library and want some performance, and want to only compile the scripts once per process (if the process is kept running for a long time), which might at least keep the library in memory for each PHP run after the first providing at least some advantage. If you don’t want to keep playing catchup with the external library, then the second method will work best.

If playing catchup every time a new release is made is no issue because of performance, then converting the PHP to C/C++ would work best. I’m of the mind, that using both methods to write the most used in C/C++ and then having the rest in PHP files is better.

I’m not going to write any code at this time.

Possibly Related Posts:


Tags: , , ,
Posted in Programming | Comments Off

PHP5: Answering the Critics

Thursday, February 21st, 2008

WordPress Weekly episode 6 had some comments about PHP5, that I want to address. It should be noted that they were referring to Matt Mullenweg’s interview at Yahoo!.

To me the argument that Matt was making was that End Users don’t care what language a project is in, as long as they are able to use it. This is true and there is enough proof out there with other consumer products to provide the evidence to support that statement. People only care about one thing, “does it work?” and if it doesn’t then they’ll either find something else that does or if they care enough or have enough patience will try to get it to work (as long as it isn’t the original product that is at fault).

The arguments against Matt’s are developer centric. I will only code in PHP5 for web development, except for a few rare occasions. Those being when I’m writing patches for WordPress, or when I am on a server that only supports PHP4. Both instances are rare in and of themselves, so it isn’t like I’m back in the dark ages. However, PHP4 isn’t that terrible, but in truth PHP4 answered a lot of complaints that a lot of developers had with PHP3. PHP5 offers a lot of enhancements over PHP4, but the amount of people really passionate about them don’t seem to be near the amount of the fans of PHP4 when it was initially released.

The fact that patches have to support PHP4 does limit what I will want to do, because I don’t want to duplicate and back-port something that already exists within PHP5. Likewise, I wouldn’t build a JSON library for converting PHP variables, because that already exists in PECL and is in PHP 5.2.x by default. It would be a waste of time to try to attempt to do so now, since the majority of hosts should be switching to PHP5 anyway.

The second fact is that PHP4 is already in end of life and will only receive security fixes until 8/08/2008 and after that, every bug, whether general or security related is not going to be fixed for any PHP4 version. This means, that WordPress will have to provide any work around for PHP security defects in any affected function. WordPress is also not going to provide any patches for PHP4, so I mean, it isn’t like users of PHP4 will be able to get the fixes from WordPress community. Only user land fixes can be made and sometimes you need to have low level fixes instead. It is very difficult to prevent a stack overflow in userland PHP.

The argument about hosts is that, most shared hosts already support running either PHP4 or PHP5. The statistics reported are just the versions users are running at that time. So even though, the user can easily switch to PHP5, if the user wanted to, but people are making the argument that they don’t even have PHP5, when they do.

I say this with only minor experience with dedicated servers, which I’ve found are extremely difficult to upgrade unless you know someone who knows what they are doing. Site down for 10-30 minutes to upgrade PHP is okay. Site down for 5 hours to 3 days before you completely botched the PHP installation is not cool. If a cluster is not used and the system administration skill level is low, then the odds of keeping up to date are pretty slim.

Doesn’t Have Any Real “Killer Features”

One of the quotes was that, “PHP5 doesn’t have any real killer features that make you need to move away from PHP4…” Okay, this is really based on opinion. I would have to say that either the commenter hasn’t touched PHP5, or just used any one of the great features in any depth. These are just a few of the “killer features” I think PHP5 has and that I think others would enjoy if they switched over to PHP5.

  1. Database Access Abstraction

    To most people who created their own simple database access abstraction, know what a boon and awesome extension PDO is. It is available by default in PHP versions 5.1+. To compare with WordPress, you can replace the entire WPDB class with PDO instance. It would only slight improve the database SQL abstraction, as you would still need to intercept MySQL SQL statements and convert them to the SQL that the database supported can understand.

    I’ve built a project, where I was easily able to support both MySQL and SQLite. I could further extend support to any number of other DBMS without having to touch the access layer. This same technique could be used with WordPress to implement an extremely flexible SQL abstraction to where it pulls the SQL from any data source.

    Furthermore, WordPress implements a prepare feature that PDO already has, which in PDO is better and faster.

  2. Filter Extension

    Have security issues with filtering input? Not any more. The filter extension allows for handling input with built in techniques or hooking another function in to do the work instead. All of the complaints about WordPress would instantly cease to be relevant.

    Now, the Filter extension isn’t a cure-all solution, but by using it throughout you offer a standard interface by either using the filter extension library functions or by building an application sanitizing and validating library around it. The reason you would wrap the filter extension is if it isn’t available (using PHP 5.1 or server admin forgot to install or forgot to enable the filter extension) or if you already have an established library.

    WordPress offers a lot for sanitizing and validation, but it can offer more. The Filter extension could be a good solution to solve that problem. I think it is great, but it really isn’t a “killer feature”.

  3. JSON

    JSON, isn’t difficult enough that if you don’t have dynamic data structure changes, that you can write the JSON out for yourself. However, you do have less of a chance of making an error and risk not having your AJAX call work by using the one function it takes to encode a PHP variable to JSON syntax.

  4. XML Capabilities

    Between SimpleXML, DOM, XMLReader, and XMLWriter, I think all of your XML headaches will cease to be. Each of the extensions have their advantages and disadvantages, but it totally wins over regex or DOMXML alone (PHP 4.3+, not including PHP 5.0+ which replaced it with DOM).

  5. SPL

    Iterators, DirectorIterator, and ArrayAccess, might not mean anything to you, but to me, it means that my objects can kick your loser PHP4 objects’ asses. Everytime I’m iterating over a directory, I kiss the ground DirectoryIterator walks on, because it includes everything I’ll ever need in one very simple to use class.

    As for Iterators, why return an array from either a method or function, when you can just loop over the object and get back relevant data. WP_Category_Iterator anyone? I’ll tell you right now, if it was available, a lot of developers would be rushing to use PHP5.

  6. SOAP

    I have heard many people shout the praises with having a built-in solution for SOAP. I don’t use it and I suspect others don’t as well. From the criticisms, it isn’t perfect, but for those that it does help, it is that one killer feature.

  7. Improved Object Oriented Support

    If you don’t do OO, then this means nothing to you, but for me, it is the one reason I will only code in PHP5+. The above features are just extra advantages to keep me coming back to PHP5. If you do care about interfaces

  8. Increase Speed Performance

    This is based off a recent benchmark of PHP4 and PHP5 versions. I think for those that speed matters, will enjoy the increase that PHP5 offers. It should be noted that for most tasks it only means a few milliseconds (if even that), but those do eventually add up to a lot.

Of course, for someone else, they will have a different set of features or just might not think anything in PHP5 is that great. In my experience, I don’t know how I lived without these features. I just suggest looking into these above features more before you decide that PHP5 is a non-event.

“…PHP6 won’t be PHP4 compatible…”

That statement is false. The only parts that won’t be compatible are if they applications depends on Register Globals (which shouldn’t anyway since PHP 4.2), safe mode, or magic quotes. Those that don’t depend on those three should have only a few minor issues depending on whether they are using a function that has been deprecated since PHP4 or PHP3 (I’m referring to the E_DEPRECATED error level that might be part of PHP 5.3 and PHP6).

There might be others, but until PHP6 is released, I think people should hold off on statements, because it is like saying PHP 5.3 is going to have namespaces. Right at this moment it does, but that can change in the future (or might have already changed since I last looked at the debate). It can be pulled just like it was for PHP 5.0. That only sure thing about PHP 6.0, is that it is going to have Unicode, which shouldn’t affect the majority of string functions out there.

Until PHP 6 is released, I think the only ones that know now verses those that will know then when everyone will know, are the ones that are developing PHP or watching the Internals.

Possibly Related Posts:


Tags:
Posted in General | 12 Comments »

Reason I Would Stay with WordPress

Sunday, January 6th, 2008

To be honest, I’ve often thought about leaving WordPress and moving to another application. S9Y seems attractive. Padraic has it and it has features that I would very much like to have. However, that was before WordPress 2.3 came out.

In response to Hello Habari on Elizabeth’s blog, I think WordPress gets a lot of grief for its architecture. In Elizabeth’s case, it was because she was on an outdated version. A lot of changes were made since WordPress 1.2 and 1.5. A lot of changes are being made for WordPress 2.5.

To shun WordPress because of past mistakes when not really diving into the current code base is a mistake in my opinion. However, I used to think the same and I’ve been using and upgrading WordPress since the 1.2 days. I think that is where we diverge, is the upgrading part.

Habari Quick Code Review

Habari made several mistakes, I believe. It does do a few things right however. I mean this is the opinion of a former haterz of WordPress core. When you really get in to the community of WordPress, the misconceptions really break apart.

  1. Complex File and Folder Structure

    I do not think that the WordPress structure is broken, in that it needs to be “fixed” with a more complex file and directory. WordPress has three folders descriptive named “admin”, “content”, and “includes” with a prefix, “wp-”. The directory structure for Habari is not as intuitive.

  2. Starting from the Ground Up does not automatically make you better.

    I often thought of forking WordPress to create a complete OO based WordPress system. The thought did not occur to me to rewrite WordPress, because I’m only one person and it would take many years to get where WordPress is now. Granted the Habari team did have a falling out from the WordPress team for some reason or another back in the 1.2 – 2.0 days.

    For them to get where WordPress is now, it is a long and hard road of them. Also, there have been many contributors to WordPress over the past four years, including many of the Habari team. I think that while the base of WordPress grows from the usage and those users contribute back in the form of patches, it will increase the stability of the core further.

  3. WordPress Codex verses Habari Codex

    I do agree that Habari has the foundation for making for great documentation down the road towards a gradual stable 1.0.0 release. WordPress has had many years of documentation contributors ahead of the team.

    The WordPress codex is not what you would call complete, with details that sparsely cover some obscure but highly needed, while others are well covered, but most of the content worthless.

    It would not be difficult for Habari to defeat WordPress in the area of codex documentation if they cover first the areas of matters to the Users, and then focus on the more broad attention to what developers care about.

  4. Habari uses PDO, WordPress uses mysql extension

    In a PHP 5 OO fork of WordPress, PDO would make for a better replacement of the WPDB abstraction that WordPress uses. My experience with writing cross SQL queries for SQLite and Mysql has been great using PDO. However, my method probably would not be inline with Habari or WordPress.

  5. Habari restricts you to one class for plugins

    False! *Updated! As it has been pointed out by others, the Plugin API of Habari is quite powerful, even more so than WordPress.

    One of my biggest complaints with several WordPress plugins that I’ve came across is that when classes are used, the design pattern is Singleton. Habari requires that you use this model for your plugin. The problem is that for complex plugins, your class could be massive.

    The only benefit is that it uses reflection (which is slow by the way) to automatically hook the methods into the actions and filters. In WordPress this is a manual process.

    However, I think it should be a manual process. Copying .NET framework in this regard is a mistake. However, C# and .NET framework do not restrict you to using only one class for all of the “hooks”. You have full freedom to tell .NET which method and class to call and also the name of the method.

    For PHP at least, they should just had stuck with WordPress’s plugin API, but extended it to be Object Oriented. That is one thing that primarily halted me from joining that project last October.

  6. WordPress has Unit Tests too

    I’ve looked at the unit tests for S9Y last year and found one. Habari has a few, but WordPress has more than both combined. The automated testing for WordPress is ongoing and while the entirely of WordPress is not covered, the same can be said for Habari and S9Y.

  7. Habari’s Object Oriented Goodness

    Does OOP make your application better than procedural code? No. Habari does get bonus points from me at least for having a clean Object Oriented class framework. It is beautiful, really beautiful.

    However, I don’t think WordPress should move to a complete Object Oriented system. What it has now is a system that a majority of novice users can pick up rather quickly without needing experience and knowledge of how OOP works.

    Procedural is much easier to explain to a novice. It becomes magnitudes harder to explain concepts of inheritance when the user has to follow the flow down to base classes and figure out if the child class overrides the parent method with its own method.

    When WordPress gains an OO backend for all core library components, I don’t believe they will replace and remove the procedural library. The users you want to cater to, are the novices and designers who want to build themes using an easy to comprehend system and as much as I hate to say it, while OO can provide that, it doesn’t when novices want to crack up the hood and see what drives the functionality.

  8. Habari has good inline Documentation

    I can look and see that all of the methods and classes I’ve looked at have at least phpdoc short descriptions, parameter type/descriptions, and return type/description. Some of the methods could use with long descriptions, it would be time consuming or difficult to add that for the core.

    This is something that WordPress needs and something that WordPress is gaining slowly. It wouldn’t be that difficult to get WordPress up to grade where Habari is, in the area of documentation.

Is WordPress really that broken?

The primary rebuttal I have is the argument that Habari is better because of the cleaner code, documentation, and general OO base. While those are great for moving forward, it will take quite a while for Habari to get the sort of base that WordPress has. However, if Elizabeth wishes to move over from the attitudes based on PHP IRC, the more power to her.

While I don’t and haven’t always agreed with the direction WordPress has taken and the position of supporting PHP 4.2.0. I think the primary focus of what drives WordPress is the users and what users need. As always WordPress and Habari is a community driven development. The core team can’t do everything.

I’ve learned a great deal from working with WordPress in the past four months. I’ve very much enjoyed the community’s insight, contributions, and general friendliness. Friendly now even through I was an asshole at the beginning.

I believe there was a discussion on moving to HTML Purifier that was shot down for some asinine reason and I proceeded to debate them on the subject as to why HTML Purifier was a better solution than Kses.

I still think HTML Purifier would be a great replacement for Kses. I’ve been using it for this blog and a lot of the problems that others are having with Kses don’t affect me.

Leaving WordPress Behind

I’m halting my involvement with WordPress to work on Astrum Futura again. I do plan to take what I’ve learned on the plugin model and duplicate it for Astrum Futura.

WordPress has also injected its template procedural model on my development style also. I may use objects for the core, but when building the templating, I’m more incline to use procedural.

I think many novice and intermediate developers can learn a lot from WordPress, when they get passed their misconceptions and misgivings that they may have for WordPress.

Possibly Related Posts:


Tags:
Posted in General | 7 Comments »

Which hosts are still running PHP 4.2?

Sunday, December 23rd, 2007

Can you do the rest of us a favor and I don’t know, upgrade? For Christmas!

Checking the statistics, it seems that there is still a small percentage running this. I have found a few hosts offering 4.3.x, I have yet to find a host that offers 4.2 hosting. I wonder if those hosts running PHP 4.2 are dedicated. I wonder if they have applied the security patches or locked down their server.

I would rather use the argument, “Support PHP 4.2? But no one runs that version anymore!”

That would be a false statement or a lie since I already know beforehand.

Merry Christmas! (for you Christians or anyone that worships Santa, Happy Holidays for all the rest of you).

Possibly Related Posts:


Tags:
Posted in General | Comments Off

Zend Studio Neon

Saturday, December 15th, 2007

I’ve been using Zend Studio Neon for the past three weeks and I have to say, for something that is free (beta software) it is quite good. Compared to using VS 2005, Zend Studio Neon has its advantages, since Visual Studio doesn’t handle PHP well. Zend Studio Neon also has areas that I didn’t like.

What I love about Zend Studio Neon

  1. It is not Eclipse

    Well, technically it is and while I haven’t completely played around with PDT, I can say that I don’t like developing PHP in plain Eclipse. Tried Eclipse for an hour. Hated it. Tried PDT for three hours, couldn’t get Subversion plugin to work. Hated it. Spent the last three weeks at work and at home developing with Zend Studio Neon. Love it.

    It has missing features that Visual Studio and Dreamweaver have, but hell, I can always switch to those applications when I need to use them and still maintain my projects in Zend Studio Neon. Well, I have used Visual Studio for searching through files. However, I think I found an area in Zend Studio Neon that might do this, but I forget where I found it and I don’t have a need for it that often.

  2. Subversion

    Not as much as a pain to set up, so I love it.

  3. PHPDoc

    Well, it has an older version of phpDocumentor, but oh well, I think pressing a button and having an application build the pages for you is golden. I would be happier if it supported the latest version, since I use @uses and other tags that Zend Studio Neon doesn’t recognize nor give me the choice in the dropdown menu.

  4. PHPUnit

    Has the full list of PHPUnit methods and parameter list. I usually have the PHPUnit manual open in my browser, “Dude! I didn’t know that method existed, it does exactly what I need!” I don’t like how it doesn’t allow you to choose multiple functions to include in a single test case, but that is okay. I do like how it will take a class and create all of the test methods for each of the methods that exist in the class. I also like how you can add Test cases to a test suite.

    I did have problems with the PHP environment (PDO class is unavailable, WTF? It runs in the browser, therefore no, PDO class does exist), but it is beta, so hopefully that gets fixed.

  5. Just about everything else

    The only thing I didn’t love about Zend Studio, was that I had to pay for it. Other than that, it has everything I wish Visual Studio and Dreamweaver would implement for PHP.

What I hate about Zend Studio Neon

  1. Is final going to stay free?

    The answer to my inquiry is “No.” The beta is free, but the final is not.

    Going to have to decide whether to pay for Zend Studio for Eclipse or switch to PDT and see if I can learn it instead. I do have the money to buy Zend Studio for Eclipse, but I’ll probably switch over to PDT at work.

    Can’t find a clear answer anywhere. I can make the assumption that it will cost money, since Zend is saying that if you pay for Zend Studio, you can get Zend Studio for Eclipse for free. Which leads me to think that if I just wanted Zend Studio for Eclipse, I’ll have to pay as much as for Zend Studio. Not that I would mind, since I’m not “smart” enough to work with Eclipse and need some hand holding to work with PHP in Eclipse.

    Until they come out and say, “It is going to be free!” or “It is going to cost your soul” then I’ll be willing to download or sell my soul to obtain it. Either way, I just can’t find anything that states whether or not it is going to be free.

  2. FTP Support

    It exists, yes. It is just in such an obscure place that if you don’t use it often enough, you’ll forget. Where is that Remote Systems again? Also, it doesn’t seem (beta software) to correctly connect to a few FTP servers. Not sure if that is a bug, since I haven’t used Eclipse for that purpose.

    Dreamweaver makes FTP extremely easy, but is crap when it comes to Subversion and Zend Studio does Subversion very well. I’ll take Subversion any day, since I’ll be migrating to that systems for all of my uploading and downloading needs.

    FTP? Who needs you?

  3. Don’t do what I think

    Have this same problem with Dreamweaver. It appears that both Dreamweaver and Zend Studio Neon thinks I’m an idiot who needs a list of available objects and variables. Even after I wrote the variable or object in the parameter list (Of course, you can just as easily press ‘Esc’ and solve this, but I’m not quite a power user yet). So it is annoying, but I’ll get over it eventually.

Possibly Related Posts:


Tags: , ,
Posted in General | 16 Comments »

If I was on PHP Internals this past month

Saturday, December 8th, 2007

I was about to break my silence from PHP Internals over the discussion about namespaces. Not that I could have done anything sexy, like make a patch and an implementation that fixes problems pointed out by another. It is difficult sometimes, to not put your head up your ass.

I agree with Sean Coates. I think Derick put some good points out there, but the rebuttal was awesome! Nothing against Derick of course. This is why you leave the big discussions to the adults.

In this humble child’s opinion, I would have rather see an imperfect implementation of namespaces. While it might create some backwards compatibility issues later, I always had faith that a better implementation would be made sooner or later. However, it appears that the implementation might be better, sooner.

Thanks to intelligent people that actually put stuff out there. You’re awesome. A lot of love also to the author of HTTP extension (beautiful, just beautiful).

Possibly Related Posts:


Tags: , ,
Posted in General | 3 Comments »

« Older Entries
Newer Entries »