packages :)

Hi

I started to reimplement the package class is did because the previous one was a bit messy.
I'm currently migrating old the tests to the new implementation and for now I have around 93% coverage.
I started to build a stupid browser to check my api.
Doru started to code a Glamour browser to see if this was ok.

Now I would really like if
        - somebody could have a look at the code
        - develop a simple package browser showing class extensions (it would help me to define
        a good api to walk though a package). I started to use Momo and this is why I reimplemented the class
        but so far I get nearly the same interface and I think that I can do better.

Of course there are comments and tests so if one of you want to join we could do remote pair coding to be able
to release a first version. So far
        - integration with MC
        - migrating from packageInfo
        - event notification
        are missing.

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

Can you provide a Gofer expression to load it?

Lukas

On 16 March 2010 17:21, Stéphane Ducasse <[hidden email]> wrote:


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

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

Hi,

To get it:
Gofer new
        squeaksource: 'PharoTaskForces';
        package: 'RPackageAll';
        load.

To get a super-simple browser that shows extensions in italics:

Gofer new
        squeaksource: 'glamoroust';
        package: 'ConfigurationOfGlamoroust';
        load.
(Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault.


To execute it on a super simple package structure:
RMockFilledPackageOrganizer fillUp.
(Smalltalk at: #GTCoder) openOn: RMockFilledPackageOrganizer default

Cheers,
Doru


On 16 Mar 2010, at 17:23, Lukas Renggli wrote:

--
www.tudorgirba.com

"Reasonable is what we are accustomed with."


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

Thank you, I will give it a try (fed up writing).

Lukas

On 16 March 2010 18:00, Tudor Girba <[hidden email]> wrote:


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

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

I forgot to mention

You should load RPackage-All from PharoTaskForces

Stef
On Mar 16, 2010, at 5:21 PM, Stéphane Ducasse wrote:


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

> Thank you, I will give it a try (fed up writing).

this is a good sign :)

Stef


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

I have some comments, to both the package implementation and the
Glamour browser. The other browser didn't work, I guess I miss some
extra package.

- I used the code below to import the existing packages into the new
model. Maybe something like this should be included on the class side
of RPackageOrganizer to have a realistic model?

        | package |
        PackageOrganizer default packages
                do: [ :info |
                        package := RPackage2 named: info packageName.
                        info classes do: [ :each | package addClassDefinition: each ].
                        info coreMethods do: [ :each |
                                each isValid
                                        ifTrue: [ package addMethod: each compiledMethod isExtension: false ] ].
                        info extensionMethods do: [ :each |
                                each isValid
                                        ifTrue: [ package addMethod: each compiledMethod isExtension: true ] ] ]
                displayingProgress: 'Importing'

Then I opened the glamour browser using:

        GTCoder openOn: RPackageOrganizer default

- I find it quite strange that I have to declare if a method is an
extension or not. Isn't a that obvious when looking at the defined
classes? Having two dictionaries for methods makes it extremely
difficult to move stuff around because always 4 separate cases need to
be handled.

- The fact that compiled methods are stored in the model is very
dangerous. You might hold onto compiled methods that have long been
replaced with other ones. Just by playing a bit with the model I run
into that situation (I don't know how). I think just keeping the
selector internally would be much safer and solve all kinds of
troubles (exactly like this is done for the classes). You'll have to
check anyway if the method is still present when you iterate over the
methods. A single use of #doSilently: (and there are lots of them in
the image) can completely screw up the complete package model.

- The browser displays nicely the extended classes, but for the
methods I don't see the protocols and the complete set of selectors
implemented. I think these things should be part of the browser,
otherwise we don't see if the package model can answer these queries
quick enough.

- The browser displays extension methods on both instance and
class-side. When browsing an extended class, the extensions are not
displayed.

That's it for the moment. I see a cool model emerging :-)

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

Hi Lukas,

On 16 Mar 2010, at 21:50, Lukas Renggli wrote:

Stef said that this was a reminiscent from before deciding he wants to  
declare the class explicitly, but we agreed that specifying the  
extension explicitly is not necessary.

> Having two dictionaries for methods makes it extremely
> difficult to move stuff around because always 4 separate cases need to
> be handled.

I also do not like this part either.

> - The fact that compiled methods are stored in the model is very
> dangerous. You might hold onto compiled methods that have long been
> replaced with other ones. Just by playing a bit with the model I run
> into that situation (I don't know how). I think just keeping the
> selector internally would be much safer and solve all kinds of
> troubles (exactly like this is done for the classes). You'll have to
> check anyway if the method is still present when you iterate over the
> methods. A single use of #doSilently: (and there are lots of them in
> the image) can completely screw up the complete package model.

The model does not store compiled methods, or classes. It only stores  
symbols.

> - The browser displays nicely the extended classes, but for the
> methods I don't see the protocols and the complete set of selectors
> implemented. I think these things should be part of the browser,
> otherwise we don't see if the package model can answer these queries
> quick enough.

I agree, but this was just a quick thing to see what kind of  
navigation methods are needed to get the classes and methods.  
Categories are still to be added.

> - The browser displays extension methods on both instance and
> class-side. When browsing an extended class, the extensions are not
> displayed.

Yes, these were bugs :). I tried to fix these, but I think I bumped  
into other problems, so I will stop for now.

Cheers,
Doru

--
www.tudorgirba.com

"Sometimes the best solution is not the best solution."


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

True, sorry about that. I did not open the inspector wide enough and I
somehow made that conclusion from the public API :-)

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

On 16 March 2010 19:00, Tudor Girba <[hidden email]> wrote:
> Hi,
>
> To get it:
> Gofer new
>        squeaksource: 'PharoTaskForces';
>        package: 'RPackageAll';
>        load.
>
I tried to do that in core image,
and found that it having unresolved dependencies on:
MorhTreeModel
and
MorphTreeNodeModel

what package i need for them?



--
Best regards,
Igor Stasenko AKA sig.

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

On 17 March 2010 08:35, Igor Stasenko <[hidden email]> wrote: Oh, sorry, it was wrong image (1.0).



--
Best regards,
Igor Stasenko AKA sig.

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

Hi Stef,

i took a look on your implementation and i don't like it. :)

It tries to work with methods and classes through symbolic names.. and
you immediately end up with
gemmorage of a need to keep separate 'core' and 'extension' , 'meta'
and 'instance-side' methods in your model.

By looking at:

addSelector: aSelector ofClass: aClass
        "Add the method to the receiver. If the class is not locally defined
in that package then
        the method is defined as a method extension: ie extending another package.
        The method is not added to the class."

        aClass isMeta
                ifTrue: [(metaclassSelectors at: aClass soleInstance name asSymbol
ifAbsentPut: [Set new]) add: aSelector.]
                ifFalse: [(classSelectors at: aClass name asSymbol ifAbsentPut: [Set
new]) add: aSelector.].

This approach, from very starting, unnecessary complexifies the model,
and requires a lot of glue code.

I don't know what is the purpose of making a package to be a dead
piece of flesh, which reflects own organization by using symbols,
instead of real objects? Who are you trying to deceive with that?

If you remember, i put some thoughts about packages here before. And
even implemented a prototype package model myself (did you looked at
it?). My concepts is simple and object-oriented (instead of
symbolic-names oriented ;) ) :
If we take a most abstract and stripped down concept then, in order to
define a package, we need just two things:
- a set of objects , which belong to that package
- and a namespace (name->object), where name is a symbol and object is
one of the objects, which
belong to package.

note, that there is no any 'methods' or 'classes' . It is just objects
and names. And then you can start adding flesh on that skeleton by
implementing things , like covenient adding/defining/lookup classes,
methods , etc etc.
But if you don't that , you model will remain a piece of flesh,
without skeleton - it can't move , it can only lie on the ground and
rot :)

I don't understand, why to not work with actual objects, instead of
names? Please enlighten me, why you want to refer to objects
indirectly and leaving to somethings else in the system to decide how
these names turned into a real objects.
What is the benefit of having such indirect model?

In such form, a package becomes only a view of something which already
exists in a system without it. It doesn't defining a domain space -
just reflecting existing one (a years-old existing system organization
(classes and methods)).
And thus, you will have a hard times when you would want to migrate to
a new system organization, because all levers of control lying
elsewhere, instead in a package itself.


On 16 March 2010 18:21, Stéphane Ducasse <[hidden email]> wrote:


--
Best regards,
Igor Stasenko AKA sig.

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

> It tries to work with methods and classes through symbolic names.. and
> you immediately end up with
> gemmorage of a need to keep separate 'core' and 'extension' , 'meta'
> and 'instance-side' methods in your model.

Yes, that's what I suggested, merge the extension and core dictionaries.

> I don't know what is the purpose of making a package to be a dead
> piece of flesh, which reflects own organization by using symbols,
> instead of real objects? Who are you trying to deceive with that?

Incremental development. Separation of concerns.

If the package would contain the real classes and real methods one had
to change (literally) thousands of places in the system.

> If you remember, i put some thoughts about packages here before. And
> even implemented a prototype package model myself (did you looked at
> it?). My concepts is simple and object-oriented (instead of
> symbolic-names oriented ;) ) :

Where?

> If we take a most abstract and stripped down concept then, in order to
> define a package, we need just two things:
> - a set of objects , which belong to that package
> - and a namespace (name->object), where name is a symbol and object is
> one of the objects, which
> belong to package.

RPackage is about a PackageInfo replacement, not about a namespace
implementation. Arguably namespacing is something entirely different.

> But if you don't that , you model will remain a piece of flesh,
> without skeleton - it can't move , it can only lie on the ground and
> rot :)

I suggested Stef to look at the environments in the refactoring
engine. They are a proven implementation for more than 10 years, they
work very efficiently with numerous GUIs (OB, VisualWorks, VisualAge),
and have been applied in many different scenarios (introspection,
reflection, refactorings, changes, lint, virtual code, ...).

> I don't understand, why to not work with actual objects, instead of
> names? Please enlighten me, why you want to refer to objects
> indirectly and leaving to somethings else in the system to decide how
> these names turned into a real objects.
> What is the benefit of having such indirect model?

What would a method object refer to other than its class and its
selector? Is the introduction of another layer of objects that
duplicates Class, PseudoClass, MCClassDefinition, RBClass and
CompiledMethod, MethodReference, MCMethodDefinition, RBMethod
reasonable?

Remember, this is just the internal implementation. I agree that to
the outside a package should be represented using dedicated objects.

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

On Mar 16, 2010, at 9:50 PM, Lukas Renggli wrote:

Historically it was like you said in implementation 1 and 2, then I removed the defined classes (implementation 3), then  I realized oops shit, we can have package with class but no methods (and in this case
we should always when removing a method check if this is the last one and if there is none in the metaclass
to trigger a classremoved event), so I reintroduced defined classes as a separate data (implementation 4 = now).
Now I think that we should remove isExtension to go back to the first implementation.
I guess that this is a todo

> Having two dictionaries for methods makes it extremely
> difficult to move stuff around because always 4 separate cases need to
> be handled.

I discussed that point with doru when you went off your office.

>
> - The fact that compiled methods are stored in the model is very
> dangerous.

There should not be or doru changes my code!!!

> You might hold onto compiled methods that have long been
> replaced with other ones. Just by playing a bit with the model I run
> into that situation (I don't know how). I think just keeping the
> selector internally would be much safer and solve all kinds of
> troubles (exactly like this is done for the classes).

but this is like that.
Doru?


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

>> Having two dictionaries for methods makes it extremely
>> difficult to move stuff around because always 4 separate cases need to
>> be handled.
>
> I also do not like this part either.

Lukas this is exactly as in RBEnvironment as you suggested when you visited me.
If you do not want to hold on class object but name as dictionary key
you do not want to have a key that is 'Point class' because you end up been forced
to do a lot of string matching shit. Now this is really simple and fast.

> The model does not store compiled methods, or classes. It only stores symbols.

I prefer that ;)

Like what?

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

On Mar 17, 2010, at 8:32 AM, Igor Stasenko wrote:

> Hi Stef,
>
> i took a look on your implementation and i don't like it. :)

Ok fair
My first implementation was holding classes and objects and people did not like it either.

> It tries to work with methods and classes through symbolic names..


The first implementation was only holding classes and compiled methods/methodreferences
and the problems is that you cannot reason about off-line system.

Lukas told me ok this is not good because of that. Look at RBEnvironment. So I rewrote everything
3 times. So I'm started to get bored.

> I don't know what is the purpose of making a package to be a dead
> piece of flesh, which reflects own organization by using symbols,
> instead of real objects? Who are you trying to deceive with that?


Off image package manipulation.

> If you remember, i put some thoughts about packages here before. And even implemented a prototype package model myself (did you looked at
> it?).

Now where is the code?
What is the cost to find all the extendingClasses, if a method is included in a packages,
classes extensions, how do we hook event for classremoval, classaddition, without raising multiple times
the same.


We could create package and manipulate them even if they are not in the image.


> In such form, a package becomes only a view of something which already
> exists in a system without it. It doesn't defining a domain space -
> just reflecting existing one (a years-old existing system organization
> (classes and methods)).

Exactly.
But if you want to introduce Package then a method should know its package (which I did
in my first implementation).

> And thus, you will have a hard times when you would want to migrate to
> a new system organization, because all levers of control lying
> elsewhere, instead in a package itself.

Did not get this one.



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

On Mar 17, 2010, at 9:23 AM, Lukas Renggli wrote:

>> It tries to work with methods and classes through symbolic names.. and
>> you immediately end up with
>> gemmorage of a need to keep separate 'core' and 'extension' , 'meta'
>> and 'instance-side' methods in your model.
>
> Yes, that's what I suggested, merge the extension and core dictionaries.

I do not see how?
without first class class and no string match: '* class' ?
I'm curious

>> I don't know what is the purpose of making a package to be a dead
>> piece of flesh, which reflects own organization by using symbols,
>> instead of real objects? Who are you trying to deceive with that?
>
> Incremental development. Separation of concerns.
>
> If the package would contain the real classes and real methods one had
> to change (literally) thousands of places in the system.

Igor what happen when your class change shape. I do not know if it is becomed
but if it is not we are in trouble.


>>
> RPackage is about a PackageInfo replacement, not about a namespace
> implementation. Arguably namespacing is something entirely different.

Yes

>> But if you don't that , you model will remain a piece of flesh,
>> without skeleton - it can't move , it can only lie on the ground and
>> rot :)
>
> I suggested Stef to look at the environments in the refactoring
> engine. They are a proven implementation for more than 10 years, they
> work very efficiently with numerous GUIs (OB, VisualWorks, VisualAge),
> and have been applied in many different scenarios (introspection,
> reflection, refactorings, changes, lint, virtual code, ...).

This is what I did.
Now in RB they do not deal with extensions.


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

On 17 March 2010 09:39, Stéphane Ducasse <[hidden email]> wrote:
Sorry, I mis-inspected the object model. Forget all I said in that
paragraph, it is invalid.

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

Hi Stef,

On 17 Mar 2010, at 09:50, Stéphane Ducasse wrote:


The issue is not between instance side and meta side. The issue is  
with having two dictionaries for each: one for extensions and one for  
definitions. If we have the information about which classes are  
defined in this package, we only need to store the methods for the  
class and we know which are extensions and which are not.

Cheers,
Doru

--
www.tudorgirba.com

"Every now and then stop and ask yourself if the war you're fighting  
is the right one."




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

On 17 March 2010 10:23, Lukas Renggli <[hidden email]> wrote: Currently everything in image is centered mainly around classes and
methods & categories.
And only a little around packages.

>> If you remember, i put some thoughts about packages here before. And
>> even implemented a prototype package model myself (did you looked at
>> it?). My concepts is simple and object-oriented (instead of
>> symbolic-names oriented ;) ) :
>
> Where?
>

There was a series of topics,
One of them - 'System changes & security model'
and then others where i tried to describe things a little more.

existing one.

I envisioned a Package (real one) to replace a PackageInfo (hollow one).
Like in attachment.
Err, what you mean by that?
If a 'method object' is a method, then it should behave like a method
- conform on a method's protocol. Isnt?

> Is the introduction of another layer of objects that
> duplicates Class, PseudoClass, MCClassDefinition, RBClass and
> CompiledMethod, MethodReference, MCMethodDefinition, RBMethod
> reasonable?
>
I fail to see a whole point in having these symbolic referencing,
instead of direct ones.
If you need to turn a symbolic name into an object, you can always do
it, when loading the code.
Keeping them inside image after that serving no purpose.


--
Best regards,
Igor Stasenko AKA sig.

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