> -----Original Message----- > From: Patrick Ohly [mailto:[email protected]] > Sent: Monday, December 09, 2013 10:48 AM > To: Schaufler, Casey > Cc: Dominig ar Foll; [email protected]; SeungYeup Kim > Subject: Re: [Dev] Smack Feature for Vconf > > On Mon, 2013-12-09 at 17:30 +0000, Schaufler, Casey wrote: > > > -----Original Message----- > > > From: [email protected] > > > [mailto:[email protected]] On Behalf Of Dominig ar Foll > > > Sent: Monday, December 09, 2013 6:18 AM > > > To: [email protected]; SeungYeup Kim > > > Subject: Re: [Dev] Smack Feature for Vconf > > > > > > > > > Le 09/12/2013 02:11, Schaufler, Casey a écrit : > > > >> That means paths decided by vconftool needs to be known (and hard > > > >> coded) by the package maintainer (what if it is changed later ?). > > > > Yes. This is correct. I submit that this is a good thing. > > > > Developers who don't > > > understand the environment in which they are developing are at a > > > serious disadvantage. It makes it very difficult for them to > > > contribute to the system beyond the niche they are working on. > > > > > > > > > > > I am afraid that I do not agree with the idea that app developpers > > > should know the abolute Path used by their Apps. > > > > If they don't know where the files are, how can they check to see if the > contents are correct? > > How can they possibly figure out if the file is getting created at all? > > You are talking about debugging. That's an activity done by humans, who can > adapt to changing circumstances more or less easily. > > What Dominig objects against, and I agree with him there, is embedding that > knowledge into the source code or packaging where it'll be much harder to > change. It goes against the principles of encapsulation and hiding of > implementation details.
Indeed it does. I don't believe in those principles. I believe that they lead to poor performance and security holes. I also understand that I am in a minority on this topic. > -- > Best Regards, Patrick Ohly > > The content of this message is my personal opinion only and although I am an > employee of Intel, the statements I make here in no way represent Intel's > position on the issue, nor am I authorized to speak on behalf of Intel on this > matter. > _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
