[00:38:01] *** prophile has quit IRC
[01:04:54] *** prophile has joined #openal
[01:04:54] *** ChanServ sets mode: +v prophile
[01:21:23] *** prophile has quit IRC
[01:28:45] *** Walt has quit IRC
[01:41:11] <KittyCat> Mazon, not currently. but patches are welcome
[01:57:31] * KittyCat is back.
[02:11:24] *** Walt has joined #openal
[02:11:24] *** ChanServ sets mode: +v Walt
[02:54:35] <kb1ooo_> hi KittyCat.  Re: you C++ thread.  While adding some syntatic C++ sugar to the API the way you presented it seems like a good idea, the C style approach of using non-member functions and passing the object is in general a better OOP desing for non-virtual functions.
[02:55:17] <KittyCat> how do you mean?
[02:57:39] <kb1ooo_> member functions that can be written as non-member functions have weaker encapsulation as member functions.
[02:58:36] <kb1ooo_> if they can be written as non-member functions, then they don't need direct access to private member data.
[02:59:05] <kb1ooo_> therefore if the implmentation changes, non-member functions won't break.
[02:59:29] <kb1ooo_> here's a good article: http://www.ddj.com/cpp/184401197
[03:00:46] <KittyCat> the functions in the implementation do access the private data
[03:01:46] <kb1ooo_> yes, but if you make them access the implementation through public acessors, then you only have to worry about managing the accessors.
[03:02:50] <kb1ooo_> lot's of STL is non-member functions.
[03:03:02] <kb1ooo_> *lots*
[03:04:02] <kb1ooo_> inheritance is another one that should be avoided when possible.  Often composition is the better choice.
[03:04:34] <kb1ooo_> http://www.berniecode.com/writing/inheritance/
[03:06:05] <kb1ooo_> using C++ to wrap the C api might be a better choice.
[03:07:59] <kb1ooo_> anyway, just a couple things I wanted to throw out there.
[03:09:31] <KittyCat> I'm not sure what adding accessors would do, at least in this case. ALUTstream::PlayOnSource, for instance, needs to reset the input data stream, and start playing the specified source.
[03:10:17] <KittyCat> the input data reset happens with InitStream (which was seperated so different functions can use it), and it needs to access the source object
[03:10:43] <KittyCat> if the source object changes, an accessor won't help because the accessors would be similarly affected
[03:14:03] <KittyCat> as for inheritence, that's only used so the implementation isn't exposed to the app
[03:14:34] <KittyCat> having an opaque object in the interface seems wasteful and just serves to add more indirection to actually accomplishing the task
[03:14:44] <kb1ooo_> yes, but the functions that use the acessors are indirectly affected.  An accessor is an interface that will not change.  the way you implement the source object might. change.  which means that you only have to change the implmentation of the acessor, not every function that directly acesses the data.
[03:15:32] <KittyCat> which only works well when accessing the objects is complicated
[03:16:58] <KittyCat> for example, if I do alSourcei(this->Source, AL_BUFFER, 0);, it wouldn't matter if I did alSourcei(this->GetSource(), AL_BUFFER, 0);. they both need a source, and if it's not readilly available for a function that needs it, there's something wrong in the design, IMO
[03:19:58] <KittyCat> having a function like StreamImpl::ClearBuffer() is also, IMO, worthless because it only serves to abstract away openal, where openal is already designed to abstract away the lower stuff
[03:20:00] <kb1ooo_> i'm not sure i agree  What if later you decide to put the Source in some other class another level deep, so to access it you write this->Sources->source[0]
[03:20:31] <KittyCat> then again, the accessor would be similarly affected. what would StreamImpl::GetSource do, in that case?
[03:21:12] <kb1ooo_> yes, so you only have to change GetSource(), you don't have to change every one of your alSourcei calls
[03:21:31] <KittyCat> change it to what, though?
[03:21:48] <KittyCat> GetSource would return the source, from the design where there's only one source
[03:22:00] <kb1ooo_> alSourcei(this->Sources->source[0], AL_BUFFER,0)
[03:22:13] <KittyCat> if there's more than one source, what would GetSource be doing?
[03:22:50] <kb1ooo_> i'm just being abstract here.  it could have been something like this->sourceContainer->Source
[03:24:27] <KittyCat> then I'll change the al(Get)Sourcei calls as needed. it's not like the implementation is very large
[03:25:06] <KittyCat> such a GetSource() function would be inlined, anyway. so if it changes, things using it would need to be rebuilt.
[03:25:48] <KittyCat> adding abstraction where you're only doing a single task is overdesigning, IMO
[03:26:14] <kb1ooo_> requiring a rebuild is quite a different thing than having to change code and rebuild
[03:26:42] <KittyCat> abstraction is good for where you need to do multiple tasks in multiple places, or where you want to be able to change the task that's performed at run-time
[03:26:58] <KittyCat> *the same multiple tasks in multiple places
[03:27:36] <KittyCat> if it's a simple single task, I don't see much use in it. if it changes slightly, that's what search&replace is for
[03:29:44] <kb1ooo_> C++ is there so you don't have to do search and replace :)
[03:31:36] <kb1ooo_> anyway, i was really just cautioning the c++ api.  i feel that you just have to be careful about syntatic sugar like stream->play() instead of play(stream) because in some cases the later is the better interface.
[03:32:22] <KittyCat> it seems to be more of a C#/Java attitude. encapsulate/abstract everything.
[03:32:26] <KittyCat> not that it's necessarilly a bad thing, but I think it's just overkill.
[03:33:50] <kb1ooo_> I don't really see it as over abstraction.  I've often been burned by the bounding/fading ball example in http://www.berniecode.com/writing/inheritance/
[03:34:03] <kb1ooo_> as well as the base class fragility problem
[03:34:33] <KittyCat> the seperate interfaces are also completely optional. if someone doesn't want to use stream->play(), they can still do play(stream), even in C++. it does the same exact thing
[03:34:44] <KittyCat> the object/pointer is the same in both cases
[03:36:32] <kb1ooo_> yah, i know.  i'm just nitpicking about working hard to provide something that in many cases opens the door to bad design :)
[03:36:41] <KittyCat> I just find it a bit jarring when you have/are working on code that's using C++ heavilly, and then all of a sudden there's a section that's basic C because the lib its using is C only
[03:37:16] <KittyCat> especially C that's trying to be OO
[03:38:12] <kb1ooo_> what i'd love to see is a way to create a stream object on the stack.  Encapsulation of heap allocations make things quite a bit safer.
[03:39:13] <kb1ooo_> anyway, nice chatting with you.  I've got some work to finish up before heading to bed.
[03:39:15] <KittyCat> and by providing a C++ interface to that OO C functionality will help the code blend in like it should. especially when it provides the ability to use C++ features (auto pointers, shared pointers, inheritence, etc)
[03:39:41] <KittyCat> cya :)
[07:22:06] *** Walt has quit IRC
[08:47:22] *** Alam_Debian has quit IRC
[08:47:22] *** KittyCat has quit IRC
[08:49:05] *** Alam_Debian has joined #openal
[08:49:05] *** KittyCat has joined #openal
[08:49:05] *** irc.freenode.net sets mode: +vv Alam_Debian KittyCat
[10:54:57] *** juanmabc has quit IRC
[12:13:24] * KittyCat is away: sleep
[13:57:04] *** Walt has joined #openal
[13:57:04] *** ChanServ sets mode: +v Walt
[14:25:06] *** kb1ooo_ has quit IRC
[14:38:52] *** kb1ooo_ has joined #openal
[14:38:52] *** ChanServ sets mode: +v kb1ooo_
[14:53:25] *** Walt_ has joined #openal
[14:53:25] *** ChanServ sets mode: +v Walt_
[15:04:47] *** Walt has quit IRC
[15:05:35] *** Walt_ has quit IRC
[17:31:20] *** zarroba has joined #openal
[17:31:20] *** ChanServ sets mode: +v zarroba
[17:31:33] <zarroba> hi there anyone here?
[17:35:24] *** Walt has joined #openal
[17:35:24] *** ChanServ sets mode: +v Walt
[17:52:04] *** zarroba has quit IRC
[18:33:17] *** prophile has joined #openal
[18:33:17] *** ChanServ sets mode: +v prophile
[19:30:21] *** juanmabc has joined #openal
[19:30:22] *** ChanServ sets mode: +v juanmabc
[21:19:34] *** juanmabc has quit IRC
[22:25:26] *** juanmabc has joined #openal
[22:25:27] *** ChanServ sets mode: +v juanmabc





top