Re: Naming and other conventions

[Sašo Kiselkov]

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).

>
> 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).

>
> 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.

>
> 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).

> - it should be STLanguageManager or STLanguagesManager?
> - STScriptManager or STScriptsManager?

STLanguageManager and STScriptManager is correct English, I guess...

>
> 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,
>
> Stefan Urbanek
> --
> http://stefan.agentfarms.net
>
> First they ignore you, then they laugh at you, then they fight you, then
> you win.
> - Mahatma Gandhi
>

--
Saso