Java API as base for PHP library?

[cyngon]

I agree that PHP needs a library of small, reusable objects. What I am wondering is if the other people advocating such a library (Harry, lastcraft, and many others) think about using the Java class library as a starting point for the API.

I think the Java class library API is well designed and would serve as a great starting point for development of a PHP implementation. Whenever I am writing library-type classes for PHP applications, I almost always end up creating classes that are a method to method copy of the corresponding Java library object's API.

I'd like to hear any arguments for or against using the Java class library API as a base for a library of small, resuable PHP classes.

[Chuckie]

I am not much of a PHP developer but it would be a logical starting point since a lot of people are familiar with java, and it would create a easy transition between both lanuages.

Chuck

[Sork]

I've voted the second option, there some java designs that don't have meaning in php because of overhead.

For my work when i need some task to be acomplished i first look in java api so i can have the work done quickly. And by now i have several classes ported from java.

There is JPHP an php library ported form java, but i don't like it at all because of some reasons, one of them is this

function method($arg)
{
      $arg = StringBuffer::toStringBuffer($arg);
      if ($arg->equals('some_value'))
      {
      }
} 

You know what i mean, for me this doens't make sense.

[lastcraft]

Hi...

I think a better approach is to cherry pick, but I see the higher level designs for things like HTTP, XML, Persistence (e.g. JDO) coming from there. Java is just so far ahead of the game in the resources available; JUnit has been cloned for lots of languages for instance.

That said, some of the smaller interfaces can be stolen from Python as they will be cleaner. Although PHP is about to get type hinting a straight Java copy would overuse this perhaps.

I guess we are all waiting for PHP5.

yours, Marcus.

[cyngon]

Marcus, I agree that the high level designs should come from Java. I think the low level designs are where the most thought needs to be directed, at least initially. This raises a number of questions:

1. Should the theoretical library have objects for primitive types such as String, Integer, etc. that can be used like their Java equivalents? It would be nice to be able to do $myString->startsWith('Foo') and other operations currently encapsulated in the PHP string functions with objects.

2. Related to #1, should the library contain classes for Arrays, HashMaps, etc.? PHP's array support is top notch and I'd be interested to hear what people think about wrapping it in collection-type classes.

3. Should all classes in the library extend one base "Object" class like they do in Java?

Does anyone have any questions/answers/comments/insights on those questions? I think how a PHP class library answers those three questions will have a huge impact on who uses it and how widespread it is accepted. I also think there isn't a way to answer those questions that is going to please almost everyone.

By the way, does Python have anything like Javadoc where I could browse its APIs online?

I think this project should be written from the start in PHP5. It just has too many new OOP goodies to pass up. Besides, by the time a library could be finished, PHP5 will be stable.

[firepages]

could you not add an extra option to the poll ..

5) Just use JAVA

?

[cyngon]

firepages,

You've now got me considering my choice of PHP over Java. I don't want this to turn into a programming language flame war, but here are some thoughts I had:

PHP is very good for quickly building web-based applications. I found it very easy to jump in to the language and build some simple sites. But now as I've become what I would consider an "advanced" PHP user (I code PHP every day at work) I find myself searching for PHP solutions to problems already solved in Java.

Some examples:

1. I'm still looking for a "perfect" Javadoc solution for PHP. It seems PHPDoc (http://www.callowayprints.com/phpdoc/) is just what I want but I am having a lot of problems getting it to work. I may end up having to write something like this myself.

2. I haven't found a solidly-designed library of small, reusable classes for PHP like the libraries included with Java. Currently I think a new development project needs to be started to fill this gap. And yes, I've looked at Eclipse.

3. The selection of frameworks for PHP application development is not to my liking. I've examind Eocene, Phrame, Fusebox, and many others and none fit my exact needs. I discovered WebWork (for... yes, Java) (http://opensymphony.com/webwork/) is just what I wanted and I ended up implementing it in PHP myself.

4. Although numerous, not many of the templating solutions for PHP match the flexibility of Java tag libraries. The best templating solution I've found for PHP, PHPTAL (http://phptal.sourceforge.net/) works just like a Java taglib but is not yet entirely stable.

Quick! Someone bonk me over the head and remind me why I use PHP!

[firepages]

Hi Cyngon , well I would hate to push anyone to the dark side [img]images/smilies/wink.gif[/img]

BUT , PHP is not JAVA , nor IMO should it be , all languages have pros and cons , the existing codebase for JAVA is obviously one of its pros.

Is it a con therfore for PHP ? , I personally don't think so , porting of JAVA solutions to PHP will also port over its problems, the 'cons' of JAVA do not all revolve around a JVM and hardware.

Though I think it often boils down to philosophy.. example , & I had this argument recently with an applications original designer where I was reworking existing PHP code ... I mostly ignored the file manipulation classes that were available as I saw no point in loading ,instansiating and manipulating an object when include, readfile , implode($filename) etc did the job for me, even saving the file seemed pointless via the available classes, we wont even go into iterating over a returned array from a file [img]images/smilies/wink.gif[/img]

...a simple and daft example I know but there are a lot more lurking away which itself leads to templating, which has been discussed a thousand times , and I fall on the side of the fence that says that you dont need templating solutions if you are using PHP it defeats part of the purpose of PHP.

I am not suggesting that I do not appreciate the merit of and the logic of java-like solutions , I just do not think that a direct port of such logic to PHP is always in itself logical.

There are surely ways to implement in PHP the design patterns & advanced OOP techniques that HarryF & friends here are showing and discussing here that do not revolve around __clone(JAVA) ?

If not then JAVA must surely be the alternative.

[Taoism]

firepages,
1. I'm still looking for a "perfect" Javadoc solution for PHP. It seems PHPDoc (http://www.callowayprints.com/phpdoc/) is just what I want but I am having a lot of problems getting it to work. I may end up having to write something like this myself.

I thought the phpDoc project was dead? We use phpDocumentor for our documentation and it is great for us. It is easy to use "out of the box". However, if you want to take advantage of some of the nicer aspects of its abilities (like the creation of tutorial pages), there is a bit more work involved.

Cheers,
Keith.

[cyngon]

BUT , PHP is not JAVA , nor IMO should it be , all languages have pros and cons , the existing codebase for JAVA is obviously one of its pros.

Is it a con therfore for PHP ? , I personally don't think so , porting of JAVA solutions to PHP will also port over its problems, the 'cons' of JAVA do not all revolve around a JVM and hardware.

I would be interested to hear some elaboration on this point. What other cons are you referring to?

Though I think it often boils down to philosophy.. example , & I had this argument recently with an applications original designer where I was reworking existing PHP code ... I mostly ignored the file manipulation classes that were available as I saw no point in loading ,instansiating and manipulating an object when include, readfile , implode($filename) etc did the job for me, even saving the file seemed pointless via the available classes, we wont even go into iterating over a returned array from a file [img]images/smilies/wink.gif[/img]

I can see many cases where it would not be wise to make use of such classes. When trying to write the best code possible, however, I think using classes to encapsulate file handling functionality makes the code easier to understand.

...a simple and daft example I know but there are a lot more lurking away which itself leads to templating, which has been discussed a thousand times , and I fall on the side of the fence that says that you dont need templating solutions if you are using PHP it defeats part of the purpose of PHP.

I fell on the same side of the fence that you did until very recently. That is, until I took a closer look at XML-style tag libraries. I would highly recommend all PHP coders examining the templating issue read up on Zope Page Templates (ZPT) which is the basis for the PHPTAL project I mentioned earlier. Start here:

http://www.faqs.org/docs/ZopeBook/ZPT.html

There are surely ways to implement in PHP the design patterns & advanced OOP techniques that HarryF & friends here are showing and discussing here that do not revolve around __clone(JAVA) ?

If not then JAVA must surely be the alternative.

I think you're on the right track here. I've noticed most good Java code I've looked at or experimented with had a certain "feel" to its design. It's hard to describe, really, but I think most people who have some experience working with Java code know what I mean. I think PHP needs to find its own "feel" for its well designed OOP code that allows us to build on the unique strengths of the language.

I thought the phpDoc project was dead? We use phpDocumentor for our documentation and it is great for us.

It does seem like the PHPDoc project I referenced is dead. I'd really like to find a PHP documentation solution that acts as a preprocessor before running the code through Javadoc itself. There are a lot of advantages in that approach, the biggest being the reuse of existing Doclets.

[Selkirk]

I would be interested to hear some elaboration on this point. What other cons are you referring to?

Java Design Flaws
Java Problems
A Java Critique
Java Good and Bad

Java is statically typed where as PHP is dynamically typed. This makes a difference in how one might organize a class library, as well as in how one might implement classical GoF design patterns:

Are Dynamic Languages Going to Replace Static Languages?
Strong Typing vs. Strong Testing
Benefits of Dynamic Typing

Smalltalk is dynamically typed as is PHP:

Smalltalk vs. Java

From Why does Dynamic Typing really matter?!?:

Get a copy of "Design Patterns" and then a copy of "Design Patterns Smalltalk Companion". Walk through the patterns one by one. Many (I think more than half) of the Smalltalk ones discuss why theirs is simpler than the C++ one due to the fact that Smalltalk is dynamially typed. For a final cut, get Pattern Hatching, where you can watch John Vlissides finally decide that something was 'not a pattern' because it was too easy to do in Smalltalk :-)

[cyngon]

Great links, Selkirk! That's exactly the kind of information I was looking for.

I'm already an owner of Design Patterns and I'm going to pick up a copy of Design Patterns Smalltalk Companion ASAP.

I'll post my thoughts after I finish reading and digesting all that information.

[lastcraft]

Hi...

There is a lot of stuff to digest in this thread so I'll have to work through one post at a time.

Should the theoretical library have objects for primitive types such as String, Integer, etc. that can be used like their Java equivalents? It would be nice to be able to do $myString->startsWith('Foo') and other operations currently encapsulated in the PHP string functions with objects.

Only if it is needed, it is too easy to "plan" a class library and end up with bloat. Unless there is a pressing need don't do it. The situations where it might be needed (e.g. an array iterator) are easily coped with by adding a specific adapter at that point. Over the lifetime of a library that is a lot of adapters, but for a specific application using only one or two, the app wins by having one or two extra classes rather than a whole load of string packing and unpacking.

Related to #1, should the library contain classes for Arrays, HashMaps, etc.? PHP's array support is top notch and I'd be interested to hear what people think about wrapping it in collection-type classes.

By the same reasoning no. Keep it minimal. Someone once said (cannot remember the quote, sorry) that the perfect design was not one where nothing could be added, but where nothing could be taken away.

Should all classes in the library extend one base "Object" class like they do in Java?

Only if needed. What would such a class do? We don't need hash maps after all.

By the way, does Python have anything like Javadoc where I could browse its APIs online?

I believe it does (Harry will know). You use something like triple quotes to delimit the comment blocks and there is a browser available in the Python distribution I think.

I think this project should be written from the start in PHP5. It just has too many new OOP goodies to pass up. Besides, by the time a library could be finished, PHP5 will be stable.

I don't have a PHP5 set-up, but I agree, or at least plan to port it immediately it comes out. Exceptions will have a big impact for example.

So are you planning to start such a project?

yours, Marcus.

[lastcraft]

Hi...

... I mostly ignored the file manipulation classes that were available as I saw no point in loading ,instansiating and manipulating an object when include, readfile , implode($filename) etc did the job for me,

I can think of situations where having a file object makes sense. For example making a raw file look the same as output from another object (say a parsed file). I would expect Readers and Writers and FileIterators to be in a class library, although I would not expect a developer to use them unless the polymorphism is needed. And then there is stubbing/mocking of course.

...a simple and daft example I know but there are a lot more lurking away which itself leads to templating, which has been discussed a thousand times , and I fall on the side of the fence that says that you dont need templating solutions if you are using PHP it defeats part of the purpose of PHP.

I would not make templating part of a class library project. Templating is a framework component and affects the design of an application. A class library is a pile of bricks. I would avoid persistence initially for the same reasons. There are libraries out there already to do that and it is a contentious issue. In Java templating is separate (JSP, Velocity, Struts) and so is the DB stuff (JDBC, JDO). Because of the influence on app.design I would say they should be separate libraries.

There are surely ways to implement in PHP the design patterns & advanced OOP techniques that HarryF & friends here are showing and discussing here that do not revolve around __clone(JAVA) ?

Some of the patterns (Double dispatching, say) don't make any sense in PHP. There also a lot more options which are easier with a dynamic language (Dynamic proxies, Autoloaded classes).

yours, Marcus.

[lastcraft]

Me again!

On a more general note, the organising of the authors would have more of an impact on a library than any early design decisions. Here are my current (rather random) ideas...

1) Shared code ownership. It forces code review and cooperation, rather than a single person owning a package and effectively freezing it. Anybody is allowed to edit your code. If that frightens someone then an examination must be made of their motives.
2) No attribution of authors. If there is less vested interest in the codebase the goal becomes the utility of the library and nothing more.
3) Completely archived discussion during construction. People are more willing to allow people the free editing of their code if they talk to them often. No rudeness and no private e-mails.
4) If nobody understands something out it goes. Code has no reuse if nobody ever reuses it. That means examples or docs or the writing of stuff thats intuitively obvious.
5) Refactoring by someone other than the person that wrote the first draught. It forces two people to have written everything and means that there is some redundancy if someone drops out for a bit. Libraries written by a single person tend to be quirky.
6) Fine grained unit tests shipped with the code. You cannot refactor without them and they reduce necessary documentation by effectively providing interface examples.
7) Always responding to users comments. Usability is important and you only get this from the users. The customer doesn't always know best, but being forced to justify a position also forces a constant reevaluation of it.
8) A clear tiering of code from stable down to experimental.
9) Refactoring to reuse other library objects. There is a limit to this because you don't want to force people to use the whole library for just a few classes. If the library were decomposed properly the issues should not be major.
10) No framework stuff.

As I said, pretty much random ideas.

yours, Marcus

[anode]

You must spread some Reputation around before giving it to lastcraft again.

Agreed on all counts.
*
Re:the Java library idea - I think Python would be a better start. Like PHP, it's dynamically typed, so that issue wouldn't be a stumbling block. The library has decent scope - not too narrow, not too wide, and is very easy to use.

Python Module Index

[cyngon]

I'm still digesting the information presented by Selkirk but I thought I'd comment on the ideas Marcus presented now.

Only if it is needed, it is too easy to "plan" a class library and end up with bloat. Unless there is a pressing need don't do it. The situations where it might be needed (e.g. an array iterator) are easily coped with by adding a specific adapter at that point. Over the lifetime of a library that is a lot of adapters, but for a specific application using only one or two, the app wins by having one or two extra classes rather than a whole load of string packing and unpacking.

Can you clarify on what you mean by "adapters"? Initially I assumed you were using it to refer to classes in the library (as basically they would all be acting as adapters or wrappers around native PHP functions) but I now am unsure. I'd like to comment more on this point but I will do so after I am completely clear what you meant in your post.

By the same reasoning no. Keep it minimal. Someone once said (cannot remember the quote, sorry) that the perfect design was not one where nothing could be added, but where nothing could be taken away.

So, therefore, the perfect design for a class library is not to have a class library at all. j/k

So are you planning to start such a project?

No. I feel I would be able to help a great deal in the implementation but I do not think I am a qualified enough programmer to design such a library in the best way possible.

I can think of situations where having a file object makes sense. For example making a raw file look the same as output from another object (say a parsed file). I would expect Readers and Writers and FileIterators to be in a class library, although I would not expect a developer to use them unless the polymorphism is needed.

Say a developer is building a large project where the polymorphism of the file objects would be absolutely required in a few cases. The same project also must do more simple file access in a few other places in the source code. In the later cases the polymorphism is probably not needed. I think, however, the developer should use the same file access classes in all cases in order to make the code more clear and uniform.

And then there is stubbing/mocking of course.

Can you please expand upon this statement? What is stubbing/mocking? I thought stubbing just meant writing out prototypes for methods before implementing them but I don't understand what you meant by mentioning it in that context.

I would not make templating part of a class library project.

Agreed. Any number of templating solutions could be built on top of the class library though.

In Java templating is separate (JSP, Velocity, Struts) and so is the DB stuff (JDBC, JDO). Because of the influence on app.design I would say they should be separate libraries.

I thought the database functionality in Java class library. I was under the impression that the classes in java.sql are what is commonly called JDBC.

Some of the patterns (Double dispatching, say) don't make any sense in PHP. There also a lot more options which are easier with a dynamic language (Dynamic proxies, Autoloaded classes).

/me scrambles to look up double dispatchingand dynamic proxies (Is it a variation of the GoF Proxy pattern?)

How does the dynamic versus static typed issue play in to class autoloading? By class autoloading are you talking about what PHP5 will have with it's __autoload() callback?

On a more general note, the organising of the authors would have more of an impact on a library than any early design decisions. Here are my current (rather random) ideas...

A lot of what you described are parts of XP. Sounds good to me.

2) No attribution of authors. If there is less vested interest in the codebase the goal becomes the utility of the library and nothing more.

I'm not sure what your proposing, exactly. It makes sense with collective code ownership not to attribute authors in the source code, but somewhere there needs to be a list of who contributed to the class library.

3) Completely archived discussion during construction. People are more willing to allow people the free editing of their code if they talk to them often. No rudeness and no private e-mails.

Good idea, but I think it needs to be refined. Should all messages relating to the project be in one bulletin board or mailing list? Or should only actual development/design messages be required to be on the list? Or should there be more than one list, one just for development/design related messages and one or more lists for other messages relating to the project but not actually design or development related?

5) Refactoring by someone other than the person that wrote the first draught. It forces two people to have written everything and means that there is some redundancy if someone drops out for a bit. Libraries written by a single person tend to be quirky.

Sounds like this might be a good substitute for pair programming. I want to do some research into how other people were able to do pair programming without actually sitting next to each other, as I am sure it is an issue others have encountered and attempted to solve before. Of particular interest to me is a programmer's text editor for Mac OS I read about that allows for two or more developers to collaborate on one working copy of source code in real time over the internet. I know it was posted on Slashdot but I'll have to search for it.

6) Fine grained unit tests shipped with the code. You cannot refactor without them and they reduce necessary documentation by effectively providing interface examples.

I want to do some more research on unit testing. I'd like to see some examples of how it is best used in large projects. I haven't actually used unit testing before, but from my limited understanding of it I don't understand how refactoring can be done without having to modify the unit tests themselves. For example, if you move a method from class Foo to class Bar it seems to me you'd have to modify the unit tests for classes Foo and Bar. Or, more likely, I think I am not understanding something fundamental about unit testing.

9) Refactoring to reuse other library objects. There is a limit to this because you don't want to force people to use the whole library for just a few classes. If the library were decomposed properly the issues should not be major.

Agreed. I think this is a big difference between collections of modules like PEAR and CPAN and an actual unified class library like Java's.

[cyngon]

Also, is there online documentation for the Smalltalk class library like there is for Python and Java?

[anode]

Of particular interest to me is a programmer's text editor for Mac OS I read about that allows for two or more developers to collaborate on one working copy of source code in real time over the internet. I know it was posted on Slashdot but I'll have to search for it.

You're referring to Hydra.

[anode]

I haven't actually used unit testing before, but from my limited understanding of it I don't understand how refactoring can be done without having to modify the unit tests themselves. For example, if you move a method from class Foo to class Bar it seems to me you'd have to modify the unit tests for classes Foo and Bar. Or, more likely, I think I am not understanding something fundamental about unit testing.

From what I understand, unit tests should test only the API, not the internals(as refactoring shouldn't break API's.)

[cyngon]

You're referring to Hydra.

Yes, that's it. Thanks. I'd love to see something similar that works with Windows or Linux.

From what I understand, unit tests should test only the API, not the internals(as refactoring shouldn't break API's.)

It seems to me this is entirely dependent on what you are refactoring. If you move a public method from one class to another than you are making a change in the API and thus need to change your unit tests. Changes to APIs of a class library are likely to be frequent up until the first stable release.

[firepages]

I think PHP needs to find its own "feel" for its well designed OOP code that allows us to build on the unique strengths of the language.

thats kind of what my reply should have been , just that

note I do not dismiss file manipulation classes as pointless , I would use them for more involved operations , but abstracting away file() etc seems still to defeat the point (of PHP) for me in many circumstances and for me harder to read .

I wont try and get into the other stuff as it whooshes gently over my head

[lastcraft]

Hi...

Well, thanks for reading through this stuff in such detail. You have already put more thought into it than I did writing it .

Can you clarify on what you mean by "adapters"? Initially I assumed you were using it to refer to classes in the library (as basically they would all be acting as adapters or wrappers around native PHP functions) but I now am unsure. I'd like to comment more on this point but I will do so after I am completely clear what you meant in your post.

No I do mean that, but was probably a little loose with the term adapter. For the string class to be used consistently internally, each version of a thingy class in the library that takes in a string would have to convert it to a string class and pass it to the "true" thingy library class. That is a lot of decorator code spread through the library. If the situations where a string class were actually useful were small (I suspect they are) then the change over should be done in the client code rather than the library. It's a judgement call of course.

So, therefore, the perfect design for a class library is not to have a class library at all. j/k

For a perfect do nothing library yes! Actually I just liked the quote.

No. I feel I would be able to help a great deal in the implementation but I do not think I am a qualified enough programmer to design such a library in the best way possible.

Rats, me neither.

Say a developer is building a large project where the polymorphism of the file objects would be absolutely required in a few cases. The same project also must do more simple file access in a few other places in the source code. In the later cases the polymorphism is probably not needed. I think, however, the developer should use the same file access classes in all cases in order to make the code more clear and uniform.

Absolutely. I think the Writer class is a clear case where OO is going to nearly always win, because of the need to write to files, templates, sockets, XML formatters, etc, etc. You could also have a StringWriter for writing straight to a string (I'm serious). You would not pass the StringWriter around internally for the sake of it outside this context though.

Can you please expand upon this statement? What is stubbing/mocking? I thought stubbing just meant writing out prototypes for methods before implementing them but I don't understand what you meant by mentioning it in that context.

Sorry, just saying what was on my brain at that second. Server stubs are a prototyping and test tool. It is possible to generate generic stubs from class interfaces that have a bunch of setters on them to preprogram a convincing simulation. Mock objects take this a step further by setting expectations of the calls made upon them. The point here is that you can generate mock classes, but not usually of PHP primitives such as file handles/streams. That said the author of the Ismo library has had a pretty good go.

Agreed. Any number of templating solutions could be built on top of the class library though.

And things like SAX filters, lexers and things would be part of a class library.

I thought the database functionality in Java class library. I was under the impression that the classes in java.sql are what is commonly called JDBC.

I would be the last person to say that nothing I ever write is complete rubbish and you have just nailed a prime example.

JDBC is of course part of Java from day one, I am really thinking of JDO. That said I would be nervous about building this because if you go platform independent here you will start to make compromises on the database, which could be too far reaching for a base library. Better I think to pull in MetaBase, PEAR, ADO or whatever your taste is.

/me scrambles to look up double dispatchingand dynamic proxies (Is it a variation of the GoF Proxy pattern?)

Double dispatch is part of Visitor. Dynamic Proxy is part of the Java reflection API. Nanning uses it to implement Aspects in Java. Think of it as a run time decorator I guess.

How does the dynamic versus static typed issue play in to class autoloading? By class autoloading are you talking about what PHP5 will have with it's __autoload() callback?

Yes, but as scripters we can always resort to the brute force that is eval().

, but somewhere there needs to be a list of who contributed to the class library.

That is probably the most that should be done though IMHO.

Sounds like this might be a good substitute for pair programming. I want to do some research into how other people were able to do pair programming without actually sitting next to each other, as I am sure it is an issue others have encountered and attempted to solve before.

I haven't had happy experiences with XP over the web, although I have heard rumours that it is possible.

... I don't understand how refactoring can be done without having to modify the unit tests themselves. For example, if you move a method from class Foo to class Bar it seems to me you'd have to modify the unit tests for classes Foo and Bar. Or, more likely, I think I am not understanding something fundamental about unit testing.

No you have got it exactly right. There are two options here. Firstly do the refactoring, watch a bunch of tests go red and then work through the broken tests. This is fast if not too much gets damaged, but generally you don't want to be writing anything significant whilst red. Extra carnage could grow out of control as you fix the tests forcing an embarrasing rollback. The other approach is to change the tests first (sending them red) and then refactor. What is left should be the dependencies you didn't know about.

Either way you are a lot safer with the test suite.

Another factor in favour is the speculative refactoring. You do a big change and see how much goes red. This gives you a handle on how hard this refactoring is going to be. You can then break it into smaller steps if it is a goer. Unit tests take away the fear of change.

yours, Marcus.

[cyngon]

Ok, based on this thread here are some proposed design guidelines for the PHP class library:

Note: I'm writing this using absolute language ("will" instead of "should"), please do not let this deter you from disagreeing with and commenting on these points. That is just the easiest way to phrase my ideas.

1. There will be a String class. The String class will be the only place in the class library's code where the PHP string manipulation functions appear. However, all public methods in the class library that are passed strings will accept primitive strings and convert them to String objects internally if needed. Code using the class library will never have to convert a string primitive into a String object just to gain the ability to call a method in the class library.

2. Other classes in the class library will convert strings to String objects if they need to manipulate strings in ways beyond what is available with just operators. For example, if a function only has to append to a string it must use a string primitive and the .= operator. If a function must get the substring of a passed string is must convert the primitive string to a String object and then call the appropriet method of the object. Basically String objects will be instanciated by other classes in the library if and only if they are needed.

3. The same rules expressed above for Strings apply to Arrays. The Array class is the only place in the class library's code where the PHP array functions can appear. Again, other classes in the library should convert native arrays to Array objects if and only if they need to manipulate them in ways beyond what they can do with the native operators.

4. There will not be an Object class that all classes in the library inherit from. Based on my understanding of the differences between strongly typed and dynamically typed languages this is unnessecary in a dynamically typed language like PHP.

Please critique and post comments.

Also, writing this provoced some questions:

Should there be classes for Integers and Floats? At first glance I thought no but then I am wondering how mathematical functionality should be built in. Should there be an Integer class with an getAbsoluteValue() method? If not, where will that functionality go? Does it need to be included in the class library at all?

Any ideas/suggestions?

[anode]

It seems to me this is entirely dependent on what you are refactoring. If you move a public method from one class to another than you are making a change in the API and thus need to change your unit tests. Changes to APIs of a class library are likely to be frequent up until the first stable release.

At this point you're less refactoring, and more re-writing IMHO. From Ward Cunningham's Wiki

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.

Or to put it another way, putting a public method in another class (without at least leaving the old method to delegate to the new one, which wouldn't break tests) is something that should be avoided in the first place, IMHO(I'm no expert of course.) This is of course why you need well-designed APIs and why PHP doesn't have a class library.