Encapsulation in JavaScript
in [JavaScript]
|
From: VK on 6 Jun 2010 13:39 > It is good, though, that you use "IMHO" acronym in this case. Because > again, the main purpose of the encapsulation is a to encapsulate (to > abstract) from a user some /auxiliary data/ which participate to provide > some public data, the public interface (API). Maybe now, but not originally. Originally it was an obvious security necessity to expose for security related actions only what is needed to be exposed and only in one way to be used. Because if you write say a C shell for a language X, and this language has method getFileName, and your method implementation has some intermediary method or var with hard disk access, this fact will be sooner or later found and if it can be used for hacking - it will be used that way. > If in future the public API will be changed, then the /ability to > localize and predict the internal (encapsulated) places of the needed > changes with the minimum of expenses/ -- is the /main/ purpose of the > encapsulation. Correction: a deeply secondary (by the timeline at least) and severely misused purpose of the encapsulation. ;-) > P.S.: regarding __parent__ by the way, it is very convenient to use it > to make a "private" concept usable via the naming convention with the > leading underscore --http://gist.github.com/363056 Wow... Thank again. I am getting two impressions by now: i) since JavaScript 1.6 the Mozilla team is having a good time of joking over the language and ii) the most dangerous person for JavaScript, Mozilla project and ECMA standards is Mr. Brendan Eich. No personal offence... > P.S.: I don't wanna to make a big off-topic in the thread related with > "JSON Style JavaScript Class/Object declaration". So, if you want, you > can make separate thread to make the discussion more relevant with the > thread title. Changed to "Encapsulation in JavaScript"
From: Dmitry A. Soshnikov on 6 Jun 2010 15:24 On 06.06.2010 21:39, VK wrote: >> It is good, though, that you use "IMHO" acronym in this case. Because >> again, the main purpose of the encapsulation is a to encapsulate (to >> abstract) from a user some /auxiliary data/ which participate to provide >> some public data, the public interface (API). > > Maybe now, but not originally. Originally it was an obvious security > necessity to expose for security related actions only what is needed > to be exposed and only in one way to be used. By the way, why do you use a assertion form of your sentences, just it would be the truth? Please mention, I'm talking to you, but not asking you what is encapsulation and what does it /originally/ and /now/ mean. I don't know what to suggested you to read, you can start reading from the general theory (e.g. Wikipedia also fits). So, /originally/ (please record, this is a lecture), a concept of an information hiding (an encapsulation) is invented to increase an abstraction of a system. If you have some modules, then these modules can collaborate via the specified API from every module. If some module will change tomorrow representation of its internal state -- all other modules will continue to use the same API just it there were no any change. And /this/ is the /main/ purpose of the /encapsulation/ concept -- decreasing of modules coupling and increasing of the abstraction. I.e. a system is a "black box" with its /internal state/ and /external API/. And (I repeat) /predicting and localizing/ the places of some changes of an internal state without (possibly) changing the external API -- is the /main/ purpose of the encapsulation. In some OOP implementations this principle was extended with ability to change a /level/ of accessibility (as a consequence of some designs, e.g. an inheritance). If some classes have collaboration -- then it is a good design if they "talk" with each other via the public API, and do not interesting about /their construction/ (or internal state). /This/ is the main purpose of the encapsulation, but not the security reasons at first place! > Because if you write say > a C shell for a language X, and this language has method getFileName, > and your method implementation has some intermediary method or var > with hard disk access, this fact will be sooner or later found and if > it can be used for hacking - it will be used that way. > Oh, come on, you don't think that for software security and safety a "private" keyword is used, right? Good then. >> If in future the public API will be changed, then the /ability to >> localize and predict the internal (encapsulated) places of the needed >> changes with the minimum of expenses/ -- is the /main/ purpose of the >> encapsulation. > > Correction: a deeply secondary (by the timeline at least) and severely > misused purpose of the encapsulation. ;-) > I have no again idea why do you use the assertion form of your statement. If some CS teacher/lecture learned you (or some student) that encapsulation is for security -- please send this teacher to me to talk. I am a lecture myself. >> P.S.: regarding __parent__ by the way, it is very convenient to use it >> to make a "private" concept usable via the naming convention with the >> leading underscore --http://gist.github.com/363056 > > Wow... Thank again. I am getting two impressions by now: i) since > JavaScript 1.6 the Mozilla team is having a good time of joking over > the language and ii) the most dangerous person for JavaScript, Mozilla > project and ECMA standards is Mr. Brendan Eich. No personal offence... > Well, don't know, but some of the stuff is very convenient though ;) Dmitry.
From: VK on 6 Jun 2010 16:34 On Jun 6, 11:24 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> wrote: > By the way, why do you use a assertion form of your sentences, just it > would be the truth? Please mention, I'm talking to you, but not asking > you what is encapsulation and what does it /originally/ and /now/ mean. I am not the FAQ Maintainer of this newsgroup. Only that person may need to indicate for statements if he/she speaks as a regular poster or expressing a current consensus among the group regulars. In my case unless it is indicated otherwise, I am talking for myself, nickname VK, [schools_ring-at-yahoo-dot-com] for nickname hijacking check if any doubts. The only exception I do sometimes is if I have a lot of different recent posts and I am currently answering to a newcomer. In such case I may indicate at the beginning that it is my private opinion so she would not make false assumption of VK expressing some consensus clj opinion. I do not see a reason to prefix each and every statement with "In my opinion," or to postfix is with IMO/IMHO. > I don't know what to suggested you to read, you can start reading from > the general theory (e.g. Wikipedia also fits). I am 42 years old and my memory is not senile yet. So I better rely on my memory. The history description may differ dramatically from the history as it is. You may know that. > So, /originally/ (please record, this is a lecture), a concept of an > information hiding (an encapsulation) is invented to increase an > abstraction of a system. Your experience differs from mine at that point. > If you have some modules, then these modules can collaborate via the > specified API from every module. If some module will change tomorrow > representation of its internal state -- all other modules will continue > to use the same API just it there were no any change. And /this/ is the > /main/ purpose of the /encapsulation/ concept -- decreasing of modules > coupling and increasing of the abstraction. > > I.e. a system is a "black box" with its /internal state/ and /external > API/. And (I repeat) /predicting and localizing/ the places of some > changes of an internal state without (possibly) changing the external > API -- is the /main/ purpose of the encapsulation. > > In some OOP implementations this principle was extended with ability to > change a /level/ of accessibility (as a consequence of some designs, > e.g. an inheritance). If some classes have collaboration -- then it is a > good design if they "talk" with each other via the public API, and do > not interesting about /their construction/ (or internal state). /This/ > is the main purpose of the encapsulation, but not the security reasons > at first place! Carefully read, but hundreds of security breaks I remember prevent me to agree with you. I mean security breaks because of security- sensitive objects exposed something besides of what they had to expose and others found it. Or what had to be exposed was exposed in a wrong way so allowed to use the exposed feature in some way beyond the intended one. > > Because if you write say > > a C shell for a language X, and this language has method getFileName, > > and your method implementation has some intermediary method or var > > with hard disk access, this fact will be sooner or later found and if > > it can be used for hacking - it will be used that way. > > Oh, come on, you don't think that for software security and safety a > "private" keyword is used, right? Wrong. Go change some Java class vars or method from the original private to something else and I'll show you how wrong you are. With Jad it will not take too long. Actually, there is no need to hack Java source. You may just help me answer to my question posted at comp.lang.java.help (it is JavaScript related as well): http://groups.google.com/group/comp.lang.java.help/browse_frm/thread/dc29f8c3c187b791 > >> If in future the public API will be changed, then the /ability to > >> localize and predict the internal (encapsulated) places of the needed > >> changes with the minimum of expenses/ -- is the /main/ purpose of the > >> encapsulation. > > > Correction: a deeply secondary (by the timeline at least) and severely > > misused purpose of the encapsulation. ;-) > > I have no again idea why do you use the assertion form of your statement. > > If some CS teacher/lecture learned you (or some student) that > encapsulation is for security -- please send this teacher to me to talk. > I am a lecture myself. I am a language (human ones) specialist by my diploma. Plus C++ 3 months crash course in the US. Plus in that sorry business since 1996. So with CS lectures (from Berkley mainly) I spoke only a few times, it was in SF bars and it was about the baseball and not about the encapsulation :-) That can be the core of the problem. > >> P.S.: regarding __parent__ by the way, it is very convenient to use it > >> to make a "private" concept usable via the naming convention with the > >> leading underscore --http://gist.github.com/363056 > > > Wow... Thank again. I am getting two impressions by now: i) since > > JavaScript 1.6 the Mozilla team is having a good time of joking over > > the language and ii) the most dangerous person for JavaScript, Mozilla > > project and ECMA standards is Mr. Brendan Eich. No personal offence... > > Well, don't know, but some of the stuff is very convenient though ;) It is. But in the recent years Mozilla acts too often like W3C tried to act, and Brendan Eich like Sir Berners-Lee. So as if they are the only legitimate JavaScript standards developers and Brendan Eich is still the owner of the thing he invented. For you: IMHO. They know CC used for AJAX data exchange encapsulation for *security* reasons in many commercial libraries. Yet they introduce a non-documented non- standard feature that f*cks up the whole CC mechanics. Sure, who wants it, he can read about yet another non-documented non-standard feature that allows to fix the breach caused by the first one. Global source code search-replace, QA testing, notify all customers and make free update for them. Big deal, really... Johnny Doe uses __parent__ in his Firefox interface part of code, he really likes it and he doesn't want any inconvenience. So what a big deal, b*ches?! IMHO, sarcasm.
From: VK on 7 Jun 2010 03:19 > > So, /originally/ (please record, this is a lecture), a concept of an > > information hiding (an encapsulation) is invented to increase an > > abstraction of a system. > > Your experience differs from mine at that point. I may need to explain it further. If say i) there is a custom function getPosXY(elm) that returns the real left-top coords of elm and ii) this function exposes some internal intermediary property or method _foo and iii) by setting this method to 0, null or undefined the user can make the whole script crashed: given these circumstances, the amount of care I do give to the possibility of (iii) is so small that one needs an electronic microscope to see it - and even then doubtful. Thus the encapsulation concept as described in your lecture is completely out of my interest and used to be out of the JavaScript coding practice. As Roedy Green said, "He would only hurt himself. That's fine. You can't protect people from committing suicide." So *in the programming* I am on the eugenics side: idiots have to eventually die so do not pollute the common genotype. :-) Yet if I am developing a stay-alone module for say 3rd party data exchange, I'll do my best to make the data accessible only in the way as spelled in my manual. Same for local file access tools, same for ActiveX objects. They always can be hacked. The 1st axiom of the programming, remember: "Anything created by one human being can be reverse engineered and altered by another human being". But at least I will try my best.
From: Dmitry A. Soshnikov on 7 Jun 2010 06:16 On 07.06.2010 0:34, VK wrote: > On Jun 6, 11:24 pm, "Dmitry A. Soshnikov"<dmitry.soshni...(a)gmail.com> > wrote: >> By the way, why do you use a assertion form of your sentences, just it >> would be the truth? Please mention, I'm talking to you, but not asking >> you what is encapsulation and what does it /originally/ and /now/ mean. > <snip> > I do not see a reason to prefix each and every > statement with "In my opinion," or to postfix is with IMO/IMHO. > Of course it is not required to use /every time/ IMHO or IMO (or whatever uncertain introduction of a phrase). I just want to prevent a some demagogy style, when some starts to talk with assertions just to "win" the talk (hoping, that an opponent won't check or don't know the subject). If this isn't you case, then we can continue to talk. Also, I want to prevent the tries to guess something. Personally, if I don't know something, I -- (a) talk in interrogative form (asking those who know the subject) if the subject is /known/, or (b) talk in the guessing/proposal form if the subject isn't know yet and innovative. If I at the position of a speaker who is sure in what he's talking about, I talk in assertion form. But to be able to talk in the "language of assertions" it is needed: (a) to know the general theory well and (b) to know deeply the concrete theory/ideology/practical aspects of the concrete technology. Regarding the encapsulation, I explain you the general theory (which is applied also to the concrete technology -- ECMAScript) of this concept. >> I don't know what to suggested you to read, you can start reading from >> the general theory (e.g. Wikipedia also fits). > > I am 42 years old and my memory is not senile yet. So I better rely on > my memory. Don't worry, I respect the age. Moreover, your age is absolutely normal for me, as at work I have some colleagues of your and older age. For your info I am 27 years old (if it matters somehow). But. In the professional discussion neither age, nor some status, as well as nor an authority, nor a position and accessory to some "privileged" community or a group and so on, and so forth /do no matter/. I for you an interlocutor. As you are for me. No more, no less. If you have the same meaning we can continue the talk. > The history description may differ dramatically from the > history as it is. You may know that. Maybe, but can you show me that you call an "original" meaning of the encapsulation and exactly that there is said, that this concept was invented for the /security/ reasons but not for an abstraction, structural decomposition of a system on modules where every module encapsulates its internal auxiliary state and has a public API? >> So, /originally/ (please record, this is a lecture), a concept of an >> information hiding (an encapsulation) is invented to increase an >> abstraction of a system. > > Your experience differs from mine at that point. > I see. But I don't argue with you. I just can explain it. To accept it or not -- this is your choice. But if you understand a professional discussion as meanings exchange, then you'll see that I am spiritted positively and on exchange of knowledge, but not on desire to "win a dispute". >> If you have some modules, then these modules can collaborate via the >> specified API from every module. If some module will change tomorrow >> representation of its internal state -- all other modules will continue >> to use the same API just it there were no any change. And /this/ is the >> /main/ purpose of the /encapsulation/ concept -- decreasing of modules >> coupling and increasing of the abstraction. >> >> I.e. a system is a "black box" with its /internal state/ and /external >> API/. And (I repeat) /predicting and localizing/ the places of some >> changes of an internal state without (possibly) changing the external >> API -- is the /main/ purpose of the encapsulation. >> >> In some OOP implementations this principle was extended with ability to >> change a /level/ of accessibility (as a consequence of some designs, >> e.g. an inheritance). If some classes have collaboration -- then it is a >> good design if they "talk" with each other via the public API, and do >> not interesting about /their construction/ (or internal state). /This/ >> is the main purpose of the encapsulation, but not the security reasons >> at first place! > > Carefully read, but hundreds of security breaks I remember prevent me > to agree with you. I mean security breaks because of security- > sensitive objects exposed something besides of what they had to expose > and others found it. Or what had to be exposed was exposed in a wrong > way so allowed to use the exposed feature in some way beyond the > intended one. > If a programmer will won't to use/change "private" access level, he'll do it -- e.g. just open a file of your library and change it. If you're interested in "maliciousness hackers", they will find a way to hack your system in completely other ways, but not via "private" keyword. Once again -- encapsulation is for a /programmer/, but not a measure of software security! It was so and it is so. <snip> Ok, you can read this paper: <URL: http://bit.ly/MP49r> -- this is the text of the /original/ meaning of the encapsulation written by "David Parnas" <URL: http://en.wikipedia.org/wiki/David_Parnas> -- the /original inventor/ of the encapsulation concept. In addition, you can read just Wikipedia, as I mentioned already: http://en.wikipedia.org/wiki/Information_hiding http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming) And try to find a word where is said that the /main/ purpose of the encapsulation is /security/, but not the /increasing of an abstraction/ via /hiding internal state (predicting and localizing the further changes of this internal state) with providing a public API/. Dmitry.
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: Cornford-Crockford Scope Management - CC Scope Management - CC Next: Alt text for equations |