- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] RPackageOrganizer >> unregisterPackageNamed:

by Esteban Lorenzano

package management and classes are orthogonal: you can have a class in the system outside the package structure. so yes.. removing a class from system will certainly remove them from package structureâ¦ but not the opposite: unregistering a package is just that: unregistering a package (the classes will remain). rpackage api needs to be revisited (yet once again) un pharo4â¦ but for now, is like that :) Esteban On 18 Mar 2014, at 18:34, Ben Coman <btc(a)openinworld.com> wrote: > RPackageOrganizer has protocol 'public registration' with methods: #registerPackageNamed: and #unregisterPackageNamed: > > So I presume I am free to evaluate the following as separate steps)... > > 1. RPackageOrganizer default registerPackageNamed: 'MyTest'. > "-->package is created okay" > > 2. Object subclass: #MyTestClass > instanceVariableNames: '' > classVariableNames: '' > category: 'MyTest'. > "-->class is created okay" > > 3. RPackageOrganizer default unregisterPackageNamed: 'MyTest'. > "-->package disappears okay" > > 4. RPackageOrganizer default registerPackageNamed: 'MyTest'. > "-->package created okay" > > 5. Object subclass: #MyTestClass > instanceVariableNames: '' > classVariableNames: '' > category: 'MyTest'. > "-->class does not appear" > > However if I go... > 6a. Smalltalk removeKey: #MyTestClass . > > 6b. Object subclass: #MyTestClass > instanceVariableNames: '' > classVariableNames: '' > category: 'MyTest'. > > "-->then the class does appear" > > Should I need to be cleaning up manually per step 6a? > > cheers -ben >

March 18, 2014

Re: [Pharo-dev] Just found, i can compile this:

by ClÃ©ment Bera

2014-03-18 18:31 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > > On 18.03.2014, at 18:17, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > > On 18 mars 2014, at 17:02, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hello, > > For blockClosures it is normal, block closure arguments have always been > assignable since smalltalk-80. > > > I never noticed, that's a weird 'feature'. > > We could add a warning to discourage it, but we cannot forbid it, or we > will not be able to load lots of frameworks and libraries that use it. So > 12419 <https://pharo.fogbugz.com/default.asp?12419> is not a bug to me, > it's a feature. > > > You mean that there exist code out there that rely on being able to store > in an argument? > > Yes there are code like that, we encountered them in Opal's regression tests (I don't remember exactly but they are in Pharo, Moose or/and seaside). As Christophe said, arguments are temporary variables with an initial value for block closures (and right now for methods too, but it's a officially bug). Perhaps it is not a bug to allow that for methods. It's another feature. The expected behavior is the same as block closures: MyClass>>foo | t | (self example: t) logCr. ^ t MyClass>>example: arg arg := 1. ^ arg When evaluating MyClass new foo, 1 is logged on the transcript but the return value is nil, because an argument is a temporary variable with an initial value. On the bug tracker we noted to add a setting for these cases. That's the solution anyway... > Always assume the worst case scenario :p > > > > For methods it is a bug, thanks for noticing. I will check. > > > > > 2014-03-18 15:45 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > >> similiar to issue 12419 <https://pharo.fogbugz.com/default.asp?12419> >> block arguments should be read only >> >> >> 2014-03-18 15:21 GMT+01:00 Camille Teruel <camille.teruel(a)gmail.com>: >> >> Indeed, I can compile: >>> >>> C>>foo: arg >>> ^ arg := 3 >>> >>> And 'C new foo: 1' returns 3... >>> >>> >>> On 18 mars 2014, at 15:16, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> > extent: newExtent >>> > >>> > vertical >>> > ifTrue: [ newExtent := self defaultWidth @ newExtent y ] >>> > ifFalse: [ newExtent := newExtent x @ self defaultWidth ]. >>> > >>> > super extent: newExtent >>> > >>> > Can you verify it? Arguments should be not assignable. >>> > >>> > -- >>> > Best regards, >>> > Igor Stasenko. >>> >>> >>> >> > > >

March 18, 2014

RPackageOrganizer >> unregisterPackageNamed:

by Ben Coman

RPackageOrganizer has protocol 'public registration' with methods: #registerPackageNamed: and #unregisterPackageNamed: So I presume I am free to evaluate the following as separate steps)... 1. RPackageOrganizer default registerPackageNamed: 'MyTest'. "-->package is created okay" 2. Object subclass: #MyTestClass instanceVariableNames: '' classVariableNames: '' category: 'MyTest'. "-->class is created okay" 3. RPackageOrganizer default unregisterPackageNamed: 'MyTest'. "-->package disappears okay" 4. RPackageOrganizer default registerPackageNamed: 'MyTest'. "-->package created okay" 5. Object subclass: #MyTestClass instanceVariableNames: '' classVariableNames: '' category: 'MyTest'. "-->class does not appear" However if I go... 6a. Smalltalk removeKey: #MyTestClass . 6b. Object subclass: #MyTestClass instanceVariableNames: '' classVariableNames: '' category: 'MyTest'. "-->then the class does appear" Should I need to be cleaning up manually per step 6a? cheers -ben

March 18, 2014

Re: [Pharo-dev] Just found, i can compile this:

by Max Leske

On 18.03.2014, at 18:17, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 18 mars 2014, at 17:02, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> Hello, >> >> For blockClosures it is normal, block closure arguments have always been assignable since smalltalk-80. > > I never noticed, that's a weird 'feature'. > >> We could add a warning to discourage it, but we cannot forbid it, or we will not be able to load lots of frameworks and libraries that use it. So 12419 is not a bug to me, it's a feature. > > You mean that there exist code out there that rely on being able to store in an argument? Always assume the worst case scenario :p > >> >> For methods it is a bug, thanks for noticing. I will check. >> >> >> >> >> 2014-03-18 15:45 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: >> similiar to issue 12419 block arguments should be read only >> >> >> 2014-03-18 15:21 GMT+01:00 Camille Teruel <camille.teruel(a)gmail.com>: >> >> Indeed, I can compile: >> >> C>>foo: arg >> ^ arg := 3 >> >> And 'C new foo: 1' returns 3... >> >> >> On 18 mars 2014, at 15:16, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> > extent: newExtent >> > >> > vertical >> > ifTrue: [ newExtent := self defaultWidth @ newExtent y ] >> > ifFalse: [ newExtent := newExtent x @ self defaultWidth ]. >> > >> > super extent: newExtent >> > >> > Can you verify it? Arguments should be not assignable. >> > >> > -- >> > Best regards, >> > Igor Stasenko. >> >> >> >> >

March 18, 2014

Re: [Pharo-dev] Just found, i can compile this:

by Camille Teruel

On 18 mars 2014, at 17:02, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hello, > > For blockClosures it is normal, block closure arguments have always been assignable since smalltalk-80. I never noticed, that's a weird 'feature'. > We could add a warning to discourage it, but we cannot forbid it, or we will not be able to load lots of frameworks and libraries that use it. So 12419 is not a bug to me, it's a feature. You mean that there exist code out there that rely on being able to store in an argument? > > For methods it is a bug, thanks for noticing. I will check. > > > > > 2014-03-18 15:45 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > similiar to issue 12419 block arguments should be read only > > > 2014-03-18 15:21 GMT+01:00 Camille Teruel <camille.teruel(a)gmail.com>: > > Indeed, I can compile: > > C>>foo: arg > ^ arg := 3 > > And 'C new foo: 1' returns 3... > > > On 18 mars 2014, at 15:16, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > extent: newExtent > > > > vertical > > ifTrue: [ newExtent := self defaultWidth @ newExtent y ] > > ifFalse: [ newExtent := newExtent x @ self defaultWidth ]. > > > > super extent: newExtent > > > > Can you verify it? Arguments should be not assignable. > > > > -- > > Best regards, > > Igor Stasenko. > > > >

March 18, 2014

Re: [Pharo-dev] Just found, i can compile this:

by Christophe Demarey

Why arguments should be read only? They are just temporary variables with an initial value. > 2014-03-18 15:45 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > similiar to issue 12419 block arguments should be read only > > > 2014-03-18 15:21 GMT+01:00 Camille Teruel <camille.teruel(a)gmail.com>: > > Indeed, I can compile: > > C>>foo: arg > ^ arg := 3 > > And 'C new foo: 1' returns 3... > > > On 18 mars 2014, at 15:16, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > extent: newExtent > > > > vertical > > ifTrue: [ newExtent := self defaultWidth @ newExtent y ] > > ifFalse: [ newExtent := newExtent x @ self defaultWidth ]. > > > > super extent: newExtent > > > > Can you verify it? Arguments should be not assignable. > > > > -- > > Best regards, > > Igor Stasenko. > > > >

March 18, 2014

Re: [Pharo-dev] Just found, i can compile this:

by ClÃ©ment Bera

Hello, For blockClosures it is normal, block closure arguments have always been assignable since smalltalk-80. We could add a warning to discourage it, but we cannot forbid it, or we will not be able to load lots of frameworks and libraries that use it. So 12419<https://pharo.fogbugz.com/default.asp?12419> is not a bug to me, it's a feature. For methods it is a bug, thanks for noticing. I will check. 2014-03-18 15:45 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de>: > similiar to issue 12419 <https://pharo.fogbugz.com/default.asp?12419> > block arguments should be read only > > > 2014-03-18 15:21 GMT+01:00 Camille Teruel <camille.teruel(a)gmail.com>: > > Indeed, I can compile: >> >> C>>foo: arg >> ^ arg := 3 >> >> And 'C new foo: 1' returns 3... >> >> >> On 18 mars 2014, at 15:16, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> > extent: newExtent >> > >> > vertical >> > ifTrue: [ newExtent := self defaultWidth @ newExtent y ] >> > ifFalse: [ newExtent := newExtent x @ self defaultWidth ]. >> > >> > super extent: newExtent >> > >> > Can you verify it? Arguments should be not assignable. >> > >> > -- >> > Best regards, >> > Igor Stasenko. >> >> >> >

March 18, 2014

Re: [Pharo-dev] Just found, i can compile this:

by Nicolai Hess

similiar to issue 12419 <https://pharo.fogbugz.com/default.asp?12419> block arguments should be read only 2014-03-18 15:21 GMT+01:00 Camille Teruel <camille.teruel(a)gmail.com>: > Indeed, I can compile: > > C>>foo: arg > ^ arg := 3 > > And 'C new foo: 1' returns 3... > > > On 18 mars 2014, at 15:16, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > extent: newExtent > > > > vertical > > ifTrue: [ newExtent := self defaultWidth @ newExtent y ] > > ifFalse: [ newExtent := newExtent x @ self defaultWidth ]. > > > > super extent: newExtent > > > > Can you verify it? Arguments should be not assignable. > > > > -- > > Best regards, > > Igor Stasenko. > > >

March 18, 2014

Re: [Pharo-dev] Just found, i can compile this:

by Camille Teruel

Indeed, I can compile: C>>foo: arg ^ arg := 3 And 'C new foo: 1' returns 3... On 18 mars 2014, at 15:16, Igor Stasenko <siguctua(a)gmail.com> wrote: > extent: newExtent > > vertical > ifTrue: [ newExtent := self defaultWidth @ newExtent y ] > ifFalse: [ newExtent := newExtent x @ self defaultWidth ]. > > super extent: newExtent > > Can you verify it? Arguments should be not assignable. > > -- > Best regards, > Igor Stasenko.

March 18, 2014

Just found, i can compile this:

by Igor Stasenko

extent: newExtent vertical ifTrue: [ newExtent := self defaultWidth @ newExtent y ] ifFalse: [ newExtent := newExtent x @ self defaultWidth ]. super extent: newExtent Can you verify it? Arguments should be not assignable. -- Best regards, Igor Stasenko.

March 18, 2014