[wx-dev] Re: XTI class names

[Stefan Csomor]

Hi Vadim
> On Mon, 23 Jul 2007 22:18:32 +0200 Francesco Montorsi <f18m_cpp217828 at yahoo.it> wrote:
>
> FM> >> ops, you're right. Then I'd suggest:
> FM> >>
> FM> >> wxConstructorBridge => wxClassConstructor[Bridge?]
> FM> >>
> FM> >> just to underline that what that class constructs are other classes 
> FM> >> (just wxConstructor[Bridge] seems too generic).
> FM> > not exactly, it calls Create on a newly allocated object instance, along 
> FM> > our two-phase construction paradigm in wx. So perhaps 
> FM> > wxObjectCreateBridge or something along these lines ?
> FM> > ...
> FM> wxObjectCreateBridge sounds good to me. Or maybe simply wxObjectCreator?
>
>  I think wxObjectCreator is too generic but OTOH "Bridge" is a bit unusual
> for me in this context, so I'd call it wxObjectCreateAdaptor ("Create()",
> as in the method name, not "Creator").
>   
fine with me as well
> FM> >>> so because they deal with object instances the names could also have 
> FM> >>> a 'object' instead of 'classinfo',
> FM> >> substituting classinfo with object would give sligthly shorter names:
> FM> >>
> FM> >> wxWriter => wxObjectWriter
> FM> >> wxReader => wxObjectReader
> FM> >> wxXmlWriter => wxObjectXMLWriter
> FM> >> wxXmlReader => wxObjectXMLReader
> FM> >>
> FM> >> wxPersister => wxObjectReaderNotifier
> FM> >> wxDepersister => wxObjectWriterNotifier
> FM> >> wxRuntimeDepersister => wxObjectCodeReaderNotifier
> FM> >> wxCodeDepersister => wxObjectRuntimeReaderNotifier
> FM> > to me object writer etc sound good, I'm not yet fully enamored with 
> FM> > Notifier, as it has the capability of changing and vetoing on the source 
> FM> > of the notification, it is more than a Notification to me, perhaps a ... 
> FM> > Delegate ... ?
> FM> Delegate seems a bit different to me and doesn't recall the callback 
> FM> concept.
> FM> Maybe we could simply use "callback" term:
> FM> 
> FM> wxPersister => wxObjectReaderCallback
> FM> wxDepersister => wxObjectWriterCallback
> FM> wxRuntimeDepersister => wxObjectCodeReaderCallback
> FM> wxCodeDepersister => wxObjectRuntimeReaderCallback
> FM> 
> FM> ?
>
>  Another alternative is "Observer". But at this stage of the discussion for
> me the more interesting question is why do we need to have these objects at
> all (it seems like you could just derive from/aggregate
> wxObjectReader/Writer) rather than how to call them.
>   
no they are rather orthogonal in the process, the reader/writer are 
concerned with the format, i.e. do you stream out the information as XML 
or as a dense binary information, ie the 'how'. While the callback is 
responsible for deciding whether an attribute will be written out, 
eventually changing the value during the process etc, ie the 'what'.

Thanks,

Stefan