SitePoint Sponsor |
|
User Tag List
View Poll Results: How well would Java's class library API serve as a base for a PHP implementation?
- Voters
- 58. You may not vote on this poll
-
It would work well with little modification.
16 27.59% -
It would work with significant modification.
19 32.76% -
A PHP class library would be better off not basing itself off the Java class library API at all.
14 24.14% -
Unsure or not familiar with Java's class library API.
9 15.52%
Results 51 to 75 of 82
-
Jul 9, 2003, 17:05 #51
- Join Date
- Aug 2002
- Location
- Burpengary, Australia
- Posts
- 4,495
- Mentioned
- 0 Post(s)
- Tagged
- 1 Thread(s)
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
-
Jul 10, 2003, 14:35 #52
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by HarryF
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.
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.
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.Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Jul 10, 2003, 16:25 #53
- Join Date
- Nov 2000
- Location
- Switzerland
- Posts
- 2,479
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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?
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.
Last edited by HarryF; Jul 10, 2003 at 16:41.
-
Jul 10, 2003, 18:08 #54
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by HarryF
Originally Posted by HarryF
Originally Posted by HarryF
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.Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Jul 13, 2003, 18:22 #55
- Join Date
- Aug 2001
- Location
- Livonia, MI, USA
- Posts
- 513
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by HarryF
Originally Posted by HarryF
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.
-
Jul 13, 2003, 18:58 #56
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
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.Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Jul 14, 2003, 01:52 #57
- Join Date
- Oct 2001
- Posts
- 656
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by cyngon
-
Jul 14, 2003, 18:18 #58
- Join Date
- Aug 2001
- Location
- Livonia, MI, USA
- Posts
- 513
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Captain Proton
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.
-
Jul 14, 2003, 23:26 #59
- Join Date
- Aug 2002
- Location
- Burpengary, Australia
- Posts
- 4,495
- Mentioned
- 0 Post(s)
- Tagged
- 1 Thread(s)
I want namespaces
-
Jul 15, 2003, 05:26 #60
- Join Date
- Oct 2001
- Posts
- 656
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Jul 15, 2003, 07:30 #61
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.
-
Jul 15, 2003, 07:55 #62
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
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.Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Jul 15, 2003, 14:09 #63
- Join Date
- Aug 2001
- Location
- Livonia, MI, USA
- Posts
- 513
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Captain Proton
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... discussiongoing without bogging down SitePoint's forums.
-
Jul 15, 2003, 14:56 #64
- Join Date
- Nov 2000
- Location
- Switzerland
- Posts
- 2,479
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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
-
Jul 15, 2003, 15:55 #65
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
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.Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Jul 15, 2003, 16:19 #66
- Join Date
- Mar 2001
- Location
- Philadelphia, US
- Posts
- 2,205
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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?
TuitionFree — a free library for the self-taught
Anode Says... — Blogging For Your Pleasure
-
Jul 15, 2003, 18:04 #67
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
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.Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Jul 15, 2003, 18:42 #68
- Join Date
- Jul 2000
- Location
- Perth Australia
- Posts
- 1,717
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Jul 16, 2003, 07:58 #69
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by firepages
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.Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Jul 16, 2003, 12:01 #70
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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)"
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.
-
Jul 16, 2003, 12:19 #71
- Join Date
- Mar 2001
- Location
- Philadelphia, US
- Posts
- 2,205
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Selkirk
TuitionFree — a free library for the self-taught
Anode Says... — Blogging For Your Pleasure
-
Jul 16, 2003, 17:48 #72
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
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.
Originally Posted by Selkirk
. 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.
Originally Posted by Selkirk
Originally Posted by Selkirk
Originally Posted by 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.
Originally Posted by Selkirk
Originally Posted by Selkirk
Originally Posted by Selkirk
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, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Jul 17, 2003, 05:01 #73
- Join Date
- Nov 2000
- Location
- Switzerland
- Posts
- 2,479
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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 topicLast edited by HarryF; Jul 17, 2003 at 05:14.
-
Jul 18, 2003, 10:19 #74
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
Originally Posted by lastcraft
Originally Posted by lastcraft
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.
Originally Posted by lastcraft
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.
-
Jul 20, 2003, 12:49 #75
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by Selkirk
Originally Posted by Selkirk
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.
Originally Posted by Selkirk
yours, Marcus.Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
Bookmarks