Hi!
With Ben we were wandering the reason why the special objects array points to the association #Processor->Processor, and not directly to the Processor object.
TIA, Guille & Ben
Doesn't it enable creation of a new Processor ?
Nicolas
2012/5/30 Guillermo Polito guillermopolito@gmail.com:
Hi!
With Ben we were wandering the reason why the special objects array points to the association #Processor->Processor, and not directly to the Processor object.
TIA, Guille & Ben
On 30 May 2012 18:32, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Doesn't it enable creation of a new Processor ?
right. it is to late-bound i think, so when you redefine the Processor class, you can plug a new processor.. still i think you must do it with precaution anyways.
Nicolas
2012/5/30 Guillermo Polito guillermopolito@gmail.com:
Hi!
With Ben we were wandering the reason why the special objects array points to the association #Processor->Processor, and not directly to the Processor object.
TIA, Guille & Ben
On Wed, May 30, 2012 at 6:32 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Doesn't it enable creation of a new Processor ?
Maybe (not sure about this), but why does this design decision apply for this object only? Because for other objects I have to recreate the complete array :/.
Nicolas
2012/5/30 Guillermo Polito guillermopolito@gmail.com:
Hi!
With Ben we were wandering the reason why the special objects array
points to the association #Processor->Processor, and not directly to the Processor object.
TIA, Guille & Ben
On 30 May 2012 18:42, Guillermo Polito guillermopolito@gmail.com wrote:
On Wed, May 30, 2012 at 6:32 PM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Doesn't it enable creation of a new Processor ?
Maybe (not sure about this), but why does this design decision apply for this object only?
Because! :) Hell i know why.. a proper answer would probably be that different parts are done at different time by different people without good communication &/ striving for unified interfaces.
Because for other objects I have to recreate the complete array :/.
Nicolas
2012/5/30 Guillermo Polito guillermopolito@gmail.com:
Hi!
With Ben we were wandering the reason why the special objects array points to the association #Processor->Processor, and not directly to the Processor object.
TIA, Guille & Ben
On Wed, May 30, 2012 at 7:25 PM, Igor Stasenko siguctua@gmail.com wrote:
On 30 May 2012 18:42, Guillermo Polito guillermopolito@gmail.com wrote:
On Wed, May 30, 2012 at 6:32 PM, Nicolas Cellier <
nicolas.cellier.aka.nice@gmail.com> wrote:
Doesn't it enable creation of a new Processor ?
Maybe (not sure about this), but why does this design decision apply for
this object only?
Because! :) Hell i know why.. a proper answer would probably be that different parts are done at different time by different people without good communication &/ striving for unified interfaces.
That's a good enough reason :).
Thanks to all!
Because for other objects I have to recreate the complete array :/.
Nicolas
2012/5/30 Guillermo Polito guillermopolito@gmail.com:
Hi!
With Ben we were wandering the reason why the special objects array
points to the association #Processor->Processor, and not directly to the Processor object.
TIA, Guille & Ben
-- Best regards, Igor Stasenko.
On Wed, May 30, 2012 at 9:30 AM, Guillermo Polito <guillermopolito@gmail.com
wrote:
Hi!
With Ben we were wandering the reason why the special objects array points to the association #Processor->Processor, and not directly to the Processor object.
TIA, Guille & Ben
By the way, VisualWorks changed this to be a direct reference to the Processor object, so in VisualWorks you have to use a become: to change the processor.
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda -
Guillermo Polito -
Igor Stasenko -
Nicolas Cellier