Posted by
Stéphane Ducasse on
Jul 14, 2010; 1:58pm
URL: https://forum.world.st/Evaluation-of-Pharo-for-Commercial-Project-tp2288574p2288802.html
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
_______________________________________________
Pharo-users mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users