Java API as base for PHP library?

[Cam]

Ahh, I got it

Well It works nicely except I get this warning.

Warning: Missing argument 3 for __call() in D:\www\root\TMP4hk66hs86i.php on line 7

Seems that PHP5 doesn't use the return parameter.

[lastcraft]

Hi...

There's a whole load of good stuff this could be used for, from very minimal "Decorator" classes to all sorts of stuff I haven't though of yet but looking at Python, there's plenty to get inspiration from.

I think it could be the stuff of nightmares!

I actually posted my reservations about this in the layering thread before but no one responded, so I'll cheekily quote myself here and double my money's worth...

Am I the only person disturbed by this development?

The intercepting is a very powerful device, but also very dangerous and it's invisible on casual inspection. Looks to me like it should be reserved for tool makers (e.g. profilers, coverage tools) or for idiomatic situations that developers know about (Aspects, Mock objects). Anywhere else I think is just "hacky".

Aspect Oriented Programming (AOP) is a related area of research at the moment. The Nanning, a Java tool, author came under heavy questioning recently at a talk in London. Questions along the lines of "Do you get spaghetti aspects?" and "Isn't this the GOTO problem revisited?" came up. He frankly admitted that they currently use a very small number of aspects in their code and they are tested extremely heavily, so the jury was out.

Now if the Nanning developers cannot decide, and these guys are extremely experienced developers using a well specified XML interface for their aspects, whether it will work long term I don't think your average library writer has a hope. Best avoided if possible.

...and...

The real power comes when you don't know a method name in advance, but you want to add some generic behaviour (e.g. Remoting) or when you do know the names, but you want to allow cross-cutting changes to the code without changing the class library (e.g. Permissions).

Even then you are creating code that will be difficult to profile, test, debug, etc. It raises the bar skill wise and should be weighed against other options. With SOAP the server could read the WSDL file (or be code generated from it) and then use a config file to map to your classes. With permissions, just have an Authority object passed around. The number (of fairly high level) classes affected by this will probably be pretty small.

I am not saying they are better or worse options, merely that they be weighed up against clashing with future tools or confusing the hell out of people.

I haven't changed my view, but went to another talk recently where Ivar Jacobson opined that aspects have a close fit with use cases. This is interesting, because it goes along with the idea of handling this with configuration of the top level application, not lot's of lower level hacks.

Also I have no idea how I am going to create mock objects from classes that use this trick . How does it work with inheritance?

yours, Marcus.

[HarryF]

Interesting point - hadn't considered that at all - just regarded __call() as a great way to cut corners. Haven't needed to use overloading in anger though.

One thing that had occurred to me, considering PEAR::SOAP right now, without the overload extension when it reads a WSDL document the proxy code it generates can be displayed [like Mock objects] (which makes a nice alternative to reading WSDL) while with overloading, you have no way to find out what they object does. That's just the tip of the iceberg but it's clearly a problem that when you ask an object "What do you do?" and it replies "Don't ask me. I just work here.".

Also I have no idea how I am going to create mock objects from classes that use this trick . How does it work with inheritance?

Apparently __call() is treated just like any other method when inherited - it can be overridden or inherited. Mock objects... hmmmm. One developer workaround might be to have call throw an exception describing it's signatures, when a special method is called but that's clearly not so good.

Makes me wonder if Pythons metaclasses might have been a better choice. Come to think of it (not that I've completely grasped metaclasses), __call() might be a means to simulate them with PHP. Again that means programmer discipline though - limit yourself to only using methods defined by a "Metaclass" within __call(). That would at least more traceable though.

Edit:


Seems that overloading and metaclasses may be a plan: interesting discussion

[lastcraft]

Hi...

Apparently __call() is treated just like any other method when inherited - it can be overridden or inherited.

But what if you are using it to simulate a method that doesn't really exist in the class. i.e as for a DynamicProxy in Java. You cannot inherit that method. With a code generation scheme, using say eval(), you can. Just generate a straight through do-nothing decorator and then inherit from that. If you want to save time writing decorators then that is a better way to go IMO, although even then this method will be defeated when decorated overloaded classes in the same way mocks are. It wrecks PHP's already rather shaky reflection API.

One developer workaround might be to have call throw an exception describing it's signatures, when a special method is called but that's clearly not so good.

I would need a special type of mock for overloaded classes. Because any method could be invoked at all this type of mock would have no method existance checks at all, simply being a general object simulator. That means any class you even suspect of having __call() in weakens the ties between the test code and the real classes. You could no longer get an error if you set an expectation on a non-existent method.

Makes me wonder if Pythons metaclasses might have been a better choice. Come to think of it (not that I've completely grasped metaclasses), __call() might be a means to simulate them with PHP. Again that means programmer discipline though - limit yourself to only using methods defined by a "Metaclass" within __call(). That would at least more traceable though.

The discipline point is exactly right. You could do aspects with __call() to some extent and this is intriguing. It would be a lot safer as I hear with aspects you tend to get the code right first, then you test the aspects separately, then finally the combination (which is hard to test). As the configuration file for the aspect integration (weaving) is in one place only and the code is expected to work without it, you have two powerful forces against complete chaos.

The fact that the PEAR libraries have embraced it sadly does not surprise me. The overload methods are just too easy to use and abuse. I feel the overload capabilities really should be treated like a loaded gun.

yours, Marcus.

[cyngon]

There are other areas though where I think PHP's native functions could be unified well with some well thought out classes, in particular where file related operations are concerned (and as has already been done many times with the DB related stuff) and perhaps the new XML stuff.

I agree such a library should have file handling, XML, and database functionality. What other areas do you guys think this library should encompase?

Likewise if there's a leader out there with time to spend on this, got ideas and code that I'd be will to throw in. Time is in short supply for me though...

I've seen this kind of statement a few times in this thread and in other discussions about a project like this. Maybe we should set up a simple code repository where anyone can upload code they feel may be useful to this project. A lot of this stuff is already written and I think just having code like this in a central repository could lead to some interesting new ideas.

Then we run right into the issue of licensing for this. GPL? LGPL? or good old public domain? I think contributers should have to agree to the chosen license before uploading any code.

[lastcraft]

Hi...

Time to think different - public domain definitely. I am not exactly handing over the crown jewels when I hand over a load of PHP classes. Sourceforge is the obvious repository, but the real challenge is getting a team together that can cooperate fully and have no code "ownership" to drag things down.

One thing though...get the smallest possible library up first. I/O is fiddly and should be done after some core interfaces and patterns get put down. Would there be any issues related to post 15?

yours, Marcus.

[Captain Proton]

Maybe we should set up a simple code repository where anyone can upload code they feel may be useful to this project

Do I hear 'PEAR' there?

[cyngon]

Do I hear 'PEAR' there? [img]images/smilies/wink.gif[/img]

::Shudder::

The code repository would serve as a place to get some code that could be used as the base for the project. The end result of the project will be one unified library composed of small reusable objects which is a far cry from PEAR.

[Cam]

I want namespaces

[Captain Proton]

I think the problem with what you're suggesting, like other people have pointed out, if everybody can contribute you may have a nice library with lots of functionality but the classes can not be used 'together' because their interfaces are different. To create a library like you're saying you really need to do some design work at first, especially if multiple people are working on it.

[Phil.Roberts]

Perhaps some kind of approval queue would be an idea, whereby everyone can submit code but it doesn't go public until it recieves majority approval.

[lastcraft]

Hi...

With Unit tests and zero ownership you can refactor contributed stuff into the final library. This means a grading system (like the one PEAR haven't got). Say Incoming contributions at the lowest level (must have tests, no need for docs), followed by Refactoring, followed by Beta, followed by Stable. Competing packages could be allowed below Beta and if a better one comes long, the lesser system can be deprecated back down the scale. This allows the churn that will be necessary for multiple people to evolve the classes.

The real trick, though is to start small with just one class. The iterator class should be contentious enough.

yours, Marcus.

[cyngon]

I think the problem with what you're suggesting, like other people have pointed out, if everybody can contribute you may have a nice library with lots of functionality but the classes can not be used 'together' because their interfaces are different. To create a library like you're saying you really need to do some design work at first, especially if multiple people are working on it.

I don't think I was clear enough in the wording of my earlier post. What I was suggesting is the creation of a place anyone (who agrees to a given license) can dump code that could possible serve as inspiration for the design work.

A lof of these classes have been designed many times, and if we can look at a bunch of different designs for the same class we can figure out which is best and why.

I don't know if I like the idea of "packages" making the library (a la PEAR). I think I'd rather see a more seemless library. Comments?

And it also would be useful to have a bulletin board where we can get that iterator flame war ... errr... discussion going without bogging down SitePoint's forums.

[HarryF]

Following on from what Markus is suggesting, some things I think would be required...

A mechanism for submitting releasing code to the site (what PEAR has done here is good from a usage point of view).

A mechanism for rendering API docs which takes advantage of a database (phpDocumentor could be a basis for this - it hasn't been done yet though) to allow...

A mechanism for people to submit comments / discuss class design - this will probably need to take into account the release version of the classes in question. It's a shame that basically none of the PHP forums out there (that I've looked at) approaches anything like Tiered / MVC design - this would probably need to be written from scratch.

A build mechanism for getting code from the project. Phing may be a good choice here.

The rest is about defining the right standards (something Markus has mentioned before) and clarifying some kind of "community process" for major decisions (e.g. [pseudo] namespace structure).

Nice to talk about work without offering to do it though

[lastcraft]

Hi.

Agree the bit about classes rather than packages. Used the wrong phrase there - sorry.

As for docs, I would get some classes up first. If you cannot read them without comments then they probably need work anyway. SimpleTest can read other unit tester's test cases now (plug ), so people can contribute tests in any format they want if people don't mind having the library wide group test in that format.

I haven't tried Phing yet (on my TODO list for some time), but I haven't seen the need for a build tool for a class library. Well not yet anyway. It sounds like a nice tool though.

As for packaging, again I think it's a case of "just get something out". A folder of classes would do fine. It won't really get going until a single class has done the process end to end.

I have Iterator, Observer, Registry, Singleton (test safe version), NullValue, Lexer and probably lot's of others ready to toss out of the door.

yours, Marcus.

[anode]

Vincent has gotten a lot of this low-level stuff(Iterators, for example) done already with Eclipse though. Perhaps we could lobby him to dual-license it as LGPL(as it is now) and something BSDish so we could use it?

[lastcraft]

Hi.

Vincent definitely started out in the right direction, but the library suffers a little from single writer syndrome. Now I don't want to get drawn into any criticism of Eclipse (I think the classes are great and did a lot to raise the bar), but there is a lot of stuff that would have gone if a second person had refactored it. The Iterator has four methods for example. To me an iterator has next() and that's it. Anything else is overhead.

Now Vincent is a little stuck here, because he has to support existing users and large scale interface changes are now impractical. It's a product in a sense.

To be different perhaps a small cohesive library should not be a library at all?

A constantly refactored non-library where classes were pulled in by need and then entered the user's application code base (hence no licence) and was instantly absorbed would not suffer from being frozen. People would use the classes and modify them themselves. If something new came out then it would be imported afresh into the app. as before. All it takes is for the library writers to say we do not guarantee that the library will stay the same. It would then just be source code (with tests and docs) rather than modules or packages. As a user you could take a current snapshot (to ensure everything that does couple interoperates where needed) and use it straight of course. If that's what was wanted. People could use parts as the basis for their own packaged libraries and win fame and fortune. Would I be angry? Not really, the PHP OO world would be benifitting from common interfaces at last.

Perhaps this idea is a bit radical . A small library probably wouldn't change much after a while. The thing is though, I think that if the coding effort is going to be made the result should not be "just another library".

As for other libraries though, anyone contributing code would have to be willing to let a load of people rip it to bits. If Vincent or anybody was happy for that to happen, then no problem. What would be left would not be Eclipse, but rather the refined combination of this and other material.

Now actually knocking up a twenty odd class library as a first draft is not very time consuming and is probably the easy part. It's the accumulated experimenting, testing, refactoring, recombining and experience with it that adds to the hours. In doing so gradually teasing out the stuff with real importance.

By way of example, the class library used by Wordtracker is about 200 classes. It hit a peak of 38000 lines of code about halfway through (9 months ago). A quick count now has it at 33404 lines and another couple of thousand are set to dissappear this week. Yet the library does more now than ever. Some reading I have done of Cockburns books suggests that this is typical OO behaviour.

yours, Marcus.

[firepages]

Can I make a suggestion ?

If you are going ahead with a JAVA-like api ... whilst it can not then be integrated as such with PEAR as PEAR follows a different ethos , perhaps it could still be part of PEAR allowing an alternative interface ? and allowing mainstream PEAR developers to also utilise your work ?

All it takes is a mail to the PEAR lists or a word in the right ear

Why ?

well with all respect to your collective knowledge , with PEAR now being an `official` part of PHP I suspect that a lot of your hard work will end up used by only a few , whislt if it were part of PEAR then it would be conveiniently planted on every PHP enabled server in da world (assuming they upgrade at some point.

if you base your code around PHP5 then you would have added leverage to get your code included.

for all the woes of PEAR , it IS going to be the standard class library , you could collectively make it a much more useful one ?

just a thought , there may be obvious reasons that this is not possible & I would love to hear them.

[lastcraft]

Hi...

All it takes is a mail to the PEAR lists or a word in the right ear

With respect it would never get it in. For a start, as you say, it's a completely different ethos. Also it would conflict with just about every package in the library and PEAR are pretty hostile to duplicate packages. It's the number one reason for rejection. You need five votes in favour over the negatives. I really don't see it getting even one positive. You are welcome to try, although I would build a version first or you will be told to contribute to PEAR instead.

Of course PEAR could be restrictive as well. If a project like this could work within PEAR confines then this discussion would never have started, we would be reusing small PEAR classes now. Reuse and refactoring are nearly non-existent in PEAR and there is no way of running a test suite for the whole library. Sadly the results show. There is plenty of good stuff and some good people contributing, but there is code in there that shouldn't have survived a student project, let alone gain "official status". This is not the fault of the developers, we all do good stuff and bad stuff, it's the fault of the organisation.Taking away package ownership would free up the "delete" key big time.

I think the official status shoud actually be revoked IMHO . I am starting to feel that PEAR is acting as a glass ceiling, stifling the development of tighter libraries.

yours, Marcus.

[Selkirk]

In "Fundamentals of object-oriented design in UML" (a highly recommended book) mpj groups all classes into one of four domains:

Foundation domain: "The classes in the foundation domain are usable in many applications from many different industries running on a broad range of computer architectures."

Architecture domain: "The classes in the architecture domain are usable in many applications from many different industries. However, the reusability of architectural classes is limited to a single computer architecture"

Business domain: "The classes in the business domain are useful in many applications, but only those within a single industry."

Application domain: "A class in the application domain is used only within a single application (or a small number of related applications)"

One problem with PHP from an OO perspective is that it does not provide any sort of Foundation domain classes. PHP provides its foundational capabilities (String manipulartion, Iteration, file access, etc.) using a functional interface.

PEAR targets the Architecture domain and is based on the standard PHP Foundation functions.

I believe that any effort to create foundational classes for PHP outside of the official PHP distribution is doomed. I also think that non-standard foundational classes would doom any architectural domain class library or framework that was based on them.

Some here are complaining about the lack of consistency in the PHP foundation domain functions and the lack of consistency in the PEAR application domain classes. I agree, but feel this is an inevitable result of the open source development process.

No political process or design committee is going to be able to overcome the splintered nature of open source development.


I have an architectural domain framework which I have been developing for several years. I am in the process of doing some major refactorings and additions to it and have decided to release it as an open source project. (Web application component toolkit)

I think it will deliver some of the things that people are looking for here. My goals are for it to provide a lightweight, modular, productive, high performance web application development environment.

I am interested in keeping it in "code normalized form" and in delivering a test suite with it. (probably using simpletest)

I am reluctant to bring it up in this thread, however.

I am not much interested in "classifying" the built in PHP functions. I am not much interested in a high ceremony committee process. I am also not much interested in creating textbook implementations of patterns devoid of context.

This thread started out with a poll. I voted "A PHP class library would be better off not basing itself off the Java class library API at all."

the reason that I voted this way is that I feel that porting is a poor driver for framework development.

My framework is the result of refactoring several web applications into a common framework. Everything in it had a basis and use in a real application. I've tried to continue with this by creating examples that demonstrate each feature in the context of a real web application.

I feel that driving the frameworks capability based on examples and real applications will result in a better framework.

I feel that driving the development of a framework based on porting another framework is going to result in porting paradigms that don't necessarily apply in the PHP environment. (PHP has dynamic, weak typing. Java has static, strong typing. PHP is interpreted. Java is compiled. PHP has a functional foundation domain. Java has a class based foundational domain, etc. Java is for Web or GUI apps. realisticly, PHP is just for web apps)

I feel that a porting effort would succumb to the desire to "round out" classes with capabilities that are not needed (or are rarely needed) in any kind of real web application. PEAR suffers from this everything AND the kitchen sink mentality.

I am also reluctant to even mention this because I am at such an early stage. I haven't even uploaded the code to the project page, nor do I have documentation of what I have done.

Anyway, if you are like minded philosophically (I am very much influenced by XP), I would welcome help.

[anode]

Some here are complaining about the lack of consistency in the PHP foundation domain functions and the lack of consistency in the PEAR application domain classes. I agree, but feel this is an inevitable result of the open source development process.

No political process or design committee is going to be able to overcome the splintered nature of open source development.

I agree with most of your post, but I think Python's library is an effective counter-argument to the quoted parts (so effective, that TCL is adopting the same process, IIRC.)

[lastcraft]

Hi...

Normally I agree with everything you say, so to save space I am just noting the disagreements. Just imagine murmurings of approval as you scroll down.

I believe that any effort to create foundational classes for PHP outside of the official PHP distribution is doomed. I also think that non-standard foundational classes would doom any architectural domain class library or framework that was based on them.

That's a lot of doom . The trouble is that the class library that is being talked about is one that has been built by lot's of people many times in PHP. It is already proven useful thus I don't agree with these sentiments. A small cohesive PHP library may not change the world, but then it doesn't have to. It only has to be useful.

I agree, but feel this is an inevitable result of the open source development process.

Hardly inevitable. Ruby and Python have turned out well, Perl hasn't. There are many ways to run an open source project, from Jakarta to PEAR. Like any factor in a project, you start with a chosen process and change it as needed to get to the desired result.

I am also not much interested in creating textbook implementations of patterns devoid of context.

With the exceptions of a few wanderings in this thread I don't think anyone is. I could be wrong about everyone else, but my own contributions would be stuff that is in use right now. That does include some textbook patterns, but then that's how the pattern textbooks got written anyway.

the reason that I voted this way is that I feel that porting is a poor driver for framework development.

I agree.

Doesn't rule Java out as a resource, though. Yes you want something pure PHP, but when you have a choice of method names or you want a fairly standard industry design (SAX filters say) a rough Java interfaces port to kick start the process doesn't do any harm.

I feel that driving the frameworks capability based on examples and real applications will result in a better framework.

We are talking library rather than framework here of course. Is it a framework you are planning? How would WACT differ in style from the Ismo library?

I feel that a porting effort would succumb to the desire to "round out" classes with capabilities that are not needed (or are rarely needed) in any kind of real web application.

Yes, but that is why you want people refactoring. The delete key is the most powerful refactoring tool available.

Anyway, if you are like minded philosophically (I am very much influenced by XP), I would welcome help.

Well, I am certainly in the XP camp.

I think the ideal number (this is a Jakarta rule) would be three as equal partners. Would you be willing to give up 66% of your control of the project? I'd certainly be happy to help as all the other things you have mentioned give me a green light.

yours, Marcus

[HarryF]

Just throwing in a link (while reading the most fascinating discussion) - the Eclipse library has a new face - http://www.phpcomplete.com/articles.php/387 - know there are disagreements on Eclipse's usefulness but just noting that there's work in progress to update it under a different lead.

One other thing regarding the relative success of Python's class library cf. PHP - Python is a "benevolent dictatorship" i.e. Guido gets the final say.

PHP is a commitee with a business face (Zend). Although this sometimes means design comprimises it does mean PHP has a much better chance of continued development plus, my guess, this was a factor (plus those 500k PHP developers) in PHP being chosen for the reference implementation for the Java Scripting JCP, as opposed to Python for example, which strikes me as a better match technology-wise.

Meanwhile both Larry Wall and Guido van Rossum are both talking about having to ease up on Perl / Python development due to personal financial issues.

Anyway - heading off topic

[Selkirk]

Doesn't rule Java out as a resource, though. Yes you want something pure PHP, but when you have a choice of method names or you want a fairly standard industry design (SAX filters say) a rough Java interfaces port to kick start the process doesn't do any harm.

Of course. Java is an excellent resource, as is .net, Web Objects, smalltalk, etc. Most of my previous post was just trying to unambiguously stake out a position as far away from porting String and Integer to PHP as possible.

We are talking library rather than framework here of course. Is it a framework you are planning?

I am talking framework. I am interested in providing the classes to help develop MVC based web applications. As I said before, I am targeting the architectural domain, not the foundational domain.

I think the ideal number (this is a Jakarta rule) would be three as equal partners. Would you be willing to give up 66% of your control of the project?

Immediately, no. In the future, yes. As long as the others shared the same overall vision (lightweight, modular, productive, high performance) and have proven their commitment to the project, I would have no problem accepting them as equal partners. (I hope to be so lucky.)

In the present, I am trying to convert a body of code that I already have into this framework. I am also trying to implement a few things that I've always wanted to do with previous versions of my libraries but haven't been able to. Once I have these things in the framework and have the framework to the point where I can use it in my production applications in place of the old one (call this version 0.5), then I will be more receptive to seeing where other people want to go with it.

I intend for quite a bit of time to pass in between when I start re-factoring all of my outstanding applications to use WACT, and when WACT might undergo an API freeze (or at least a chill). That version would be called 1.0. There are portions of the code which I will be uncofortable with until they have proven themselves by supporting a diverse base of code.

I'd certainly be happy to help as all the other things you have mentioned give me a green light.

I would very much like to have your help. I've been looking at simpletest and would like to adopt it to create a test suite for WACT.

One of my hopes for this framework is that it can support TDD in PHP.

I haven't released the code in to the wild yet. I am still scurrying around trying to Fix broken windows before uploading the initial version to the sourceforge project.

[lastcraft]

Hi...

I would very much like to have your help. I've been looking at simpletest and would like to adopt it to create a test suite for WACT.

Of course.

One of my hopes for this framework is that it can support TDD in PHP.

Beyond shipping the library with tests I am not sure what could be done.

Off the top of my head I guess shipping it with test suites that confirms the library works with do-nothing extensions. Say you have a class in the framework that is to be inherited by the application. Ship a test case that takes a class name as a prameter and that checks that the new class does all the things required by the framework. That way people get a head start on testing their extensions.

I went to a talk by Eric Gamma recently about Eclipse (the Java IDE, not the PHP library). One of it's design strengths was that it doesn't expose very much of itself to tool writers. It opens up just enough for people to write their extensions with clearly sign posted development sockets. I guess doing any framework is similar. It you just PHPDoc everything then people can extend what they want leading to breakages in their code everytime something in the library is refactored. If you have clearly designated extension points, a few methods in a few classes, you document them only.

Enabling TDD would mean also shipping test cases for these extension points.

I haven't released the code in to the wild yet. I am still scurrying around trying to Fix broken windows before uploading the initial version to the sourceforge project.

I have a few of those as well.

yours, Marcus.