Re: [Pharo-dev] Why was #asLegalSelector removed?

[stepharo]

Le 20/2/15 15:59, Sean P. DeNigris a écrit :

As you know, I love cleaning ;)

But...


stepharo wrote

https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/StringCleaning.md

What enlightenment am I supposed to gain from "candidates for removal...
asLegalSelector", and later "Done: candidates for removal...
asLegalSelector". I still understand nothing of the rationale.
Yes we are poor are documenting such decision. But if to remove a bad 
method it takes 5 times more energy than

removing it then we will never make progress.

This code is bogus and shitty.

And useful ;) (as evidenced by this thread). Okay, it's limited, but what's
better - having users roll their own every time?


Probably and I'm not provocating.


For now, I'll package it with my code, but I think we should add it back,
maybe with a method comment to clarify that it creates a unary selector
only...

Bring back #asLegalSelector
https://pharo.fogbugz.com/default.asp?14969
Fix in inbox: SLICE-Issue-14969-Bring-back-asLegalSelector-SeanDeNigris.1

I think that this is better that you package it with your app. I do not 
see the point to have

this method fromGarbageToUnarySelector in String.


Stef

Re: [Pharo-dev] Why was #asLegalSelector removed?

[Sean P. DeNigris]

stepharo wrote
> I prefer to die because I have moved than because I feared to move because
> at the end I will die.

Perfectly said :)



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Why-was-asLegalSelector-removed-tp4806427p4806745.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Why was #asLegalSelector removed?

[stepharo]

Damien
I decided that living is about mistakes so I will not stress and 
continue to improve the platform.

And from time to time I will do a mistake and we will fix it.
I prefer to die because I have moved than because I feared to move 
because at the end I will die.


Stef

Le 19/2/15 18:43, Damien Pollet a écrit :
I'm usually extremely apprehensive of changing code I don't own, to 
the point I — sadly — contribute nearly nothing to Pharo. Now, 
cleaning the platform — and in this case, by cleaning, I really mean 
hazmat suits, industrial grade acid, and flame throwers — is going to 
break things. I'm all for a process to help others follow such 
changes, but if we want a process to work, it has to be even simpler 
than not having a process. In any case I don't want to have to stress 
over touching platform code.


I think it would make sense to publish a configuration for 
DeprecationFinder in the configuration browser. Does it work on any 
Pharo image, or is it written on top of Moose ?


About #asComment : since class comments are free text, any string will 
do and there is no escapement sequences to enforce. Maybe ideally we 
would have string un/escaper objects responsible for translating 
between free text and and specific encodings (comments, strings, 
regexes, URLs…)


On 19 February 2015 at 15:05, stephan > wrote:


The way this was handled can be improved. It is sometimes
difficult for us not in Lille
to find out what is going on.

- a specific issue name helps us notice what changes
- check where code is used. DeprecationFinder works for that
  (and should add more repos and team projects).

And a specific one: the rename from #asSmalltalkComment
to #asComment is problematic. There are 2 kinds of thing
casually known as comments: the comment text in a method,
and the class comment.  The method name should reflect that.

Stephan




--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Re: [Pharo-dev] Why was #asLegalSelector removed?

[Sean P. DeNigris]

As you know, I love cleaning ;)

But...


stepharo wrote
> https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/StringCleaning.md

What enlightenment am I supposed to gain from "candidates for removal...
asLegalSelector", and later "Done: candidates for removal...
asLegalSelector". I still understand nothing of the rationale.


stepharo wrote
> This code is bogus and shitty.

And useful ;) (as evidenced by this thread). Okay, it's limited, but what's
better - having users roll their own every time?

For now, I'll package it with my code, but I think we should add it back,
maybe with a method comment to clarify that it creates a unary selector
only...

Bring back #asLegalSelector
https://pharo.fogbugz.com/default.asp?14969
Fix in inbox: SLICE-Issue-14969-Bring-back-asLegalSelector-SeanDeNigris.1



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Why-was-asLegalSelector-removed-tp4806427p4806671.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Why was #asLegalSelector removed?

[Stephan Eggermont]

On 19/02/15 18:43, Damien Pollet wrote:

I think it would make sense to publish a configuration for
DeprecationFinder in the configuration browser. Does it work on any
Pharo image, or is it written on top of Moose ?


I'm trying to see if it still runs atm. Looking good in a
Moose 5.1. 50 MB of package cache, 1250 monticello packages
and counting. Hmm, found a bug in MooseMonticelloHTTPImporter.
VHDL-cipt.24.mcz has a method name ending in _class
and that confuse resolveInstanceSide: aNamedEntity

I deliberately didn't put this in the configuration browser
as running this code without the delay in getAllFrom:thenDo:
performs a DOS attack. It also takes a lot of time to run,
getting all packages and just creates a data structure
that is easy to inspect.

DeprecationFinder default findAllUsers

just starts downloading and parsing everything. I never
bothered creating a UI, as the GTInspector is
good enough.

Stephan

Re: [Pharo-dev] Why was #asLegalSelector removed?

[Damien Pollet]

I'm usually extremely apprehensive of changing code I don't own, to the
point I — sadly — contribute nearly nothing to Pharo. Now, cleaning the
platform — and in this case, by cleaning, I really mean hazmat suits,
industrial grade acid, and flame throwers — is going to break things. I'm
all for a process to help others follow such changes, but if we want a
process to work, it has to be even simpler than not having a process. In
any case I don't want to have to stress over touching platform code.

I think it would make sense to publish a configuration for
DeprecationFinder in the configuration browser. Does it work on any Pharo
image, or is it written on top of Moose ?

About #asComment : since class comments are free text, any string will do
and there is no escapement sequences to enforce. Maybe ideally we would
have string un/escaper objects responsible for translating between free
text and and specific encodings (comments, strings, regexes, URLs…)

On 19 February 2015 at 15:05, stephan  wrote:

> The way this was handled can be improved. It is sometimes difficult for us
> not in Lille
> to find out what is going on.
>
> - a specific issue name helps us notice what changes
> - check where code is used. DeprecationFinder works for that
>   (and should add more repos and team projects).
>
> And a specific one: the rename from #asSmalltalkComment
> to #asComment is problematic. There are 2 kinds of thing
> casually known as comments: the comment text in a method,
> and the class comment.  The method name should reflect that.
>
> Stephan
>
>


-- 
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Re: [Pharo-dev] Why was #asLegalSelector removed?

[stephan]

The way this was handled can be improved. It is sometimes difficult for 
us not in Lille

to find out what is going on.

- a specific issue name helps us notice what changes
- check where code is used. DeprecationFinder works for that
  (and should add more repos and team projects).

And a specific one: the rename from #asSmalltalkComment
to #asComment is problematic. There are 2 kinds of thing
casually known as comments: the comment text in a method,
and the class comment.  The method name should reflect that.

Stephan

Re: [Pharo-dev] Why was #asLegalSelector removed?

[stepharo]

Because we were analysing the string API and trying to clean it.
Now this analysis is publicly available on

https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/StringCleaning.md

Now I'm quite sure that I do not want to get such behavior into string: 
why string is responsible to convert junk

into a "selector" which cannot even accept the fact that it could need a :

This code is bogus and shitty.

Stef


asLegalSelector
"'234znak 43 ) 2' asLegalSelector2"

| toUse |
 toUse := self select: [:char | char isAlphaNumeric].
(toUse size = 0 or: [ toUse first isLetter not ])
ifTrue: [ toUse := 'v', toUse ].
^ toUse withFirstCharacterDownshifted




As mentioned in Stephan's recent comment in
https://pharo.fogbugz.com/default.asp?13754 , some of us were using it. What
was the rationale? Maybe removing methods warrants a discussion on the list?
How about deprecations?



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Why-was-asLegalSelector-removed-tp4806427.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] Why was #asLegalSelector removed?

[Sean P. DeNigris]

As mentioned in Stephan's recent comment in
https://pharo.fogbugz.com/default.asp?13754 , some of us were using it. What
was the rationale? Maybe removing methods warrants a discussion on the list?
How about deprecations?



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Why-was-asLegalSelector-removed-tp4806427.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.