RB bug

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

RB bug

Toon Verwaest
If I want to create a new namespace and in that new namespace a new
class which has a still unexisting superclass, the system does some
magic but at some point tries to get the real namespace of the yet
unexisting namespace which obviously failes. This happens in
RBBasicNamespace>>nameSpaceFor: at line 5 (returns self if true).
However; if it would succeed it would return false and the rest of the
code would actually work.

As a fix I changed the realNamespace implementation to

realNameSpace
  | realItem |
  realItem := self realItem.
  realItem ifNil: [ ^nil ].
  ^ realItem asNameSpace

Like this everything works nicely again...

Reply | Threaded
Open this post in threaded view
|

Re: RB bug

Toon Verwaest
Again on the [RB], is there a way of ordering the changes so that they
are ensured to be applicable? Or do I need to generate my changes
myself in a certain order. I am talking here about generating classes
which subclass from each other. The RB should be able to detect this
order itself easily enough. However, the RB in the current VW seems to
rely on the order of input received. It seems useless to order this
myself since it is a general RB problem to tackle.

cheers,
Toon

Reply | Threaded
Open this post in threaded view
|

Re: RB bug

Travis Griggs-3

On Jan 10, 2008, at 8:05 AM, Toon Verwaest wrote:

> Again on the [RB], is there a way of ordering the changes so that they
> are ensured to be applicable? Or do I need to generate my changes
> myself in a certain order. I am talking here about generating classes
> which subclass from each other. The RB should be able to detect this
> order itself easily enough. However, the RB in the current VW seems to
> rely on the order of input received. It seems useless to order this
> myself since it is a general RB problem to tackle.


The RB change model just does what you tell it to, in the order you  
tell it to. Different clients tell it to do different things, and  
specify the order. These "clients" are typically refactorings. For  
example, an rename method knows that it first makes a duplicate of the  
method, then rewrites all call sites, and finally removes the  
original. This allows the system to stay running while the refactoring  
is taking place. The logic for the order is in the refactoring though.

--
Travis Griggs
Objologist
"Only one thing is impossible for God: to find any sense in any  
copyright law on the planet." - Mark Twain