On Sat, 7 Jan 2006 02:50:03 +1000 David Seikel <[EMAIL PROTECTED]> wrote:
> On Sat, 7 Jan 2006 00:35:42 +0900 Carsten Haitzler (The Rasterman) > <[EMAIL PROTECTED]> wrote: > > > i would argue that ECORE_EVENT_EXE is fine as its a CORE ecore event > > (not a sub ecore system like ecore_con)... ? > > I'm thinking consistency in naming things IPC related. I think that > merging fork'n'pipe with ecore_ipc might be good, it's just another > IPC method, why should it be different? Most of the ways of dealing > with it from the ecore users perspective are mostly similar. Most of > the differences are simply due to current inconsistent naming and > lack of an exe add event. The user doesn't see any core ecore / sub > ecore issues, it's all ecore_*_whatever to them. > > As I said before, the naming of the exit event is historical, and I'm > prepared to wear that. The data event is new though, and should be > consistent with other IPC data events. It's semantics are the same, > hell most of the code was just cut'n'paste from ecore_con. I've thought about it some more, and the fact that the ecore_exe functions are all called ecore_exe_* like the "sub" ecore functions means that I consider it to be more consistent. The style guide says to use name spaced, object oriented style names, so ecore_exe_* and ECORE_EXE_* has to be the way to go. I'll make these changes, but keep ECORE_EVENT_EXE_EXIT around for historical reasons (so no one can blame me for beaking evidence).
pgphCBYmwgpSL.pgp
Description: PGP signature
