Re: Naming and other conventions

[Stefan Urbanek]

On Tue, 2005-08-30 at 22:40 +0200, Sašo Kiselkov wrote:
> Quoting Stefan Urbanek <stefan@agentfarms.net>:
> 
> > Hi,
> >
> > As mentioned in my previous emails, StepTalk is going through interface
> > additions and changes. Following are several questions from previous mail
> > (RFC:
> > StepTalk semi-persistent shared environment(s)) that received no feedback so
> > far. I would like to know your opinion before I commit anything:
> >
> > 1. naming conventions
> >
> > - interpretScript:inEnvironment or interpretScript:environment?
> > - methodFromSource:forReceiver:inContext: or
> > methodFromSource:receiver:context:
> 
> Personally I like the first versions better. Although one has to write a 
> little
> bit more, I think the contribution to code readability is much more important
> (such as the latter method you mentioned actually tells me that what I'm
> creating is "for" a receiver and "in" a certain context).
> 

I'll wait for more inputs on this. I do not care which one of the two, I
just would like to be compliant.

> >
> > 2. reference or copy?
> >
> > - what should be default: returning result by reference or by copy? that
> > is, the method -result should return reference or copy? if reference,
> > then there would be following pair:
> >   - result
> >   - resultByCopy (or copyOfResult?)
> > otherwise there would be following pair:
> >   - result
> >   - resultByReference
> > Or - resulByCopy:(BOOL)flag?
> 
> By reference if the result is immutable, otherwise create an autoreleased
> (possibly) immutable copy. And in the case of immutable references, instead of
> creating some weird method pairs, I'd opt for [[foo result] copy] - testing
> whether a result can be copied should be a matter of checking whether it
> implements NSCopying (or NSMutableCopying if that is also apropriate).
> 

My fault, I had it in my mind and have not realised that you sohld not
know it without looking at the sources. I have not explained clearly
what I wanted.

The mentioned methods are methods of a proxy to a distant object. The
situation is like this (simplified):

you -> STDistantConversation -> NSDistantObject -> (process boundary) ->
STConversation

Now, the methods in distant conversation are the same as before, but in
STConversation (and therefore in same protocol in NSDistantObject) it is
different. The question is, what way it should be?

  - (id)result
  - (bycopy id)resultByCopy (or copyOfResult?)
or:
  - (bycopy id)result
  - (id)resultByReference

?

In STDistantConversation i can have one method with a flag:
- (id)resultByCopy:(BOOL)flag;
But the - (id)result would return [self resultByCopy:YES] or [self
resultByCopy:NO]?

> >
> > 3. autoreleased or not?
> >
> > should a method -[STLanguageManager createEngineForLanguage:] return
> > autoreleased object or not? I think that it should be autoreleased, just 
> > want
> > to be sure.
> 
> According to Cocoa memory management documentation, only methods named "alloc"
> and "copy" should return retained objects (retainCount=1). Other methods that
> create objects should always return them as autoreleased.
> 

Ok, you have just assured me.

> >
> > 4. class names
> >
> > Are following class names OK or you would prefer different names?
> >
> > - STConversation - controller that links scripting context/environment +
> > language and script interpretation
> > - STDistantConversation - kind of local proxy for a STConversation in 
> > another
> > process, allows one to interpret scripts in contexts that are remote
> > (STRemoteConversation?)
> 
> Perhaps STRemoteConversation or rather STConversationProxy (which is more
> consistent with OpenStep's name for NSProxy).
> 

I will use STRemoteConversation I think as it is more close to what it
does.

> > - it should be STLanguageManager or STLanguagesManager?
> > - STScriptManager or STScriptsManager?
> 
> STLanguageManager and STScriptManager is correct English, I guess...
> 

Ok.

> >
> > And finally, how would you call a class that would serve as main controller
> > over
> > the whole scripting framework (NSApplication is a controller for the whole
> > process, NSWorkspace is a controller for the whole desktop environment)?
> > STStepTalk, STStepTalkRuntime, STRuntime, STSystem, STLounge ...?
> >
> 
> I'd prefer STRuntime.
> 

Thanks for input. I'll wait for some more.

Regards,

Stefan Urbanek
-- 
http://stefan.agentfarms.net

First they ignore you, then they laugh at you, then they fight you, then
you win.
- Mahatma Gandhi