Nachricht
When a top-level
namespace (f.ex. Smalltalk.A) contains a class with the same name (f.ex.
Smalltalk.A.A), tools based on refactoring changes are
broken:
Class definition
wizard, namespace definition wizard (probably more).
Steps to
reproduce:
1. open vanilla
visual.im, open Browser and select package (none)
2. define namespace
A in namespace Smalltalk (using the tool or directly)
3. define a class A
in namespace Smalltalk.A (using the tool or directly)
4. define a new
class B (or whatever) in namespace Smalltalk.A using the tool ==>
MNU
Problem: the class
definition message to create the class is wrong, because it confuses the
namespace with the class:
^A
defineClass:
#B
superclass: #{Core.Object}
indexedType:
#none
private: false
instanceVariableNames:
''
classInstanceVariableNames: ''
imports:
''
category: #'(none)'
the right one would
be:
^Smalltalk.A
defineClass:
#B
superclass: #{Core.Object}
indexedType:
#none
private: false
instanceVariableNames:
''
classInstanceVariableNames: ''
imports:
''
category: #'(none)'
This behavior is
new in 7.4.1. It happens only with top-level namespaces (i.e. defining class
Smalltalk.A.B.B is fine).
The responsible
change is in [Browser-ChangeObjects]
Refactory.Browser.ExecuteCodeChange>>primitiveExecute.
Instead of using
Smalltalk as environment for compilation, it now uses the namespace of the class
to be defined. That would be OK, if the definition (the source to be compiled)
would have the fully specified name of the namespace (including 'Smalltalk.'),
but it doesnt.
Solution:
I could override
Refactory.Browser.ExecuteCodeChange>>primitiveExecute with its old
version... (I hate this kind of overrides).
Or I could rename
all my classes which have the same name as the namespace - I dislike this even
more.
Defining shared
variables via tool works - maybe there are the right changes which were
forgotten to apply to the class and namespace definition
changes?
Other
ideas?
Cheers,
Christian
Locked
