Re: Objective-C/Java Translation

[Rob Leclerc]

I am not sure I have this competley down or not.  First of all is there any
*real* need to bisect a createBegin/createEnd phase away from the object
itself?  As, for the *most* part it seems that all the setting up activity
can be carried out within the constructor.  I understand the notion that one
would want to keep certian data objects/values of an "Impl" object
encapsulated and protected, but that should just be set with private fields,
and without getter/setter methods for them?

Further, I am not sure I see a necessary link between a "CImpl" object and a
corresponding "Impl" object.  As an example, and as I understand it, I might
to something like:

MyObjectIF objectInterface;  //declare an interface for and object

//...Some point later in the code we want to declare our object...

MyObjectCIF objectCInterface = new MyObjectCImpl(new MyObjectImpl());

//Then we want to execute some code in createBegin()

objectCInterface.createBegin(aZone);
objectCInterface.setSomeValue(someValue);

/*
Now am I to suppose that MyObjectCImpl, and extending something like
SwarmObjectCImpl,
that I will now have identified createBegin(),createEnd(), and some set*()
methods, and on TOP of that, will
have set my constructor something like:
*/

    public MyObjectCImpl(MyObjectIF myObject){

    this.someLocalStorageVariableForMyObject = myObject;

    }


/*
And then I am assuming that createBegin(), and createEnd() will make some
alterations to myObject?
thus thus createEnd(), will then return the variable reference
"this.someLocalStorageVariableForMyObject"?
What I don't really understand is why those would need to be set outside of
the constructor?  Having overloaded
constructors should allow you to pretty much mutate the object in any way
you desire.
*/

Thus if you wanted to create an object and set some DNA info for it, you
could have some DNA class, and pass
it in the constructor of the class you were setting it for.  The object
itself would then just have a private interface for that object which
would be make it not directly accessable.


BTW, the need for casting would be because by default the return type is of
type Object, and one would need to
cast it to something compadible with the interface it was being passed back
to, ie usually the same interface type as the interface that it
is being passed back to.

RDL






----- Original Message -----
From: "Paul E Johnson" <address@hidden>
To: <address@hidden>
Sent: Wednesday, January 24, 2001 7:56 AM
Subject: Re: Objective-C/Java Translation


> > Rob Leclerc wrote:
> >
"<interfaceName>","<interfaceName>C","<interfaceName>CImpl","<interfaceName>
Impl".
> >
> > As well as these "C" references, which I take to be some kind of
> > create versions of the class, there are also some "S" type classes.  I
> > was unable to get a good understanding of what the different or
> > important roles these classes played. >
>
> Hey, Rob, I'm trying to understand this too, a late Java-arriver as I
> am.  Perhaps I can write down my understanding, we can get corrected by
> the experts, and I'll have something to put in the FAQ.
>
> If you look in the Email list from early January, you will find a note
> from me asking how to subclass Arguments in java and Marcus gave a test
> program, which I have in the WorkingExampleCode section of SwarmFaq.
>
http://lark.cc.ukans.edu/~pauljohn/SwarmFaq/WorkingExampleCode/java/Argument
sSubclass.java
> .
>
> To the best of my limited understanding, the problem is Java
> constructors do not allow return arguments, so the usual swarm thing
> like:
>
> [[aObject createBegin: aZone] createEnd]
>
> does not work.  Also, swarm classes are designed with a separation
> between methods you can do at "create time" from others, and those
> create time methods have to be used before the createEnd, and never
> after it.  I'm not a programmer, so pardon my terminology.  Its
> something like this: you need to catch the object when it is still in
> the gestation period and do things to it, before it is a full fledged
> object.  That was easy in ObjC, not so simple in Java.
>
> So you have to look harder at Marcus's code, and I'm still not sure I
> understand everything about it, but the CImpl class is the functional
> equivalent of a "holding class" that can be created and given a
> proto-object of the sort you want to create (maybe proto is not the
> right word. I mean it is an inchoate object, a part-of-the-way created
> object. I mean it is the thing that createBegin returns in objc). This
> "holding class" has the ability to execute the things that go into the
> createBegin phase of object creation.
>
> Suppose you need to create aObject, but it requires
> createBegin/createEnd fussing.
>
> First, declare that thing you want to end up with.
>
> WhateverImpl aObject;
>
> Next, create the "holding class" which can do the create-time fussing
> about with the proto-object. Note, the proto-object is created in the
> argument to WhateverCImpl, so it is "hidden" inside there.  The
> WhateverCImpl class does whatever it does to that object:
>
>   WhateverCImpl aTemporaryObject =  new WhateverCImpl( new
> WhateverImpl());
>
> Now, aTemporaryObject can do the things you need done in the create
> phase of the proto-class that is inside it:
>
>   aTemoraryObject.createBegin(aZone);
> aTemoraryObject.setSomeValue(aValue);
>
> Then, when you are done with create-phase methods, you yank the
> proto-object out of aTemporaryObject.  I don't know why the cast is
> required here, but it works:
>
> aObject = (WhateverImpl) aTemporaryObject.createEnd();
>
> --
> Paul E. Johnson                       email: address@hidden
> Dept. of Political Science            http://lark.cc.ukans.edu/~pauljohn
> University of Kansas                  Office: (785) 864-9086
> Lawrence, Kansas 66045                FAX: (785) 864-5700
>
>                   ==================================
>    Swarm-Support is for discussion of the technical details of the day
>    to day usage of Swarm.  For list administration needs (esp.
>    [un]subscribing), please send a message to <address@hidden>
>    with "help" in the body of the message.
>


                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.