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?
>
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.