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? Imo extension to Object is fine. All methods use namespace prefix, so there is a little chance to clash with some other project/package. 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..
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.
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.
(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.