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 <[email protected]> wrote:
> 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
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
