Use of #deprecated: and/or #deprecatedExplanation:
Locked
 
|
Hi:
In Squeak was common the use of #deprecatedExplanation: and also #deprecate: These methods are not present in Cuis, I'm interested in learn how manage the ports of packages that use de deprecation messages. It's a good practice use, for example, "self flag: 'comment'"?
Thanks. _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Use of #deprecated: and/or #deprecatedExplanation:
|
|
On 12/27/2013 3:24 PM, Germán Arduino wrote:
We don't have a specific good practice for that... yet. What is the idea? To let package users know that that method should not be used? What does that method do in Squeak? Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Use of #deprecated: and/or #deprecatedExplanation:
|
|
When I do this, I usually do something like self flag: #foo. "Need to remember to take care of foo. --cbr" Main point of saying this is, it's nice to have a comment by the flag so when know who raised it and why.
On Fri, Dec 27, 2013 at 2:24 PM, Juan Vuletich <[hidden email]> wrote:
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Use of #deprecated: and/or #deprecatedExplanation:
|
|
Juan: I believe in Pharo they have deprecation warnings. There's a preference to turn them off, and IIRC the first time you hit a deprecated method with them enabled, the system complains (can't remember if it's a dialog or a debugger or what.)
On Fri, Dec 27, 2013 at 6:17 PM, Casey Ransberger <[hidden email]> wrote:
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Use of #deprecated: and/or #deprecatedExplanation:
|
|
That's how they work in Squeak too: Deprecation below is a resumable
Notification: Object >> deprecated: anExplanationString "Warn that the sending method has been deprecated." Preferences showDeprecationWarnings ifTrue: [Deprecation signal: thisContext sender printString, ' has been deprecated. ', anExplanationString] Typically used like this: Behavior >> compile: code classified: category notifying: requestor trailer: bytes ifFail: failBlock self deprecated: 'Use #compile:notifying:trailer:ifFail:'. ^self compile: code notifying: requestor trailer: bytes ifFail: failBlock frank On 28 December 2013 02:19, Casey Ransberger <[hidden email]> wrote: > Juan: I believe in Pharo they have deprecation warnings. There's a > preference to turn them off, and IIRC the first time you hit a deprecated > method with them enabled, the system complains (can't remember if it's a > dialog or a debugger or what.) > > > On Fri, Dec 27, 2013 at 6:17 PM, Casey Ransberger <[hidden email]> > wrote: >> >> When I do this, I usually do something like >> >> self flag: #foo. "Need to remember to take care of foo. --cbr" >> >> Main point of saying this is, it's nice to have a comment by the flag so >> when know who raised it and why. >> >> >> On Fri, Dec 27, 2013 at 2:24 PM, Juan Vuletich <[hidden email]> wrote: >>> >>> On 12/27/2013 3:24 PM, Germán Arduino wrote: >>> >>> Hi: >>> >>> In Squeak was common the use of #deprecatedExplanation: and also >>> #deprecate: >>> >>> These methods are not present in Cuis, I'm interested in learn how manage >>> the ports of packages that use de deprecation messages. It's a good practice >>> use, for example, "self flag: 'comment'"? >>> >>> Thanks. >>> >>> -- >>> Saludos / Regards, >>> Germán Arduino >>> www.arduinosoftware.com >>> >>> >>> We don't have a specific good practice for that... yet. What is the idea? >>> To let package users know that that method should not be used? What does >>> that method do in Squeak? >>> >>> Cheers, >>> Juan Vuletich >>> >>> _______________________________________________ >>> Cuis mailing list >>> [hidden email] >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>> >> > > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Use of #deprecated: and/or #deprecatedExplanation:
|
|
Ah, okay, Squeak does it too then.
So, the question is, do we need this sort of thing in Cuis? Because nothing says deprecated quite like MessageNotUnderstood :D Anyhow it seems to me the reason you'd want this behavior is to let people know to stop using stuff that's present temporarily for back compat, or I suppose maybe to inform #unloadAllKnownPackages that the deprecated stuff can go? Since back compat isn't a strong goal in Cuis, and we're more generally just inclined to rip stuff that isn't absolutely required out, I'd argue that we don't really need this. Counter arguments? --C > On Dec 28, 2013, at 3:18 AM, Frank Shearar <[hidden email]> wrote: > > That's how they work in Squeak too: Deprecation below is a resumable > Notification: > > Object >> deprecated: anExplanationString > "Warn that the sending method has been deprecated." > > Preferences showDeprecationWarnings ifTrue: > [Deprecation signal: thisContext sender printString, ' has > been deprecated. ', anExplanationString] > > > Typically used like this: > > Behavior >> compile: code classified: category notifying: requestor > trailer: bytes ifFail: failBlock > self deprecated: 'Use #compile:notifying:trailer:ifFail:'. > ^self compile: code notifying: requestor trailer: bytes ifFail: failBlock > > frank > >> On 28 December 2013 02:19, Casey Ransberger <[hidden email]> wrote: >> Juan: I believe in Pharo they have deprecation warnings. There's a >> preference to turn them off, and IIRC the first time you hit a deprecated >> method with them enabled, the system complains (can't remember if it's a >> dialog or a debugger or what.) >> >> >> On Fri, Dec 27, 2013 at 6:17 PM, Casey Ransberger <[hidden email]> >> wrote: >>> >>> When I do this, I usually do something like >>> >>> self flag: #foo. "Need to remember to take care of foo. --cbr" >>> >>> Main point of saying this is, it's nice to have a comment by the flag so >>> when know who raised it and why. >>> >>> >>>> On Fri, Dec 27, 2013 at 2:24 PM, Juan Vuletich <[hidden email]> wrote: >>>> >>>> On 12/27/2013 3:24 PM, Germán Arduino wrote: >>>> >>>> Hi: >>>> >>>> In Squeak was common the use of #deprecatedExplanation: and also >>>> #deprecate: >>>> >>>> These methods are not present in Cuis, I'm interested in learn how manage >>>> the ports of packages that use de deprecation messages. It's a good practice >>>> use, for example, "self flag: 'comment'"? >>>> >>>> Thanks. >>>> >>>> -- >>>> Saludos / Regards, >>>> Germán Arduino >>>> www.arduinosoftware.com >>>> >>>> >>>> We don't have a specific good practice for that... yet. What is the idea? >>>> To let package users know that that method should not be used? What does >>>> that method do in Squeak? >>>> >>>> Cheers, >>>> Juan Vuletich >>>> >>>> _______________________________________________ >>>> Cuis mailing list >>>> [hidden email] >>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >> >> >> _______________________________________________ >> Cuis mailing list >> [hidden email] >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Use of #deprecated: and/or #deprecatedExplanation:
|
|
On 28 December 2013 11:46, Casey Ransberger <[hidden email]> wrote:
> Ah, okay, Squeak does it too then. > > So, the question is, do we need this sort of thing in Cuis? Because nothing says deprecated quite like MessageNotUnderstood :D > > Anyhow it seems to me the reason you'd want this behavior is to let people know to stop using stuff that's present temporarily for back compat, or I suppose maybe to inform #unloadAllKnownPackages that the deprecated stuff can go? That's exactly why we have deprecation warnings in Squeak. The plan is that 4.5 holds things deprecated in 4.4, and then in 4.6 we dump those (but keep things deprecated in 4.5), and so on. frank > Since back compat isn't a strong goal in Cuis, and we're more generally just inclined to rip stuff that isn't absolutely required out, I'd argue that we don't really need this. > > Counter arguments? > > --C > >> On Dec 28, 2013, at 3:18 AM, Frank Shearar <[hidden email]> wrote: >> >> That's how they work in Squeak too: Deprecation below is a resumable >> Notification: >> >> Object >> deprecated: anExplanationString >> "Warn that the sending method has been deprecated." >> >> Preferences showDeprecationWarnings ifTrue: >> [Deprecation signal: thisContext sender printString, ' has >> been deprecated. ', anExplanationString] >> >> >> Typically used like this: >> >> Behavior >> compile: code classified: category notifying: requestor >> trailer: bytes ifFail: failBlock >> self deprecated: 'Use #compile:notifying:trailer:ifFail:'. >> ^self compile: code notifying: requestor trailer: bytes ifFail: failBlock >> >> frank >> >>> On 28 December 2013 02:19, Casey Ransberger <[hidden email]> wrote: >>> Juan: I believe in Pharo they have deprecation warnings. There's a >>> preference to turn them off, and IIRC the first time you hit a deprecated >>> method with them enabled, the system complains (can't remember if it's a >>> dialog or a debugger or what.) >>> >>> >>> On Fri, Dec 27, 2013 at 6:17 PM, Casey Ransberger <[hidden email]> >>> wrote: >>>> >>>> When I do this, I usually do something like >>>> >>>> self flag: #foo. "Need to remember to take care of foo. --cbr" >>>> >>>> Main point of saying this is, it's nice to have a comment by the flag so >>>> when know who raised it and why. >>>> >>>> >>>>> On Fri, Dec 27, 2013 at 2:24 PM, Juan Vuletich <[hidden email]> wrote: >>>>> >>>>> On 12/27/2013 3:24 PM, Germán Arduino wrote: >>>>> >>>>> Hi: >>>>> >>>>> In Squeak was common the use of #deprecatedExplanation: and also >>>>> #deprecate: >>>>> >>>>> These methods are not present in Cuis, I'm interested in learn how manage >>>>> the ports of packages that use de deprecation messages. It's a good practice >>>>> use, for example, "self flag: 'comment'"? >>>>> >>>>> Thanks. >>>>> >>>>> -- >>>>> Saludos / Regards, >>>>> Germán Arduino >>>>> www.arduinosoftware.com >>>>> >>>>> >>>>> We don't have a specific good practice for that... yet. What is the idea? >>>>> To let package users know that that method should not be used? What does >>>>> that method do in Squeak? >>>>> >>>>> Cheers, >>>>> Juan Vuletich >>>>> >>>>> _______________________________________________ >>>>> Cuis mailing list >>>>> [hidden email] >>>>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >>> >>> >>> _______________________________________________ >>> Cuis mailing list >>> [hidden email] >>> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org >> >> _______________________________________________ >> Cuis mailing list >> [hidden email] >> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
In reply to this post by Casey Ransberger-2
On Sat, 28 Dec 2013 03:46:33 -0800
Casey Ransberger <[hidden email]> wrote: > Since back compat isn't a strong goal in Cuis, and we're more generally just inclined to rip stuff that isn't absolutely required out, I'd argue that we don't really need this. Not only that, but you can specify a requirement for an older version and a revision range where things do work. Since this includes the base image, we can still safely share packages. One of the motivations for both Cuis and Pharo to drop backward compatibility is to lessen the drag on forward progress. Cuis (Comprehensible Uniform Incremental Simple :^) into conciseness and scalable Morphic(3) and Pharo into professional, systematically rational introspective tools. It is good not to create arbitrary differences in dialect and to be conscious of where others are different and why, but the joy of evolution has its own imperative. Useful aspects can be imaginatively created in any dialect and if really useful and not discordant will be picked up by others as makes sense. But we must be free to experiment with new viewpoints. I am basically a bottom-up tinkerer and incrementalist. Some people can conceive of the grand plan, plan out the details, and just build it. One of the joys of Smalltalk is the ability to aim for a direction, explore and try out a bunch of solutions and evolve toward goals rather than having to pre-plan and build toward goals. For me it has to be simple enough to play around, have fun, learn, and produce things I think beautiful, or at least pretty. I hope my code will be useful, but if it is not fun I will not get there. Anyway, I depricate #depricated. $0.02, -KenD _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
-KenD
|
|
|
I saw the use in the way, for example: drawAxis: aBoolean self deprecatedExplanation: 'use #shouldDrawAxis: instead'.
self shouldDrawAxis: aBoolean but nothing that can not be replaced by a comment, imho. 2013/12/28 Ken Dickey <[hidden email]>
Saludos / Regards,
Germán Arduino www.arduinosoftware.com _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Use of #deprecated: and/or #deprecatedExplanation:
|
|
On 12/28/2013 3:35 PM, Germán Arduino wrote:
But only if you see some value in those methods. Otherwise, just nuke them! It is the best way to be sure nobody will use them :) Cheers, Juan Vuletich
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Use of #deprecated: and/or #deprecatedExplanation:
|
|
In reply to this post by Casey Ransberger-2
On 12/27/2013 11:19 PM, Casey Ransberger wrote:
I know. But the point is, given that we don't do that in the base image, do we need to do it in external packages? Cheers, Juan Vuletich
_______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
Re: Use of #deprecated: and/or #deprecatedExplanation:
|
|
In reply to this post by KenDickey
On 12/28/2013 2:31 PM, Ken Dickey wrote:
> On Sat, 28 Dec 2013 03:46:33 -0800 > Casey Ransberger<[hidden email]> wrote: > >> Since back compat isn't a strong goal in Cuis, and we're more generally just inclined to rip stuff that isn't absolutely required out, I'd argue that we don't really need this. > Not only that, but you can specify a requirement for an older version and a revision range where things do work. Since this includes the base image, we can still safely share packages. > > One of the motivations for both Cuis and Pharo to drop backward compatibility is to lessen the drag on forward progress. Cuis (Comprehensible Uniform Incremental Simple :^) into conciseness and scalable Morphic(3) and Pharo into professional, systematically rational introspective tools. :) > It is good not to create arbitrary differences in dialect and to be conscious of where others are different and why, but the joy of evolution has its own imperative. Useful aspects can be imaginatively created in any dialect and if really useful and not discordant will be picked up by others as makes sense. But we must be free to experiment with new viewpoints. > > I am basically a bottom-up tinkerer and incrementalist. Some people can conceive of the grand plan, plan out the details, and just build it. One of the joys of Smalltalk is the ability to aim for a direction, explore and try out a bunch of solutions and evolve toward goals rather than having to pre-plan and build toward goals. Yes! > For me it has to be simple enough to play around, have fun, learn, and produce things I think beautiful, or at least pretty. I hope my code will be useful, but if it is not fun I will not get there. Same here. > Anyway, I depricate #depricated. Agreed. > $0.02, > -KenD > > _______________________________________________ > Cuis mailing list > [hidden email] > http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org Cheers, Juan Vuletich _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
|
|
In reply to this post by Juan Vuletich-4
2013/12/28 Juan Vuletich <[hidden email]>
Not :) _______________________________________________ Cuis mailing list [hidden email] http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org |
«
Return to Cuis Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |