Before I look into all of this, I want to clear a possible misunderstanding. Have you looked at this commit which followed the one this thread is about: https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?h=GSoC-2019-moazin&id=8a40ef90ea2a819ea7c9b3eb03b2f312af0dbec9
Abusing it to set pointer to code, Just Unacceptable. Because, after this commit, I am not abusing it to set pointer to code. I am abusing it to set a structure of four function pointers. Let me know if your concerns remain the same with this change. Meanwhile, I should dig into the things you mentioned. I am new to C design patterns and thus unaware of standard practices. On Mon, Aug 19, 2019 at 11:47 PM Behdad Esfahbod <beh...@behdad.org> wrote: > On Fri, Jul 19, 2019 at 4:34 PM Moazin Khatri <moazinkha...@gmail.com> > wrote: > >> Just want to express that this is very, *very*, /very/, VERY, bad. >>> >> >> Thank you for pointing that out. However, ... >> >> The whole property API is a big anti-pattern that FreeType has adopted. >>> Still, using it to set boolean, integer, or string values is justifiable. >>> >> >> Please explain to me why it's an "anti-pattern"? What's wrong with the >> property API? What could be a better alternative? Just for my >> own understanding! :) >> > > It should go the other way around. You should explain what you gain by > using this scheme instead of what's standard practice in the language we > are dealing with (C). > > For all I see you are throwing out type safety and things that compiler > and linker can check for, to gain.... nothing. "Fewer API" is not a goal. > It shouldn't be. Why don't we move ALL API into that one call?! > > Also Google around why ioctl is a bad syscall for example. > > -- > behdad > http://behdad.org/ >
_______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
