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
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 <stepharo.self@gmail.com>:
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
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
2018-04-12 12:31 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
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
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 <dionisiydk@gmail.com> wrote:
2018-04-12 12:31 GMT+02:00 Peter Uhnák <i.uhnak@gmail.com>:
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
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 <dionisiydk@gmail.com> 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 <stepharo.self@gmail.com>:
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 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
Hi Sean, On Thu, Apr 12, 2018 at 9:49 AM, Sean P. DeNigris <sean@clipperadams.com> 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 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 <eliot.miranda@gmail.com> wrote: > Hi Sean, > > On Thu, Apr 12, 2018 at 9:49 AM, Sean P. DeNigris <sean@clipperadams.com> > 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
Hi Stephane, On Thu, Apr 12, 2018 at 11:46 AM, Stephane Ducasse <stepharo.self@gmail.com> 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 <eliot.miranda@gmail.com> > wrote: > > Hi Sean, > > > > On Thu, Apr 12, 2018 at 9:49 AM, Sean P. DeNigris <sean@clipperadams.com > > > > 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
2018-04-12 20:46 GMT+02:00 Stephane Ducasse <stepharo.self@gmail.com>: > 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 <eliot.miranda@gmail.com> > wrote: > > Hi Sean, > > > > On Thu, Apr 12, 2018 at 9:49 AM, Sean P. DeNigris <sean@clipperadams.com > > > > 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 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 <sean@clipperadams.com> 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 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
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 <dionisiydk@gmail.com> 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 <stepharo.self@gmail.com>:
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
2018-04-12 12:49 GMT+02:00 Stephane Ducasse <stepharo.self@gmail.com>:
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. or 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 <dionisiydk@gmail.com> 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 <stepharo.self@gmail.com>:
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
participants (5)
-
Denis Kudriashov -
Eliot Miranda -
Peter Uhnák -
Sean P. DeNigris -
Stephane Ducasse