Re: Customize create and probe maps questions

[Roger M. Burkhart]

> Hello,
> I have three questions:
> 
> 1. first one concerns customizeBegin/customizeEnd
> sequence. I wanted to use it to set some features of the
> objects (I have many objects of the type to be created)
> while leaving the rest to be set during initialization
> of the instance (between createBegin and createEnd).
> However, unfortunately, I want  to make some checking if
> the initialization was correct (say if all the required 
> attributes were set) in createEnd method (it seems to be the
> most suitable place). The problem is that createEnd
> is called from customizeEnd - it is certainly
> not the end of initialization and in my case it is an error
> obviously. I have no idea how to pass it by - to be able
> to use both customize methods and to check if initialization
> was done correctly. Do I miss something obvious?

I'm not sure where you're inheriting from, but customizeBegin/customizeEnd
aren't really set up for normal user objects that just inherit from
SwarmObject and don't use the split creating and using phases that the
collections and activity libraries do.  If you want to use them, I'd
recommend you just override all four messages customizeBegin/End
and createBegin/End so that they work correctly together, and not rely
on the createEnd call from customizeEnd.

In the cases where createEnd does support use of customizeEnd (e.g., most
creatable classes in collections and activity), createEnd still does all
its normal final initialization checking, but just before it's about to
return a final initialized object, it makes a special call to indicate
which of several options is to be followed for creating further objects of
the type just initialized.  createEnd then returns to a special context
created earlier by customizeBegin, rather than taking a normal return.
That's the way that createEnd can be called by customizeEnd and still
complete its normal initialization checks.  Perhaps this could all be made
to work for normal subclasses of SwarmObject but no one's attempted that
yet, so far as I know.  The way it's set up now is a bit tricky (to
minimize overhead when createEnd is used outside customizeEnd) and is in
process of changing somewhat, but after it's changed we should resolve all
the subclass contexts in which it can safely be used, and get this
properly documented.

> To be more specific the initialization sequence for the object
> looks then as follows:
> //Customization
>  customizeBegin -> createBegin is invoked
>  customizeEnd -> createEnd is invoked
> //Instance creation
>  createBegin
>  createEnd
> so createEnd and createBegin are called twice and first time 
> creatEnd is invoked is much too early for validation of
>  initialization.

The way it works is that every time createEnd is called by customizeEnd,
createEnd has a special responsibility to return prior to its normal
return, using special instructions for how further objects are to be
created.  Otherwise customizeEnd reports that the create-phase implementation
doesn't support customizeBegin/End, which is the case for all classes that
don't have the special coding for createEnd.

> Second question concerns method probes and GUI:
> 
> 2. I have a class that contains a collection. I created a probe
> for the method getCount (which sends request getCount to the
> collection).
> I would like to have this method automatically invoked and its
> result displayed when the window representing the object
>  appears/is updated. Just not to 
> make user invoke it manually each time. (I also don't want to 
> create an artificial attribute where this value would be
> stored).  Is it possible? I couldn't find the way.
> By the way, is it possible to have attributes
> of different objects in the same probe map or in the same window
> - it seems that probe map is  created for a particular class, 
> but it costs nothing to ask :) 

I'll let others who work more closely with probes answer also, but my
understanding of current probes is that they don't support these capabilities.
Further extensions of probes probably could support them, but I don't think
we've received these particular requests before.  My understanding is that
you'd like a probe map to contain values calculated by sending messages
to other objects to which a probed object is related.

> 3. It is much less important but  I would greatly appreciate
> an answer. I use forwarding in one of my classes and every
> time I use a method that is forwarded, during compilation
> I get a warning: `class' does not respond to `method:' what makes
> an output really messy. It certainly doesn't respond to it,
> it forwards it... Is there any way to stop it? 

Yes.  The problem is typically with default type checking performed by the
compiler whenever it thinks it knows the class of an object.  The workaround
is to case a receiver of class type to type (id), which is all it takes
to shut the compiler up.  For example, [(id)classReceiver doSomething: foo];.
Don't know your exact situation, but casting to (id) is what I always do
to suppress these warning messages.

Roger Burkhart