An important infrastructural question

HI guys

With simon we restarted to code on the new package to substitute  
packageInfo.
Now we have a nice package class which works well (one little bug to  
fix) and a lot of cool tests.
I believe that this was the easy part now we will have to think how to  
have
a migration path and about the possible options. We want your feedback  
on the following points.

        Currently PackageOrganizer is not really used or half way and the  
responsibility are split
        with packageinfo ending in the kind of mess. We suggest to either use  
it as a factory
        and package registry or to remove it.
        The package manager class (either packageOrganizer or Package class  
side) should
        really be responsible to create, query, manage package and emit event.
        Since packageOrganizer is not really used may be this is easier to  
move its behavior to
        PackageInfo (and later Package) class side.


        events? we think that PackageOrganizer/Package  should emit events so  
that other tools can
        register. Now the question is how this interact with systemNotification
       
        mutating from PackageInfo
        we could write a script that convert all package info (BTW full of  
crap) into our package:
        the question is then what to do with the code that we will load later  
and relied on *
       
                - idea: we keep the * notation but we hook into the tools to
                create real package. In particular the user could either explicitly  
add a method extension
                to a package or use the* notation. The end result should be the star  
notation in the cat
                and the use of a real package in the background.
               
        - fileout (MC). Similarly we could get rid of the convention at the  
cat level
  when fileouting a package. It would work at the package level but  
fileouting a class would
        break since the markers would be lost. Also porting code to Squeak or  
other MC based
        platform could be a problem. So lukas do you if VW uses the *  
convention, I imagine at least when
        saving code?

       
So let us know what you think.

Stef

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>                - idea: we keep the * notation but we hook into the tools to
>                create real package. In particular the user could either explicitly
> add a method extension
>                to a package or use the* notation. The end result should be the star
> notation in the cat
>                and the use of a real package in the background.

It would be nice if old packages could be imported and new ones merged
and exported without problems. If a package is named "Foo", then its
categories would be represented in Monticello as
"Foo-OriginalCategoryName" and its protocols as
"*foo-OriginalProtocolName". This would allow full compatibility.

>        platform could be a problem. So lukas do you if VW uses the *
> convention, I imagine at least when
>        saving code?

Yes, they use the same convention. Categories are not really visible
in VW, but they are the same as on the Pharo side. The package name
could actually be cropped from the protocol, but they strangely don't
do that and still display the *.

Cheers,
Lukas


--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

GemStone (GLASS) will be writing and reading "old-style" mcz files for the foreseeable future, so backward compatibility is important.

Dale
----- "Lukas Renggli" <[hidden email]> wrote:

| >                - idea: we keep the * notation but we hook into the
| tools to
| >                create real package. In particular the user could
| either explicitly
| > add a method extension
| >                to a package or use the* notation. The end result
| should be the star
| > notation in the cat
| >                and the use of a real package in the background.
|
| It would be nice if old packages could be imported and new ones
| merged
| and exported without problems. If a package is named "Foo", then its
| categories would be represented in Monticello as
| "Foo-OriginalCategoryName" and its protocols as
| "*foo-OriginalProtocolName". This would allow full compatibility.
|
| >        platform could be a problem. So lukas do you if VW uses the
| *
| > convention, I imagine at least when
| >        saving code?
|
| Yes, they use the same convention. Categories are not really visible
| in VW, but they are the same as on the Pharo side. The package name
| could actually be cropped from the protocol, but they strangely don't
| do that and still display the *.
|
| Cheers,
| Lukas
|
|
| --
| Lukas Renggli
| http://www.lukas-renggli.ch
|
| _______________________________________________
| Pharo-project mailing list
| [hidden email]
| http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Sep 11, 2009, at 9:33 PM, Lukas Renggli wrote:

yes I believe that this is the way to go. (lot of hack in tools but  
necessary).
If we do it well we will certainly improve the tools too. Because the  
notification should be a good
support.

>>        platform could be a problem. So lukas do you if VW uses the *
>> convention, I imagine at least when
>>        saving code?
>
> Yes, they use the same convention. Categories are not really visible
> in VW, but they are the same as on the Pharo side. The package name
> could actually be cropped from the protocol, but they strangely don't
> do that and still display the *.

Ok this is what I thought. We will do the same.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

yeap!
the life of real project.....been backward compatible

Stef

On Sep 11, 2009, at 10:04 PM, Dale Henrichs wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project