Hi runar
I am looking at Pharo to evaluate whether it can be used for a mid-size commercial project. The system will use Seaside. I have looked at Pharo 1.0, 1.1 and 1.2.
Do not use 1.2 :) This is written Unstable on the box :)
I am impressed by the work done so far. Pharo looks and feels a lot better than Squeak, and a lot of enhancements have been done since the project started.
We will start cleaning even more under the surface. See my mail about 1.2 vision.
There are however a few issues which hold us back from using Pharo, listed (in decreasing importance) below:
1 - Package Management
From what I have seen so far, the concept of âpackages and categoriesâ is confusing. We are used to VisualAge and VisualWorks, which clearly shows the structure of packages in the browsers. In Pharo we cannot find browsers which give us the same overview. We are uncertain how packages are made and how they show up in Monticello. At one point we thought category == package, but that seems not to be correct. We note that method extensions are possible, but we also struggle to understand all aspects of them.
really simple if you declare a package then you get: PackageA = CategoryA + protocol *CategoryA After if you have PackageA PackageAB Then AB is included in A (bad) So you should do PackageA-Core PackageA-B Do you use *overrides-categoryA simple this is bogus
I notice that a âPackage management systemâ is in work, so hopefully this area will improve.
Removing completely categories would be good but we would end up with a lot of packages. We have a really new and good implementation to have first class packages without relying on string matching but now we should integrate them into the system.
2 - Dependency Management between Packages Since we are unable to organize our code in packages, why?
controlling and verifying dependencies between them is hard.
but you will use package and still you point is valid.
But from what I understand, there are not many tools for controlling that packages do not break dependency rules.
You have dependencyBrowser developed by Hernan Morales eDSM to identify cycle in your program that is working on top of Moose Then also really important and much better than the envy solution you have metacello to describe the package dependency
3 - Name Space Support I understand name spaces will not be supported any soon. We have a project with thousands of classes, and name space support would be nice to have.
Not before we really understand how they interact with package. I do not like the solution of VW, Java.... So we should build and prototype something good.
4 - Break Point Support It would be better to have break points, than having to insert code like âself haltâ into the code.
If this is the only show stopper to use pharo this is easy. There are some support for break points. We should look around. Second you have haltIf: which is worth a lot more than halt haltIf: #foo stopped if the methods is eventually invoked by foo
Is there any reason to believe Pharo will improve to meet our requirements?
I think that the two requirements are solved, because we managed really complex software with Monticello and metacello. Namespace can be solved with simple Prefixing for now. Finally you can provide code for fixes and that you can really get an impact on the system.
Did I misunderstand some aspects of Pharo, or are there tools which can solve what we see as shortcomings?
Stef