[Pharo-dev] Fogbugz admin - please add Pharo 7 milestone

Just taking a browse through open tickets for Pharo 6, and maybe some can be bumped to Pharo 7 (rather than just "Later"). Could we have a Fogbugz milestone for it? cheers -ben

Re: [Pharo-dev] How to report website text bugs?

On Thu, Dec 1, 2016 at 2:21 PM, Nicolai Hess wrote: > Am 01.12.2016 12:30 vorm. schrieb "Ben Coman" : >> >> On Wed, Nov 30, 2016 at 7:37 PM, Henrik Nergaard >> wrote: >> > SystemNavigation new allLocalCallsOn: 'No change'

Re: [Pharo-dev] Generate accessors refactoring

How about mostly keeping the existing behaviour, but default to collisions being deselected? Then at least you don't need to search for it. It minimises the chance of missing it by mistake. The deselected item easily stands out to be reselected if required. P.S. An additional side idea: If

Re: [Pharo-dev] Generate accessors refactoring

That isn’t a refactoring. The existing methods aren’t accessors. The refactoring will find accessors for the variables if they exist (even if they have a different names). We all know what is refactoring. Usually we don't care about safe aspect of it (and we have tests). We just want

Re: [Pharo-dev] Generate accessors refactoring

> On Dec 6, 2016, at 10:53 AM, Denis Kudriashov wrote: > > > 2016-12-06 17:16 GMT+01:00 John Brant : > > For me it is too intelligent now because it is tried to create new version > > of accessors instead of existing one. > > But simple logic

Re: [Pharo-dev] Generate accessors refactoring

2016-12-06 17:53 GMT+01:00 Denis Kudriashov : > > 2016-12-06 17:16 GMT+01:00 John Brant : > >> > For me it is too intelligent now because it is tried to create new >> version of accessors instead of existing one. >> > But simple logic should just

Re: [Pharo-dev] Generate accessors refactoring

2016-12-06 17:16 GMT+01:00 John Brant : > > > On Dec 6, 2016, at 8:25 AM, Denis Kudriashov > wrote: > > > > > > 2016-12-06 15:09 GMT+01:00 Yuriy Tymchuk : > > It shouldn’t be too intelligent. Keep the default behavior, and

Re: [Pharo-dev] Generate accessors refactoring

For me it is too intelligent now because it is tried to create new version of accessors instead of existing one. But simple logic should just analyze method name and if accessor already exists it should skip it That isn’t a refactoring. The existing methods aren’t accessors. The

Re: [Pharo-dev] Generate accessors refactoring

2016-12-06 17:16 GMT+01:00 John Brant : > > For me it is too intelligent now because it is tried to create new > version of accessors instead of existing one. > > But simple logic should just analyze method name and if accessor already > exists it should skip it > >

Re: [Pharo-dev] Generate accessors refactoring

> On Dec 6, 2016, at 8:25 AM, Denis Kudriashov wrote: > > > 2016-12-06 15:09 GMT+01:00 Yuriy Tymchuk : > It shouldn’t be too intelligent. Keep the default behavior, and for each > method add a 3-state checkbox: create (default), skip, force

[Pharo-dev] [pharo-project/pharo-core] 55be1a: 60318

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 55be1a1eac6fb945dfa11771de5fcbb523f56034 https://github.com/pharo-project/pharo-core/commit/55be1a1eac6fb945dfa11771de5fcbb523f56034 Author: Jenkins Build Server Date:

[Pharo-dev] [pharo-project/pharo-core]

Branch: refs/tags/60318 Home: https://github.com/pharo-project/pharo-core

Re: [Pharo-dev] Generate accessors refactoring

2016-12-06 15:09 GMT+01:00 Yuriy Tymchuk : > It shouldn’t be too intelligent. Keep the default behavior, and for each > method add a 3-state checkbox: create (default), skip, force (override). > Also having a usage recorder would be nice to know if developers are > actually

Re: [Pharo-dev] Generate accessors refactoring

It shouldn’t be too intelligent. Keep the default behavior, and for each method add a 3-state checkbox: create (default), skip, force (override). Also having a usage recorder would be nice to know if developers are actually checking the other state more often than the default one. Uko > On 6

Re: [Pharo-dev] OCASTTranslator forValue/forEffect

> >> >> @Marcus, >> can we *always* use the valueTranslator when visiting a link preamble ? >> (I tried this, the above method now works, and all tests are green, but I am >> not sure if this is the right solution). >> > > Yes, I think so. The idea is that the preamble is just about stack >

Re: [Pharo-dev] Generate accessors refactoring

2016-12-06 11:34 GMT+01:00 Denis Kudriashov : > > 2016-12-06 11:28 GMT+01:00 Yuriy Tymchuk : > >> Additionally it was annoying if a superclass has a method with the same >> name. For example if you have a name var and you create accessors I’d like >> to

Re: [Pharo-dev] Generate accessors refactoring

2016-12-06 11:28 GMT+01:00 Yuriy Tymchuk : > Additionally it was annoying if a superclass has a method with the same > name. For example if you have a name var and you create accessors I’d like > to have actually a ’name’ getter and not ’name1’ Yes

Re: [Pharo-dev] Generate accessors refactoring

Additionally it was annoying if a superclass has a method with the same name. For example if you have a name var and you create accessors I’d like to have actually a ’name’ getter and not ’name1’ Uko > On 6 Dec 2016, at 11:16, Nicolai Hess wrote: > > > > 2016-12-06

Re: [Pharo-dev] Generate accessors refactoring

2016-12-06 11:09 GMT+01:00 Denis Kudriashov : > Hi. > > There is very annoying logic of accessors refactoring. > For example imaging your class already has getter for variable #myInstVar > but with some extra code instead of simple return. For example it could be > lazy

Re: [Pharo-dev] Generate accessors refactoring

+1 super annoying! On Dec 6, 2016 11:10, "Denis Kudriashov" wrote: > Hi. > > There is very annoying logic of accessors refactoring. > For example imaging your class already has getter for variable #myInstVar > but with some extra code instead of simple return. For example

[Pharo-dev] Generate accessors refactoring

Hi. There is very annoying logic of accessors refactoring. For example imaging your class already has getter for variable #myInstVar but with some extra code instead of simple return. For example it could be lazy initialization: MyClass>>myInstVar ^myInstVar ifNil: [#someValue] In that