On Sun, Dec 29, 2013 at 4:15 PM, commits@source.squeak.org wrote:
Item was changed:
----- Method: Environment>>at:ifAbsentPut: (in category 'emulating')
at: aSymbol ifAbsentPut: aBlock
^declarations
^ declarations at: aSymbol
ifAbsent: [ self at: aSymbol put: aBlock value ]!
ifAbsentPut: aBlock!
Yup. We want to make use of the new become logic in #at:put: here too...
Item was changed:
----- Method: Environment>>at:put: (in category 'emulating') ----- at: aSymbol put: anObject
| binding newBinding |
newBinding := aSymbol => anObject.
binding := declarations associationAt: aSymbol ifAbsent: [ nil ].
binding ifNotNil: [
binding class == newBinding class
ifTrue: [ binding value: anObject ]
ifFalse: [ binding becomeForward: newBinding ].
^anObject ].
binding := undeclared associationAt: aSymbol ifAbsent: [ nil ].
binding
ifNil: [ binding := newBinding ]
ifNotNil: [
undeclared removeKey: aSymbol.
binding class == newBinding class
ifTrue: [ binding value: anObject ]
ifFalse: [ binding becomeForward:
newBinding ] ].
declarations add: binding.
+ references add: binding.
I think the above line is problematic. It by by-passes all the import/export logic.
+ exports bind: binding. "Do we really want this?"
Yes.
+ ^anObject
Item was changed:
----- Method: Environment>>removeKey:ifAbsent: (in category 'emulating')
removeKey: key ifAbsent: aBlock
(declarations includesKey: key) ifFalse: [ ^aBlock value ].
references removeKey: key ifAbsent: [].
Again, the above line by-passes all the import/export logic.
Colin
On Mon, 30 Dec 2013, Colin Putney wrote:
On Sun, Dec 29, 2013 at 4:15 PM, commits@source.squeak.org wrote:
Item was changed: ----- Method: Environment>>at:ifAbsentPut: (in category 'emulating') ----- at: aSymbol ifAbsentPut: aBlock + + ^declarations - ^ declarations at: aSymbol + ifAbsent: [ self at: aSymbol put: aBlock value ]! - ifAbsentPut: aBlock!
Yup. We want to make use of the new become logic in #at:put: here too...
Item was changed: ----- Method: Environment>>at:put: (in category 'emulating') ----- at: aSymbol put: anObject + + | binding newBinding | + newBinding := aSymbol => anObject. + binding := declarations associationAt: aSymbol ifAbsent: [ nil ]. + binding ifNotNil: [ + binding class == newBinding class + ifTrue: [ binding value: anObject ] + ifFalse: [ binding becomeForward: newBinding ]. + ^anObject ]. + binding := undeclared associationAt: aSymbol ifAbsent: [ nil ]. + binding + ifNil: [ binding := newBinding ] + ifNotNil: [ + undeclared removeKey: aSymbol. + binding class == newBinding class + ifTrue: [ binding value: anObject ] + ifFalse: [ binding becomeForward: newBinding ] ]. + declarations add: binding. + references add: binding.
I think the above line is problematic. It by by-passes all the import/export logic.
You're right, but this is somewhat intentional. Or do you want an imported class to shadow a class defined in your environment?
+ exports bind: binding. "Do we really want this?"
Yes.
+ ^anObject Item was changed: ----- Method: Environment>>removeKey:ifAbsent: (in category 'emulating') ----- removeKey: key ifAbsent: aBlock + + (declarations includesKey: key) ifFalse: [ ^aBlock value ]. + references removeKey: key ifAbsent: [].
Again, the above line by-passes all the import/export logic.
Right.
Levente
Colin
On Mon, Dec 30, 2013 at 11:49 AM, Levente Uzonyi leves@elte.hu wrote:
I think the above line is problematic. It by by-passes all the import/export logic.
You're right, but this is somewhat intentional. Or do you want an imported class to shadow a class defined in your environment?
Yes, if that's the way you've set up your imports.
See http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-December/175497....
On Mon, 30 Dec 2013, Colin Putney wrote:
On Mon, Dec 30, 2013 at 11:49 AM, Levente Uzonyi leves@elte.hu wrote: I think the above line is problematic. It by by-passes all the import/export logic.
You're right, but this is somewhat intentional. Or do you want an imported class to shadow a class defined in your environment?
Yes, if that's the way you've set up your imports.
See http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-December/175497....
In that case class renaming will have to be reviewed. If I have an environment E with a class C, but I've imported the environment IE, which also has a class C, and the C from IE shadows the C from E, then either we shouldn't allow renaming C from E, or we should change the renaming code to not modify references in E in this case.
Levente
On Mon, Dec 30, 2013 at 12:20 PM, Levente Uzonyi leves@elte.hu wrote:
In that case class renaming will have to be reviewed. If I have an environment E with a class C, but I've imported the environment IE, which also has a class C, and the C from IE shadows the C from E, then either we shouldn't allow renaming C from E, or we should change the renaming code to not modify references in E in this case.
Yeah. That's actually a special case of the more general problem of adding or removing bindings during development. If you removed C from IE, then suddenly the C in E becomes visible, and methods compiled in E should be rebound. It's something that should be handled at the tools level rather than down in the guts of Environment. Per Tim's suggestion, we can throw notifications when this happens, and leave it up to the tools, load-script or whatever to deal with them.
One way we might handle it at the tools level is to have a conflict browser. It would show names which have more than one binding in a given environment, and the classes/globals they could be bound to. There would be commands for choosing which one to expose to your environment, and would automatically rejigger the imports to make that happen.
Similarly, the "references to it" browser should pay attention to the actual value being bound, rather than name it's bound to, or the actual binding in the CompiledMethod.
Colin
squeak-dev@lists.squeakfoundation.org