Smalltalk › Pharo › Pharo Smalltalk Developers

Why can't we use * in protocol for package extension?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

15 messages Options

Stephane Ducasse-3

Why can't we use * in protocol for package extension?

in calypso.
* was simple and nice.
Now if I create a protocol with a star it got eaten and no protocol
will be created.

Stef

Denis Kudriashov

Re: Why can't we use * in protocol for package extension?

But it shows notification why it does not supported and what to use instead. (it was not available in old versions)

Idea to move away from star convention. Calypso gives you explicit tools to add method to the package. Most simple is checkbox "extension" in the status bar of method editor.

For now star convention will stay internal implementation detail of RPackage. In future it should be completely removed (you know how RPackage is ugly because of that). Only old text code formats will use star protocols.

So Calypso is a step to remove this "star habit" from users.

2018-04-12 11:42 GMT+02:00 Stephane Ducasse <[hidden email]>:

in calypso.
* was simple and nice.
Now if I create a protocol with a star it got eaten and no protocol
will be created.

Stef

Peter Uhnak

Re: Why can't we use * in protocol for package extension?

In future it should be completely removed (you know how RPackage is ugly because of that). Only old text code formats will use star protocols.

So Calypso is a step to remove this "star habit" from users.

What is the correct way to generate such methods then?

I use Something compile: 'method' classified: '*OtherPackage' ... but if the star convention is removed?

Thanks,

Peter

Stephane Ducasse-3

Re: Why can't we use * in protocol for package extension?

In reply to this post by Denis Kudriashov

You see. You pushed this idea and at then end we will have to handle the mess.
I do not see why we cannot simply support *.
Seriously why eveybody on earth has to inforce their own view.
Now to declare an extension (it took me at least 10 min) we have to
create a protocol then to click on it then to select an existing
package!
Why it cannot stay and be simple

On Thu, Apr 12, 2018 at 12:10 PM, Denis Kudriashov <[hidden email]> wrote:

> But it shows notification why it does not supported and what to use instead.
> (it was not available in old versions)
>
> Idea to move away from star convention. Calypso gives you explicit tools to
> add method to the package. Most simple is checkbox "extension" in the status
> bar of method editor.
> For now star convention will stay internal implementation detail of
> RPackage. In future it should be completely removed (you know how RPackage
> is ugly because of that). Only old text code formats will use star
> protocols.
>
> So Calypso is a step to remove this "star habit" from users.
>
> 2018-04-12 11:42 GMT+02:00 Stephane Ducasse <[hidden email]>:
>>
>> in calypso.
>> * was simple and nice.
>> Now if I create a protocol with a star it got eaten and no protocol
>> will be created.
>>
>> Stef
>>
>

Stephane Ducasse-3

Re: Why can't we use * in protocol for package extension?

In reply to this post by Denis Kudriashov

I do not see why we should remove star protocols. It will break many things.
Why can't we focus on important next steps.

On Thu, Apr 12, 2018 at 12:10 PM, Denis Kudriashov <[hidden email]> wrote:

Denis Kudriashov

Re: Why can't we use * in protocol for package extension?

In reply to this post by Peter Uhnak

2018-04-12 12:31 GMT+02:00 Peter Uhnák <[hidden email]>:

In future it should be completely removed (you know how RPackage is ugly because of that). Only old text code formats will use star protocols.

So Calypso is a step to remove this "star habit" from users.

What is the correct way to generate such methods then?
I use Something compile: 'method' classified: '*OtherPackage' ... but if the star convention is removed?

It should be simple package parameter like:

Something compile: 'method' inPackage: #'OtherPackage' asPackage

Thanks,
Peter

Stephane Ducasse-3

Re: Why can't we use * in protocol for package extension?

Ok let us move away. Now I would like to know all the old ways and clean them.

Stef

On Thu, Apr 12, 2018 at 1:37 PM, Denis Kudriashov <[hidden email]> wrote:

>
>
> 2018-04-12 12:31 GMT+02:00 Peter Uhnák <[hidden email]>:
>>>
>>> In future it should be completely removed (you know how RPackage is ugly
>>> because of that). Only old text code formats will use star protocols.
>>>
>>>
>>> So Calypso is a step to remove this "star habit" from users.
>>
>>
>> What is the correct way to generate such methods then?
>> I use Something compile: 'method' classified: '*OtherPackage' ... but if
>> the star convention is removed?
>
>
> It should be simple package parameter like:
>
> Something compile: 'method' inPackage: #'OtherPackage' asPackage
>
>
>>
>>
>> Thanks,
>> Peter
>
>

Denis Kudriashov

Re: Why can't we use * in protocol for package extension?

In reply to this post by Stephane Ducasse-3

2018-04-12 12:49 GMT+02:00 Stephane Ducasse <[hidden email]>:

I do not see why we should remove star protocols.

Think about future module system which you already started to work with others.

I don't think you plan to support string convention there.

I just want RIGHT simple things:

aMethod package: aPackage.

aPackage addMethod: aMethod.

Instead of

aMethod protocol: '*', aPackage name

Which is the only way to create extension in current system.

It will break many things.

As soon as package management will do this part in the right way we will just need to fix code exporters and importers.

But fixing package system is not easy task. Extension protocols and packages are bound implicitly using events.

Why can't we focus on important next steps.

I would say it is required step to achieve module system.

On Thu, Apr 12, 2018 at 12:10 PM, Denis Kudriashov <[hidden email]> wrote:

> But it shows notification why it does not supported and what to use instead.
> (it was not available in old versions)
>
> Idea to move away from star convention. Calypso gives you explicit tools to
> add method to the package. Most simple is checkbox "extension" in the status
> bar of method editor.
> For now star convention will stay internal implementation detail of
> RPackage. In future it should be completely removed (you know how RPackage
> is ugly because of that). Only old text code formats will use star
> protocols.
>
> So Calypso is a step to remove this "star habit" from users.
>
> 2018-04-12 11:42 GMT+02:00 Stephane Ducasse <[hidden email]>:
>>
>> in calypso.
>> * was simple and nice.
>> Now if I create a protocol with a star it got eaten and no protocol
>> will be created.
>>
>> Stef
>>
>

Sean P. DeNigris

Re: Why can't we use * in protocol for package extension?

Administrator

In reply to this post by Stephane Ducasse-3

Stephane Ducasse-3 wrote
> You see. You pushed this idea and at then end we will have to handle the
> mess.
> I do not see why we cannot simply support *.

I'm surprised by this resistance. The *Xyz was always an ugly hack, part of
Squeak's overloading the same mechanism for both system categorization and
packaging, and exposing and limiting protocols as "just dumb strings", all
of which IMHO makes the system much less understandable (no real "private"
tagging, extension methods can't show up in proper protocol, etc). We're not
in a feature freeze, so what is the problem with tackling part of this mess
now? Sure, maybe the UI support can be improved, but let's focus on some
concrete suggestions.

Denis and I just happened to be talking about this larger issue the other
day. Here are a few snippets I dug up during that conversations of some of
my many posts about this over the years…

> we have overloaded system categories to package code for SCM. System
> categories should be tags (preferably multiple allowed)
> which offer a logical view of the system. Packages, the POV we show now,
> are orthogonal and much less useful for users.
(edited)
and another:
> I feel more and more that the standard "Package" pane is only useful
> for... packaging, and when one takes off the dependency management hat and
> puts the user hat on (i.e. most of the time), what you really want there
> is a logical view of the system. So I see three use cases:
- Logical view of the system - I guess this was the original intention of
Categories, but has been hijacked by Monticello
- By project - which, as you just showed, we have now, yay!
- By package - the least useful, but primary (up til now), view
(edited)
and regarding Nautilus' tree package pane (when it first arrived):
I noticed that right now, separate packages within the same project are not
collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they will
be siblings in the tree, instead of both under MyProject. It seems like it
would be more useful to have
- MyProject
- Core
- Platform
in the tree

> it seems that the tree is primarily about chunking information into
> manageable pieces.

A primary difficulty here is that packages are often divided for reasons
that have nothing to do with the domain model, e.g. the ubiquitous
MyPackage-Platform, which is an artifact of Metacello that is not all that
relevant to a user wanting to understand the system.

From the naive user perspective, if I'm exploring from the top level of the
system, I want to see things like:
- CodeImport
- Collections
- Compiler

From this perspective, the 14 entries for Collections, multiplied by a few
dozen top-level categories make the list unwieldy and only marginally less
daunting than the flattened list we used to have (see
http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two )

-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Cheers,
Sean

Eliot Miranda-2

Re: Why can't we use * in protocol for package extension?

Hi Sean,

On Thu, Apr 12, 2018 at 9:49 AM, Sean P. DeNigris <[hidden email]> wrote:

Stephane Ducasse-3 wrote
> You see. You pushed this idea and at then end we will have to handle the
> mess.
> I do not see why we cannot simply support *.

I'm surprised by this resistance. The *Xyz was always an ugly hack, part of
Squeak's overloading the same mechanism for both system categorization and
packaging, and exposing and limiting protocols as "just dumb strings", all
of which IMHO makes the system much less understandable (no real "private"
tagging, extension methods can't show up in proper protocol, etc). We're not
in a feature freeze, so what is the problem with tackling part of this mess
now? Sure, maybe the UI support can be improved, but let's focus on some
concrete suggestions.

Denis and I just happened to be talking about this larger issue the other
day. Here are a few snippets I dug up during that conversations of some of
my many posts about this over the years…

> we have overloaded system categories to package code for SCM. System
> categories should be tags (preferably multiple allowed)
> which offer a logical view of the system. Packages, the POV we show now,
> are orthogonal and much less useful for users.
(edited)
and another:
> I feel more and more that the standard "Package" pane is only useful
> for... packaging, and when one takes off the dependency management hat and
> puts the user hat on (i.e. most of the time), what you really want there
> is a logical view of the system. So I see three use cases:
- Logical view of the system - I guess this was the original intention of
Categories, but has been hijacked by Monticello
- By project - which, as you just showed, we have now, yay!
- By package - the least useful, but primary (up til now), view
(edited)
and regarding Nautilus' tree package pane (when it first arrived):
I noticed that right now, separate packages within the same project are not
collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they will
be siblings in the tree, instead of both under MyProject. It seems like it
would be more useful to have
- MyProject
- Core
- Platform
in the tree

If you and Denis are "going radical" and going to do the right thing then please also give thought to overrides and unloading. Allowing a package to override a set of methods on load is a useful facility, fraught with difficulties (being able to browse the overridden versions being the main one). Having things organized so that the overridden versions are saved, don't get lost when source is rewritten, etc, etc (made much easier by keeping source in methods), but most importantly, get restored in the right order when packages are unloaded. I believe it's as simple as associating the methods that are overridden with the packages to which they belong, and maintaining a load order (so that if PkgA B & C implement C>>foo, and are loaded in the order A, B, C, then we can compute easily that unloading C restores PkgB's C>>foo, and that unloading B does not affect C>>foo).

> it seems that the tree is primarily about chunking information into
> manageable pieces.

A primary difficulty here is that packages are often divided for reasons
that have nothing to do with the domain model, e.g. the ubiquitous
MyPackage-Platform, which is an artifact of Metacello that is not all that
relevant to a user wanting to understand the system.

From the naive user perspective, if I'm exploring from the top level of the
system, I want to see things like:
- CodeImport
- Collections
- Compiler

From this perspective, the 14 entries for Collections, multiplied by a few
dozen top-level categories make the list unwieldy and only marginally less
daunting than the flattened list we used to have (see
http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two )

-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

_,,,^..^,,,_

best, Eliot

Stephane Ducasse-3

Re: Why can't we use * in protocol for package extension?

In reply to this post by Sean P. DeNigris

Sean

you are mixing and other concerns. The tools could show all the
collections as projects.
Packages are unit of loading. So small modular packages are good.

Stef

On Thu, Apr 12, 2018 at 6:49 PM, Sean P. DeNigris <[hidden email]> wrote:

> Stephane Ducasse-3 wrote
>> You see. You pushed this idea and at then end we will have to handle the
>> mess.
>> I do not see why we cannot simply support *.
>
> I'm surprised by this resistance. The *Xyz was always an ugly hack, part of
> Squeak's overloading the same mechanism for both system categorization and
> packaging, and exposing and limiting protocols as "just dumb strings", all
> of which IMHO makes the system much less understandable (no real "private"
> tagging, extension methods can't show up in proper protocol, etc). We're not
> in a feature freeze, so what is the problem with tackling part of this mess
> now? Sure, maybe the UI support can be improved, but let's focus on some
> concrete suggestions.
>
> Denis and I just happened to be talking about this larger issue the other
> day. Here are a few snippets I dug up during that conversations of some of
> my many posts about this over the years…
>
>> we have overloaded system categories to package code for SCM. System
>> categories should be tags (preferably multiple allowed)
>> which offer a logical view of the system. Packages, the POV we show now,
>> are orthogonal and much less useful for users.
> (edited)
> and another:
>> I feel more and more that the standard "Package" pane is only useful
>> for... packaging, and when one takes off the dependency management hat and
>> puts the user hat on (i.e. most of the time), what you really want there
>> is a logical view of the system. So I see three use cases:
> - Logical view of the system - I guess this was the original intention of
> Categories, but has been hijacked by Monticello
> - By project - which, as you just showed, we have now, yay!
> - By package - the least useful, but primary (up til now), view
> (edited)
> and regarding Nautilus' tree package pane (when it first arrived):
> I noticed that right now, separate packages within the same project are not
> collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they will
> be siblings in the tree, instead of both under MyProject. It seems like it
> would be more useful to have
> - MyProject
> - Core
> - Platform
> in the tree
>
>> it seems that the tree is primarily about chunking information into
>> manageable pieces.
>
> A primary difficulty here is that packages are often divided for reasons
> that have nothing to do with the domain model, e.g. the ubiquitous
> MyPackage-Platform, which is an artifact of Metacello that is not all that
> relevant to a user wanting to understand the system.
>
> From the naive user perspective, if I'm exploring from the top level of the
> system, I want to see things like:
> - CodeImport
> - Collections
> - Compiler
>
> From this perspective, the 14 entries for Collections, multiplied by a few
> dozen top-level categories make the list unwieldy and only marginally less
> daunting than the flattened list we used to have (see
> http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two )
>
>
>
> -----
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>

Stephane Ducasse-3

Re: Why can't we use * in protocol for package extension?

In reply to this post by Eliot Miranda-2

Eliot

We do not want to go the road of overrides. We want to keep our
engineer task forces.

Stef

On Thu, Apr 12, 2018 at 7:31 PM, Eliot Miranda <[hidden email]> wrote:

> Hi Sean,
>
> On Thu, Apr 12, 2018 at 9:49 AM, Sean P. DeNigris <[hidden email]>
> wrote:
>>
>> Stephane Ducasse-3 wrote
>> > You see. You pushed this idea and at then end we will have to handle the
>> > mess.
>> > I do not see why we cannot simply support *.
>>
>> I'm surprised by this resistance. The *Xyz was always an ugly hack, part
>> of
>> Squeak's overloading the same mechanism for both system categorization and
>> packaging, and exposing and limiting protocols as "just dumb strings", all
>> of which IMHO makes the system much less understandable (no real "private"
>> tagging, extension methods can't show up in proper protocol, etc). We're
>> not
>> in a feature freeze, so what is the problem with tackling part of this
>> mess
>> now? Sure, maybe the UI support can be improved, but let's focus on some
>> concrete suggestions.
>>
>> Denis and I just happened to be talking about this larger issue the other
>> day. Here are a few snippets I dug up during that conversations of some of
>> my many posts about this over the years…
>>
>> > we have overloaded system categories to package code for SCM. System
>> > categories should be tags (preferably multiple allowed)
>> > which offer a logical view of the system. Packages, the POV we show now,
>> > are orthogonal and much less useful for users.
>> (edited)
>> and another:
>> > I feel more and more that the standard "Package" pane is only useful
>> > for... packaging, and when one takes off the dependency management hat
>> > and
>> > puts the user hat on (i.e. most of the time), what you really want there
>> > is a logical view of the system. So I see three use cases:
>> - Logical view of the system - I guess this was the original intention of
>> Categories, but has been hijacked by Monticello
>> - By project - which, as you just showed, we have now, yay!
>> - By package - the least useful, but primary (up til now), view
>> (edited)
>> and regarding Nautilus' tree package pane (when it first arrived):
>> I noticed that right now, separate packages within the same project are
>> not
>> collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they will
>> be siblings in the tree, instead of both under MyProject. It seems like it
>> would be more useful to have
>> - MyProject
>> - Core
>> - Platform
>> in the tree
>
>
> If you and Denis are "going radical" and going to do the right thing then
> please also give thought to overrides and unloading. Allowing a package to
> override a set of methods on load is a useful facility, fraught with
> difficulties (being able to browse the overridden versions being the main
> one). Having things organized so that the overridden versions are saved,
> don't get lost when source is rewritten, etc, etc (made much easier by
> keeping source in methods), but most importantly, get restored in the right
> order when packages are unloaded. I believe it's as simple as associating
> the methods that are overridden with the packages to which they belong, and
> maintaining a load order (so that if PkgA B & C implement C>>foo, and are
> loaded in the order A, B, C, then we can compute easily that unloading C
> restores PkgB's C>>foo, and that unloading B does not affect C>>foo).
>
>>
>>
>> > it seems that the tree is primarily about chunking information into
>> > manageable pieces.
>>
>> A primary difficulty here is that packages are often divided for reasons
>> that have nothing to do with the domain model, e.g. the ubiquitous
>> MyPackage-Platform, which is an artifact of Metacello that is not all that
>> relevant to a user wanting to understand the system.
>>
>> From the naive user perspective, if I'm exploring from the top level of
>> the
>> system, I want to see things like:
>> - CodeImport
>> - Collections
>> - Compiler
>>
>> From this perspective, the 14 entries for Collections, multiplied by a few
>> dozen top-level categories make the list unwieldy and only marginally less
>> daunting than the flattened list we used to have (see
>> http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two )
>>
>>
>>
>> -----
>> Cheers,
>> Sean
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot

Eliot Miranda-2

Re: Why can't we use * in protocol for package extension?

Hi Stephane,

On Thu, Apr 12, 2018 at 11:46 AM, Stephane Ducasse <[hidden email]> wrote:

Eliot

We do not want to go the road of overrides. We want to keep our
engineer task forces.

There are overrides anyway. In general overrides are unavoidable in some circumstances. The issue is not whether they exist, it's whether they work reliably. Right now they don't; they rely on changes file technology that is extremely fragile. Sean and Denis' move to reimplement extensions is an opportunity to implement overrides correctly.

Stef

On Thu, Apr 12, 2018 at 7:31 PM, Eliot Miranda <[hidden email]> wrote:
> Hi Sean,
>
> On Thu, Apr 12, 2018 at 9:49 AM, Sean P. DeNigris <[hidden email]>
> wrote:
>>
>> Stephane Ducasse-3 wrote
>> > You see. You pushed this idea and at then end we will have to handle the
>> > mess.
>> > I do not see why we cannot simply support *.
>>
>> I'm surprised by this resistance. The *Xyz was always an ugly hack, part
>> of
>> Squeak's overloading the same mechanism for both system categorization and
>> packaging, and exposing and limiting protocols as "just dumb strings", all
>> of which IMHO makes the system much less understandable (no real "private"
>> tagging, extension methods can't show up in proper protocol, etc). We're
>> not
>> in a feature freeze, so what is the problem with tackling part of this
>> mess
>> now? Sure, maybe the UI support can be improved, but let's focus on some
>> concrete suggestions.
>>
>> Denis and I just happened to be talking about this larger issue the other
>> day. Here are a few snippets I dug up during that conversations of some of
>> my many posts about this over the years…
>>
>> > we have overloaded system categories to package code for SCM. System
>> > categories should be tags (preferably multiple allowed)
>> > which offer a logical view of the system. Packages, the POV we show now,
>> > are orthogonal and much less useful for users.
>> (edited)
>> and another:
>> > I feel more and more that the standard "Package" pane is only useful
>> > for... packaging, and when one takes off the dependency management hat
>> > and
>> > puts the user hat on (i.e. most of the time), what you really want there
>> > is a logical view of the system. So I see three use cases:
>> - Logical view of the system - I guess this was the original intention of
>> Categories, but has been hijacked by Monticello
>> - By project - which, as you just showed, we have now, yay!
>> - By package - the least useful, but primary (up til now), view
>> (edited)
>> and regarding Nautilus' tree package pane (when it first arrived):
>> I noticed that right now, separate packages within the same project are
>> not
>> collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they will
>> be siblings in the tree, instead of both under MyProject. It seems like it
>> would be more useful to have
>> - MyProject
>> - Core
>> - Platform
>> in the tree
>
>
> If you and Denis are "going radical" and going to do the right thing then
> please also give thought to overrides and unloading. Allowing a package to
> override a set of methods on load is a useful facility, fraught with
> difficulties (being able to browse the overridden versions being the main
> one). Having things organized so that the overridden versions are saved,
> don't get lost when source is rewritten, etc, etc (made much easier by
> keeping source in methods), but most importantly, get restored in the right
> order when packages are unloaded. I believe it's as simple as associating
> the methods that are overridden with the packages to which they belong, and
> maintaining a load order (so that if PkgA B & C implement C>>foo, and are
> loaded in the order A, B, C, then we can compute easily that unloading C
> restores PkgB's C>>foo, and that unloading B does not affect C>>foo).
>
>>
>>
>> > it seems that the tree is primarily about chunking information into
>> > manageable pieces.
>>
>> A primary difficulty here is that packages are often divided for reasons
>> that have nothing to do with the domain model, e.g. the ubiquitous
>> MyPackage-Platform, which is an artifact of Metacello that is not all that
>> relevant to a user wanting to understand the system.
>>
>> From the naive user perspective, if I'm exploring from the top level of
>> the
>> system, I want to see things like:
>> - CodeImport
>> - Collections
>> - Compiler
>>
>> From this perspective, the 14 entries for Collections, multiplied by a few
>> dozen top-level categories make the list unwieldy and only marginally less
>> daunting than the flattened list we used to have (see
>> http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two )
>>
>>
>>
>> -----
>> Cheers,
>> Sean
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot

_,,,^..^,,,_

best, Eliot

Denis Kudriashov

Re: Why can't we use * in protocol for package extension?

In reply to this post by Stephane Ducasse-3

2018-04-12 20:46 GMT+02:00 Stephane Ducasse <[hidden email]>:

Eliot

We do not want to go the road of overrides. We want to keep our
engineer task forces.

We will need support this anyway. It's very similar to loading methods extending undefined class (you already have prototype, right?).

Imagine that you load project which overrides your package which already includes many changes. It should be safe to commit package. Overridden methods should not be removed.

And to support it we will need model for package overrides which will bring features which Eliot describes.

Stef

On Thu, Apr 12, 2018 at 7:31 PM, Eliot Miranda <[hidden email]> wrote:
> Hi Sean,
>
> On Thu, Apr 12, 2018 at 9:49 AM, Sean P. DeNigris <[hidden email]>
> wrote:
>>
>> Stephane Ducasse-3 wrote
>> > You see. You pushed this idea and at then end we will have to handle the
>> > mess.
>> > I do not see why we cannot simply support *.
>>
>> I'm surprised by this resistance. The *Xyz was always an ugly hack, part
>> of
>> Squeak's overloading the same mechanism for both system categorization and
>> packaging, and exposing and limiting protocols as "just dumb strings", all
>> of which IMHO makes the system much less understandable (no real "private"
>> tagging, extension methods can't show up in proper protocol, etc). We're
>> not
>> in a feature freeze, so what is the problem with tackling part of this
>> mess
>> now? Sure, maybe the UI support can be improved, but let's focus on some
>> concrete suggestions.
>>
>> Denis and I just happened to be talking about this larger issue the other
>> day. Here are a few snippets I dug up during that conversations of some of
>> my many posts about this over the years…
>>
>> > we have overloaded system categories to package code for SCM. System
>> > categories should be tags (preferably multiple allowed)
>> > which offer a logical view of the system. Packages, the POV we show now,
>> > are orthogonal and much less useful for users.
>> (edited)
>> and another:
>> > I feel more and more that the standard "Package" pane is only useful
>> > for... packaging, and when one takes off the dependency management hat
>> > and
>> > puts the user hat on (i.e. most of the time), what you really want there
>> > is a logical view of the system. So I see three use cases:
>> - Logical view of the system - I guess this was the original intention of
>> Categories, but has been hijacked by Monticello
>> - By project - which, as you just showed, we have now, yay!
>> - By package - the least useful, but primary (up til now), view
>> (edited)
>> and regarding Nautilus' tree package pane (when it first arrived):
>> I noticed that right now, separate packages within the same project are
>> not
>> collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they will
>> be siblings in the tree, instead of both under MyProject. It seems like it
>> would be more useful to have
>> - MyProject
>> - Core
>> - Platform
>> in the tree
>
>
> If you and Denis are "going radical" and going to do the right thing then
> please also give thought to overrides and unloading. Allowing a package to
> override a set of methods on load is a useful facility, fraught with
> difficulties (being able to browse the overridden versions being the main
> one). Having things organized so that the overridden versions are saved,
> don't get lost when source is rewritten, etc, etc (made much easier by
> keeping source in methods), but most importantly, get restored in the right
> order when packages are unloaded. I believe it's as simple as associating
> the methods that are overridden with the packages to which they belong, and
> maintaining a load order (so that if PkgA B & C implement C>>foo, and are
> loaded in the order A, B, C, then we can compute easily that unloading C
> restores PkgB's C>>foo, and that unloading B does not affect C>>foo).
>
>>
>>
>> > it seems that the tree is primarily about chunking information into
>> > manageable pieces.
>>
>> A primary difficulty here is that packages are often divided for reasons
>> that have nothing to do with the domain model, e.g. the ubiquitous
>> MyPackage-Platform, which is an artifact of Metacello that is not all that
>> relevant to a user wanting to understand the system.
>>
>> From the naive user perspective, if I'm exploring from the top level of
>> the
>> system, I want to see things like:
>> - CodeImport
>> - Collections
>> - Compiler
>>
>> From this perspective, the 14 entries for Collections, multiplied by a few
>> dozen top-level categories make the list unwieldy and only marginally less
>> daunting than the flattened list we used to have (see
>> http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two )
>>
>>
>>
>> -----
>> Cheers,
>> Sean
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot

Sean P. DeNigris

Re: Why can't we use * in protocol for package extension?

Administrator

In reply to this post by Stephane Ducasse-3

Stephane Ducasse-3 wrote
> you are mixing and other concerns

True, they are not the same issue. I guess the connection for me is that
they are both examples of overloading a single mechanism to accomplish at
best orthogonal and often conflicting goals. Right now we're using dumb
strings to define: 1) method visibility (e.g. "private") 2) extension
package 3) categorization. It seems way overdue for a real model. Thus I was
surprised that there seemed to be resistance to change.

-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Cheers,
Sean