From: John L. <jla...@gm...> - 2006-05-18 02:59:12
|
In going through the the interface files I've noticed that there are a few naming inconsistencies for C++ overloaded functions and constructors. Typically they have the names that wxPython uses (where noted in the docs) and for the most part are fine, but... Since we can overloaded function in wxLua directly (usually) we don't actually need to give them unique names, however they need some sort of name for the C function and might as well be accessible in wxLua using that name as well as the overloaded way. Suggested rules for renaming: 1) Most "commonly used" or default function gets actual name 2) Function names use the original name + [With][Data type] ex. Append(int n), Append(wxString s) -> AppendString(s) ex. Append(int n), Append(int n, Stuff s) -> AppendWithStuff(n, s) 3) Class constructors start with the ClassName + From[Data type] Default constructors are always wxClassNameDefault() Copy constructors are always wxClassNameCopy(const wxClassName& c) Obviously there will be exceptions or cases where the name may sound awkward, but the number of these will be small. Some examples of the inconsistencies I'm talking about: -------------------------- These member functions will be out of alphabetical order and may be difficult to directly associate with the original function without looking through the docs. It is true that the wxPython ones may be more syntactically "correct", but I think that directly associating them with the original function is more compelling. wxListCtrl wxPython naming (currently wxLua uses this) InsertItem(item) Inserts an item using a wxListItem. InsertStringItem(index, label) Inserts a string item. InsertImageItem(index, imageIndex) Inserts an image item. InsertImageStringItem(index, label, imageIndex) Insert an image/string = item. I would prefer InsertItem(item) Inserts an item using a wxListItem. InsertItemString(index, label) Inserts a string item. InsertItemImage(index, imageIndex) Inserts an image item. InsertItemImageString(index, label, imageIndex) Insert an image/string = item. --------------------------- Some constructor examples, currently it's this way wxColour(const unsigned char red, const unsigned char green, const unsigned char blue) wxNamedColour(const wxString& colourNname) // python compatibility wxColourCopy(const wxColour& colour) I would prefer wxColour(const unsigned char red, const unsigned char green, const unsigned char blue) wxColourFromString(const wxString& colourNname) // python compatibility wxColourCopy(const wxColour& colour) other examples %constructor wxDefaultBitmap() %win wxBitmap(void * data, int type, int width, int height, int depth = =3D -1) %constructor wxBitmapCopy(const wxBitmap& bitmap) %constructor wxEmptyBitmap( int width, int height, int depth =3D -1) %constructor wxBitmapFromFile( const wxString& name, long type) %constructor wxBitmapFromXPMData(const char **data) %wxchkver23 %constructor wxBitmapFromImage(const wxImage &image, int depth =3D -1) and wxImage(const wxImage& image) %constructor wxDefaultImage() %wxchkver23 %constructor wxImageFromBitmap(const wxBitmap& bitmap) %constructor wxEmptyImage(int width, int height, bool clear=3Dtrue) %constructor wxImageFromData(int width, int height, unsigned char* data, bool static_data =3D false) %constructor wxImageFromFile(const wxString& name, long type =3D wxBITMAP_TYPE_ANY) Hopefully you can see that the naming right now can be fairly arbitrary, where the default wxImage constructor makes a copy? wxEmptyImage? wxDefaultImage? The default for wxBitmap takes the bitmap data itself, but only for MSW, how useful is that? I would like to normalize all of these, obviously breaking compatibility, but better sooner than later. :) There's probably about 2 dozen of them to change. Regards, John Labenski |
From: Francesco M. <f18...@ya...> - 2006-05-19 07:04:50
|
John Labenski ha scritto: > In going through the the interface files I've noticed that there are a > few naming inconsistencies for C++ overloaded functions and > constructors. Typically they have the names that wxPython uses (where > noted in the docs) and for the most part are fine, but... > > Since we can overloaded function in wxLua directly (usually) we don't > actually need to give them unique names, however they need some sort > of name for the C function and might as well be accessible in wxLua > using that name as well as the overloaded way. however I'm not sure that having two possible names (e.g. InsertItem and InsertItemString) for the same functions (in lua scripts) is a good thing: it probably means there will be scripts with a messy mix of the two... > Suggested rules for renaming: > 1) Most "commonly used" or default function gets actual name > 2) Function names use the original name + [With][Data type] > ex. Append(int n), Append(wxString s) -> AppendString(s) > ex. Append(int n), Append(int n, Stuff s) -> AppendWithStuff(n, s) > 3) Class constructors start with the ClassName + From[Data type] > Default constructors are always wxClassNameDefault() > Copy constructors are always wxClassNameCopy(const wxClassName& c) > > Obviously there will be exceptions or cases where the name may sound > awkward, but the number of these will be small. I agree: better follow a unique rational rule. This will reduce the number of times the user is forced to look in the manual to find the right name of a function. > Hopefully you can see that the naming right now can be fairly > arbitrary, where the default wxImage constructor makes a copy? > wxEmptyImage? wxDefaultImage? The default for wxBitmap takes the > bitmap data itself, but only for MSW, how useful is that? > > I would like to normalize all of these, obviously breaking > compatibility, but better sooner than later. :) There's probably about > 2 dozen of them to change. I agree that this should be done as soon as possible. Francesco |
From: Hakki D. <dog...@tr...> - 2006-05-19 16:40:13
|
Hi, Francesco Montorsi yazmış: > John Labenski ha scritto: >> In going through the the interface files I've noticed that there are a >> few naming inconsistencies for C++ overloaded functions and >> constructors. Typically they have the names that wxPython uses (where >> noted in the docs) and for the most part are fine, but... >> >> Since we can overloaded function in wxLua directly (usually) we don't >> actually need to give them unique names, however they need some sort >> of name for the C function and might as well be accessible in wxLua >> using that name as well as the overloaded way. > however I'm not sure that having two possible names (e.g. InsertItem and > InsertItemString) for the same functions (in lua scripts) is a good > thing: it probably means there will be scripts with a messy mix of the > two... > >> Suggested rules for renaming: >> 1) Most "commonly used" or default function gets actual name >> 2) Function names use the original name + [With][Data type] >> ex. Append(int n), Append(wxString s) -> AppendString(s) >> ex. Append(int n), Append(int n, Stuff s) -> AppendWithStuff(n, s) >> 3) Class constructors start with the ClassName + From[Data type] >> Default constructors are always wxClassNameDefault() >> Copy constructors are always wxClassNameCopy(const wxClassName& c) >> >> Obviously there will be exceptions or cases where the name may sound >> awkward, but the number of these will be small. > I agree: better follow a unique rational rule. This will reduce the > number of times the user is forced to look in the manual to find the > right name of a function. > > >> Hopefully you can see that the naming right now can be fairly >> arbitrary, where the default wxImage constructor makes a copy? >> wxEmptyImage? wxDefaultImage? The default for wxBitmap takes the >> bitmap data itself, but only for MSW, how useful is that? >> >> I would like to normalize all of these, obviously breaking >> compatibility, but better sooner than later. :) There's probably about >> 2 dozen of them to change. > I agree that this should be done as soon as possible. > > Francesco > > I was naming my python bindings (with swig) like wxPython. But for lua I'm not duplicating functions for every different params; I'm checking them in wrapping functions. I'm using luna. So all wrapping is hand made :) Ex: in C++ : Send(int), Send(wxString), Send(int, int),... becomes in Lua: Send(...) But I don't know how something like that can be generated automatically. Does toLua handle overloaded functions? -- Regards, Hakki Dogusan |
From: John L. <jla...@gm...> - 2006-05-19 18:15:01
|
T24gNS8xOS8wNiwgSGFra2kgRG9ndXNhbiA8ZG9ndXNhbmhAdHIubmV0PiB3cm90ZToKPiBGcmFu Y2VzY28gTW9udG9yc2kgeWF6bf3+Ogo+ID4gSm9obiBMYWJlbnNraSBoYSBzY3JpdHRvOgo+ID4+ IEluIGdvaW5nIHRocm91Z2ggdGhlIHRoZSBpbnRlcmZhY2UgZmlsZXMgSSd2ZSBub3RpY2VkIHRo YXQgdGhlcmUgYXJlIGEKPiA+PiBmZXcgbmFtaW5nIGluY29uc2lzdGVuY2llcyBmb3IgQysrIG92 ZXJsb2FkZWQgZnVuY3Rpb25zIGFuZAo+ID4+IGNvbnN0cnVjdG9ycy4gVHlwaWNhbGx5IHRoZXkg aGF2ZSB0aGUgbmFtZXMgdGhhdCB3eFB5dGhvbiB1c2VzICh3aGVyZQo+ID4+IG5vdGVkIGluIHRo ZSBkb2NzKSBhbmQgZm9yIHRoZSBtb3N0IHBhcnQgYXJlIGZpbmUsIGJ1dC4uLgo+ID4+Cj4gPj4g U2luY2Ugd2UgY2FuIG92ZXJsb2FkZWQgZnVuY3Rpb24gaW4gd3hMdWEgZGlyZWN0bHkgKHVzdWFs bHkpIHdlIGRvbid0Cj4gPj4gYWN0dWFsbHkgbmVlZCB0byBnaXZlIHRoZW0gdW5pcXVlIG5hbWVz LCBob3dldmVyIHRoZXkgbmVlZCBzb21lIHNvcnQKPiA+PiBvZiBuYW1lIGZvciB0aGUgQyBmdW5j dGlvbiBhbmQgbWlnaHQgYXMgd2VsbCBiZSBhY2Nlc3NpYmxlIGluIHd4THVhCj4gPj4gdXNpbmcg dGhhdCBuYW1lIGFzIHdlbGwgYXMgdGhlIG92ZXJsb2FkZWQgd2F5Lgo+ID4gaG93ZXZlciBJJ20g bm90IHN1cmUgdGhhdCBoYXZpbmcgdHdvIHBvc3NpYmxlIG5hbWVzIChlLmcuIEluc2VydEl0ZW0g YW5kCj4gPiBJbnNlcnRJdGVtU3RyaW5nKSBmb3IgdGhlIHNhbWUgZnVuY3Rpb25zIChpbiBsdWEg c2NyaXB0cykgaXMgYSBnb29kCj4gPiB0aGluZzogaXQgcHJvYmFibHkgbWVhbnMgdGhlcmUgd2ls bCBiZSBzY3JpcHRzIHdpdGggYSBtZXNzeSBtaXggb2YgdGhlCj4gPiB0d28uLi4KClRoaXMgaXMg dHJ1ZSwgaG9wZWZ1bGx5IHBlb3BsZSB3aWxsIGp1c3QgdXNlIHRoZSBvdmVybG9hZGVkIG1ldGhv ZHMgYXMKc2hvd24gaW4gdGhlIHNhbXBsZXMgKHRvZG8pLiBUaGVyZSdzIHN0aWxsIHNvbWUgd29y ayB0byBiZSBkb25lIHdpdGgKdGhlIG92ZXJsb2FkZWQgZnVuY3Rpb25zLCBsaWtlIHN0YXRpYyBm dW5jdGlvbnMgZG9uJ3Qgd29yaywgYnV0IEkKZG9uJ3QgZm9yc2VlIGFueXRoaW5nIHRoYXQgc2hv dWxkIG1ha2UgaXQgaW1wb3NzaWJsZS4KCj4gPj4gU3VnZ2VzdGVkIHJ1bGVzIGZvciByZW5hbWlu ZzoKPiA+PiAxKSBNb3N0ICJjb21tb25seSB1c2VkIiBvciBkZWZhdWx0IGZ1bmN0aW9uIGdldHMg YWN0dWFsIG5hbWUKPiA+PiAyKSBGdW5jdGlvbiBuYW1lcyB1c2UgdGhlIG9yaWdpbmFsIG5hbWUg KyBbV2l0aF1bRGF0YSB0eXBlXQo+ID4+IGV4LiBBcHBlbmQoaW50IG4pLCBBcHBlbmQod3hTdHJp bmcgcykgLT4gQXBwZW5kU3RyaW5nKHMpCj4gPj4gZXguIEFwcGVuZChpbnQgbiksIEFwcGVuZChp bnQgbiwgU3R1ZmYgcykgLT4gQXBwZW5kV2l0aFN0dWZmKG4sIHMpCj4gPj4gMykgQ2xhc3MgY29u c3RydWN0b3JzIHN0YXJ0IHdpdGggdGhlIENsYXNzTmFtZSArIEZyb21bRGF0YSB0eXBlXQo+ID4+ IERlZmF1bHQgY29uc3RydWN0b3JzIGFyZSBhbHdheXMgd3hDbGFzc05hbWVEZWZhdWx0KCkKPiA+ PiBDb3B5IGNvbnN0cnVjdG9ycyBhcmUgYWx3YXlzIHd4Q2xhc3NOYW1lQ29weShjb25zdCB3eENs YXNzTmFtZSYgYykKPiA+Pgo+ID4+IE9idmlvdXNseSB0aGVyZSB3aWxsIGJlIGV4Y2VwdGlvbnMg b3IgY2FzZXMgd2hlcmUgdGhlIG5hbWUgbWF5IHNvdW5kCj4gPj4gYXdrd2FyZCwgYnV0IHRoZSBu dW1iZXIgb2YgdGhlc2Ugd2lsbCBiZSBzbWFsbC4KPiA+IEkgYWdyZWU6IGJldHRlciBmb2xsb3cg YSB1bmlxdWUgcmF0aW9uYWwgcnVsZS4gVGhpcyB3aWxsIHJlZHVjZSB0aGUKPiA+IG51bWJlciBv ZiB0aW1lcyB0aGUgdXNlciBpcyBmb3JjZWQgdG8gbG9vayBpbiB0aGUgbWFudWFsIHRvIGZpbmQg dGhlCj4gPiByaWdodCBuYW1lIG9mIGEgZnVuY3Rpb24uCgpHb29kLCBJJ20gZ2xhZCB5b3UgYWdy ZWUuIEFnYWluLCBmb3IgdGhlIG1vc3QgcGFydCB0aGV5IGZvbGxvdyB0aGUKYWJvdmUgInJ1bGVz IiwgYnV0IHRoZXJlJ3Mgc29tZSBvZGRiYWxscy4KCj4gPj4gSG9wZWZ1bGx5IHlvdSBjYW4gc2Vl IHRoYXQgdGhlIG5hbWluZyByaWdodCBub3cgY2FuIGJlIGZhaXJseQo+ID4+IGFyYml0cmFyeSwg d2hlcmUgdGhlIGRlZmF1bHQgd3hJbWFnZSBjb25zdHJ1Y3RvciBtYWtlcyBhIGNvcHk/Cj4gPj4g d3hFbXB0eUltYWdlPyB3eERlZmF1bHRJbWFnZT8gVGhlIGRlZmF1bHQgZm9yIHd4Qml0bWFwIHRh a2VzIHRoZQo+ID4+IGJpdG1hcCBkYXRhIGl0c2VsZiwgYnV0IG9ubHkgZm9yIE1TVywgaG93IHVz ZWZ1bCBpcyB0aGF0Pwo+ID4+Cj4gPj4gSSB3b3VsZCBsaWtlIHRvIG5vcm1hbGl6ZSBhbGwgb2Yg dGhlc2UsIG9idmlvdXNseSBicmVha2luZwo+ID4+IGNvbXBhdGliaWxpdHksIGJ1dCBiZXR0ZXIg c29vbmVyIHRoYW4gbGF0ZXIuIDopIFRoZXJlJ3MgcHJvYmFibHkgYWJvdXQKPiA+PiAyIGRvemVu IG9mIHRoZW0gdG8gY2hhbmdlLgo+ID4gSSBhZ3JlZSB0aGF0IHRoaXMgc2hvdWxkIGJlIGRvbmUg YXMgc29vbiBhcyBwb3NzaWJsZS4KCk5leHQgd2VlaywgSSdtIG9mZiBmb3IgdGhlIHdlZWtlbmQu Cgo+IEkgd2FzIG5hbWluZyBteSBweXRob24gYmluZGluZ3MgKHdpdGggc3dpZykgbGlrZSB3eFB5 dGhvbi4gQnV0Cj4gZm9yIGx1YSBJJ20gbm90IGR1cGxpY2F0aW5nIGZ1bmN0aW9ucyBmb3IgZXZl cnkgZGlmZmVyZW50IHBhcmFtczsKPiBJJ20gY2hlY2tpbmcgdGhlbSBpbiB3cmFwcGluZyBmdW5j dGlvbnMuIEknbSB1c2luZyBsdW5hLiBTbyBhbGwKPiB3cmFwcGluZyBpcyBoYW5kIG1hZGUgOikK Pgo+IEV4OiBpbiBDKysgOiBTZW5kKGludCksIFNlbmQod3hTdHJpbmcpLCBTZW5kKGludCwgaW50 KSwuLi4KPiBiZWNvbWVzIGluIEx1YTogU2VuZCguLi4pCj4KPiBCdXQgSSBkb24ndCBrbm93IGhv dyBzb21ldGhpbmcgbGlrZSB0aGF0IGNhbiBiZSBnZW5lcmF0ZWQgYXV0b21hdGljYWxseS4KPiBE b2VzIHRvTHVhIGhhbmRsZSBvdmVybG9hZGVkIGZ1bmN0aW9ucz8KCkR1bm5vLCB3eEx1YSB1c2Vz IGl0J3Mgb3duIHdyYXBwaW5nIG1lY2hhbmlzbSBmb3IgYmV0dGVyIG9yIHdvcnNlLgpQcm9iYWJs eSBmb3IgdGhlIGJldHRlciBzaW5jZSB3ZSBoYXZlIGNvbnRyb2wgb3ZlciBpdCBhbmQgdGhlcmUn cyBhCmZldyB0aGluZyBpbiB3eFdpZGdldHMgdGhhdCB3ZSBoYXZlIHRvIGhhbmRsZSBzcGVjaWFs bHksIGxpa2Ugd3hXaW5kb3cKZGVyaXZlZCBjbGFzc2VzLgoKaHR0cDovL3d4bHVhLnNvdXJjZWZv cmdlLm5ldC9kb2NzL2JpbmRpbmcuaHRtbApodHRwOi8vd3hsdWEuc291cmNlZm9yZ2UubmV0L2Rv Y3Mvd3hsdWFyZWYuaHRtbAoKUmVnYXJkcywKICAgIEpvaG4gTGFiZW5za2kK |