Axel Simon <axel.si...@in.tum.de> writes: > Andy, > > On 22.03.2010, at 08:48, Andy Stewart wrote: > >> If two module have same signal name, example, Entry and TextBuffer have >> some signal `copyClipboard`, when `gtk2hs/gtk/Graphics/UI/Gtk.hs.pp` >> import those will got conflict error, then you just need hiding one >> module's signal name. >> >> We just add suffix `Signal` after signal name when necessary, example >> have signal named `show`, so we need change it to `showSignal` to avoid >> conflict with Haskell `show` functoin. > > Well, my convention was so far to call attributes and signals by their > shortest name (as in > Gtk+). Once a naming conflict with a standard Haskell function occurs (as in > the 'show' signal) or > if two modules export the same signal/attribute name, these become prefixed > with the type name. I > think we should stick to this. Duplicate names in different modules are a > pain since it is > impossible to use either of the names when you simply import Graphics.UI.Gtk > which is what most > users do. Duplicate signal name is unavoidable, because Gtk+ have some many libraries.
Example, in Entry and TextBuffer, have many same signal ` *Clipboard `, so them conflict in Gtk.chs.pp file, as you said, we modified `copyClipboard` in Entry to `entryCopyClipboard`, but user still don't know default `copyClipboard` belong to where? (Perhaps have other module also have `copyClipboard` signal) So we must modified `copyClipboard` in TextBuffer to `textBufferCopyClipboard`, then user will know which signal is come from where. (even long name is waste time) As you recommend, we always use shortest name, just add prefix when conflict, but that's pain to works with diff tool, once new API have same signal/attribute name, we need check source code to confirm it's signal or attribute. If we just keep signal name shortest, then we can merge code immediately when we saw export list. And it's save much time when we update new API. We just need add new signal/attribute name, `signal` and `attribute` won't conflict, Because prefix type always attribute, shortest name always signal. Why not avoid conflict name when create it? Why need waste time on `change conflict name` ? What do you think? > > And please don't change any existing signal names since this will break code. > If an existing module > Foo contains e.g. 'copyClipboard' and a new module has the same signal name, > do the following: > > old Foo.chs: > > -- | The content was copied to the clipboard. > -- > copyClipboard :: .... > copyClipboard = > > > new Foo.chs: > > -- keep backwards compatibility, export, but do not document > copyClipboard = fooCopyClipboard > > -- | The content was copied to the clipboard. > -- > fooCopyClipboard :: .... > fooCopyClipboard = > > > Please tell me if this convention is not clear. I agree this, it's a good idea for backward compatibility! :) And keep a accordant coding style. Cheers, -- Andy ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
