Hi Igor, While I can clearly see your points, I don't quite agree with all of them, probably because I don't have as much experience as you do. See bellow some of my thoughts on the matter. At the end I like very much NativeBoost today, and I think discussing these things helps us move forward and assume the choices that are made. On Wed, Nov 28, 2012 at 11:04 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 28 November 2012 22:24, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote:
Hi guys,
Looking at NB methods extending Object I am wandering if it won't be better to put them in a Trait to be used by any class needing them?
i don't see what you will gain from that, except that you will end up using that trait all over the places?
What do you understand about all over the places? In my opinion FFI calls should be very well isolated in specific modules that are meant for that. I think we might have different views on this issue... I see using external libraries as a limited number of classes (maybe just one in most cases) doing the native calls, and then writing a library that relies on these classes only for calling the external library. This way the external interfaces are well defined, and we don't run the risk of having the whole image full of FFI calls...
Imo extension to Object is fine. All methods use namespace prefix, so there is a little chance to clash with some other project/package.
yes I agree namespace prefix protects us somehow (at the same time I'm looking the whole day at C code with company_library_MyFoo(x, y, z) calls and I don't like it)
What i dislike about traits that if it used multiple times,
browsing implementors of trait method will give you list of all very same methods where that trait is used. So, if you not careful enough, you can mistakenly change method for a single class, instead of modifying trait method..
This sucks, but I think that it is not an issue, maybe someday the traits will get the attention they deserve, and somebody will fix this problem. I'm a dreamer maybe... but well
As for ByteArray maybe instead of using the methods inherited from Object maybe we can use a double-dispatch scheme to delegate NB calls to another class.
i see that you want to avoid duplicated code. but delegation will cost 1 more message send. while i actually wondering if we need those extensions at all. except from some important ones (internally by NB), i don't think that using nbXAtOffset: is good practice. I think that people should use more higher level abstractions for working with data. those methods providing direct access to memory (with all possible consequences).. so one should use them only if there's no better/more elegant way.
So, even if you put implementation into single class, it won't make things less bloated: you will still have to provide a 'delegation methods' , i.e.:
nbXXXAtOffset: offset ^ SomeGuyInCharge doXXXAtOffset: offset for: self
which won't make number of methods any bit smaller. that's why i asking , what if better would be to look for a ways how we can get rid of all of them instead.. and provide something better in exchange.
I completely agree with you on this...
This way we won't need to extend Object anymore...
Igor, what do you think?
well, extensions were put for reason: to avoid using globals and to make things more convenient to use.
don't let me wrong: i don't like extending Object.. especially over-extending: right now it is 9 extension methods. I'd rather consider if we can shrink that protocol to remove: nbCall: fnSpec module: aModuleNameOrHandle options: callOptions nbCall: fnSpec options: callOptions nbCall: fnSpec module: aModuleNameOrHandle nbCall: fnSpec
since new api, which i introduced recently, provides similar abilities without need of polluting any class(es) protocols more than necessary.
Yep your new API is cool I like it...
I hope I'm not bothering you too much with these small things... By the way did you see my last mail about structs, and enums...? good night
(if you agree I will do it for NB)... I don't know if that will play well with existing NB-based projects though (Athens, NBOpenGL, etc...) But I think it is worth it on the long run...
Cheers, -- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Best regards, Igor Stasenko.
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro