Prev: Cornford-Crockford Scope Management - CC Scope Management - CC
Next: Alt text for equations
From: Dmitry A. Soshnikov on 7 Jun 2010 06:46
On 07.06.2010 11:19, VK wrote:
>>> 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

That's your choice. Repeat, I just can explain, but not to force you to
accept the truth (possibly, you'll need some time to understand and
accept this truth -- but that's completely OK, because as I mentioned
this problem with understanding the main purpose of the encapsulation is
widespread). In any case, the truth isn't being disturbed because of
someone does not understand it (or understand it incorrectly) or does
not accept it.

<snip>

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

Should be a correct understanding of the encapsulation. If some (a user,
a programmer) will wanna change the code of your library -- he will. But
why the heck he should ask your permission to do this? He uses your lib,
see some bad implementation -- go to source and change them (if the
license is OK to change the code). Accordingly, he can change you
"private" keyword to "public" if he want.

Many languages e.g. Ruby has this concept (of encapsulating the internal
state) built-in in core principle. E.g. everything is base on
getter/setter methods for internal state. Thus, an internal state can be
more complex than just a simple variable:

class A

def initialize
@x = 100 # private state var
@y = 300
@z = 500
end

# getter
def x
@x
end

# setter
def x=(new_x)
@x = new_x
end

# only getter for @y
def y
@y + 100
end

end

a = A.new
a.x # 100

a.x = 200
a.x # 200

a.y 400
a.y = 500 # error

a.z # error -- there is no even a getter for z

At the same time, Ruby has several /meta/ methods, including
getting/setting private internal state:

a.instance_variable_get(:@z) # 500
a.instance_variable_set(:@z, 600)
a.instance_variable_get(:@z) # 600

# define an own getter
# for @z for "a" instance

def a.z
a.instance_variable_get(:@z)
end

a.z # 600

If tomorrow a representation of the internal state will be changed, the
public API will be the same (supposing that "a.y" is used in many places):

def a.y
500
end

a.y # 500


Another simplest example of the encapsulation can a casual /constant/
concept when you use e.g. MAX_LENGTH constant /predicting and
localizing/ the places (currently will be only one place) of needed changes:

MAX_LENGTH = 100;

And then always use MAX_LENGTH everywhere. If tomorrow if will be 200,
all other modules won't even notice that your module has changed some
internal state (the value) -- they will continue to use public API --
MAX_LENGTH.

And /this/ is the main purpose of the encapsulation. Go and tell "them"
all that I've told you. And I will tell this for everyone independently
their status or authority. But repeat -- with the positive approach and
with the only one objective -- to show what exactly it means, but not
accept the misconceptions forced by some authorities without understanding.

Dmitry.
From: VK on 16 Jun 2010 06:09
On Jun 7, 2:46 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com>
wrote:
> That's your choice. Repeat, I just can explain, but not to force you to
> accept the truth (possibly, you'll need some time to understand and
> accept this truth -- but that's completely OK, because as I mentioned
> this problem with understanding the main purpose of theencapsulationis
> widespread). In any case, the truth isn't being disturbed because of
> someone does not understand it (or understand it incorrectly) or does
> not accept it.
>
> Should be a correct understanding of the encapsulation. If some (a user,
> a programmer) will wanna change the code of your library -- he will. But
> why the heck he should ask your permission to do this? He uses your lib,
> see some bad implementation -- go to source and change them (if the
> license is OK to change the code). Accordingly, he can change you
> "private" keyword to "public" if he want.

Your position is clearly understood. IMO the problem is in the
semantic, not in in the correctness / non-correctness of a programming
paradigm. Any JavaScript program has three main stages of the life
cycle:
1) idle stage (source stage)
That is the stage of a program being say open in an editor or simply
stored as a file client/server side.
2) parsing stage
This is the stage of the source being fed to the parser
3) execution stage
I guess it doesn't need to be explained

In your posts you are talking about the idle stage and the
"abstraction encapsulation" as it applies to that stage. For this
stage and this kind of encapsulation your arguments are correct.
Indeed, the abstraction encapsulation appeared as a measure of
protection of programmers from programmers, so the library would be
used in the documented way and not over different "undocumented
features" ("Undocumented features of ..." once was a very popular
title at DOS/Windows 3.x times). The usage of undocumented features
and unfrozen interfaces may be very effective for a particular task in
comparison with officially exposed methods. Yet such usage is a
ticking bomb in case of internal library changes. So here the
abstraction encapsulation came. Can anyone still alter the program on
its idle stage, say private to public etc? Of course she can. Here
digital signatures, hash codes and user agreements come into play. So
I can alter or completely redo a 3rd party library but it eliminates
my possibility to complain if anything goes wrong, it eliminates my
rights for support and in most cases it violates the user agreement I
had to accept. So the explicit manual change of a 3rd party program
lies beyond any programming matters, in the legal domain.

The issue with the abstraction encapsulation - which is rightly
criticized by you - is that at some moment some programmers wrongly
took the possibility of the "back door" access as their
responsibility. Other words if method getXY() has internal _foo
accessible from outside, and by setting _foo to something makes
getXY() behave wrongly then it is by definition my own holly
obligation to protect _foo from side access. It is not. I may do it,
or I may let anyone to "shoot his leg" and screw them.

So for the abstraction encapsulation we seem to have no points to
argue. I was arguing about the execution stage and the security
encapsulation which is a whole different issue.
From: Dmitry A. Soshnikov on 16 Jun 2010 07:31
On 16.06.2010 14:09, VK wrote:
> On Jun 7, 2:46 pm, "Dmitry A. Soshnikov"<dmitry.soshni...(a)gmail.com>
> wrote:
>> That's your choice. Repeat, I just can explain, but not to force you to
>> accept the truth (possibly, you'll need some time to understand and
>> accept this truth -- but that's completely OK, because as I mentioned
>> this problem with understanding the main purpose of theencapsulationis
>> widespread). In any case, the truth isn't being disturbed because of
>> someone does not understand it (or understand it incorrectly) or does
>> not accept it.
>>
>> Should be a correct understanding of the encapsulation. If some (a user,
>> a programmer) will wanna change the code of your library -- he will. But
>> why the heck he should ask your permission to do this? He uses your lib,
>> see some bad implementation -- go to source and change them (if the
>> license is OK to change the code). Accordingly, he can change you
>> "private" keyword to "public" if he want.
>
> Your position is clearly understood. IMO the problem is in the
> semantic, not in in the correctness / non-correctness of a programming
> paradigm.

Besides, I don't see any problem with understanding what does the
"encapsulation" term (in computer science) mean.

Any JavaScript program has three main stages of the life
> cycle:
> 1) idle stage (source stage)
> That is the stage of a program being say open in an editor or simply
> stored as a file client/server side.
> 2) parsing stage
> This is the stage of the source being fed to the parser
> 3) execution stage
> I guess it doesn't need to be explained
>

Let's say -- not only JavaScript, but many other languages have such
stages (I'll mention the Ruby soon to show you again -- how we can
easily and _dynamically_ affect the code, getting access to the
encapsulated data if needed) ;)

Of course, if we have the case when a programmer do this often (of
without understanding -- that is more essential), then it is possible to
talk about /bad programming stylistics/.

> In your posts you are talking about the idle stage and the
> "abstraction encapsulation" as it applies to that stage.

Not only the "idle" stage (by your terminology). In completely dynamic
language with mutable objects we can affect the code dynamically at
runtime. Take any such language -- Ruby, Python, ECMAScript, etc.

> For this
> stage and this kind of encapsulation your arguments are correct.

OK. But I should again mention -- I didn't prove anything, I just explained.

> Indeed, the abstraction encapsulation appeared as a measure of
> protection of programmers from programmers,

Yeah, that's right -- as a good helper for more abstractly and therefore
-- more quality build a system -- with a (possibly) complex and powerful
internal state, but with the convenient public API for a user of our
system. And this internal state (an auxiliary data) is encapsulated from
the user, making using the system really convenient and all details are
transparent. I should underline the whole this sentence -- this exactly
is called as an encapsulation in the computer science.

> so the library would be
> used in the documented way and not over different "undocumented
> features" ("Undocumented features of ..." once was a very popular
> title at DOS/Windows 3.x times).

Yeah, I remember that titles ;)

> The usage of undocumented features
> and unfrozen interfaces may be very effective for a particular task in
> comparison with officially exposed methods.

Maybe, but such cases (if possible) should be avoided in the good
stylistics. Notice, nevertheless, I don't mention security.

> Yet such usage is a
> ticking bomb in case of internal library changes.

Yep. Only the programmer is responsible for that. If he want to use a
system not by the "rules", he _may_, but -- the full responsibility is
on him. If something goes wrong -- only he will rewrite his system
correctly using special public interface to talk with the system.

That's it -- the system has its right -- to change at any time its
internal state. At the same time, if a programmer knows the system
completely and knows /how/ and /when/ it will look like after the
changes of some internal state, he can affect this internal state, but,
repeat, with full responsibilities for that.

I mention the Ruby again. I already showed you an example how a
programmer can affect internal instance variables (in Ruby they prefixed
with @ sign -- analog of using `this.` in other languages).
Alternatively, Ruby has ability to send messages to /private/ state of
an object:

class A

def initialize
@a = 10 # instance variable without getter/setter
end

def test
return @a + private_method()
end

private

def private_method
return " from private"
end

end

a = A.new # an instance

a.a # error, there is no getter for @a

# the general getter of instance
# internal (sic!) encapsulated variables

a.instance_variable_get(:@a) # 10

# public method has access
# to the private method

a.test() # "10 from private"

# at the same time "a" has
# no access to the "private_method"
# from the outside of the "A" class definition

a.private_method() # error, access to private method

# but (sic!) using the general "send"
# method we can access this encapsulated state

a.send(:private_method) # OK - " from private" is returned

Now tell me. The author of Ruby -- Yukihiro Matsumoto <URL:
http://en.wikipedia.org/wiki/Yukihiro_Matsumoto> -- could he /by his own
hands/ just "kill" his language and provide such "insecure" methods?
Could he just don't think about anything and create such "ugly" language
which (oh-o-o..) has no /"private" keyword for "security"/? Or maybe, he
just knew _what is_ encapsulation?

> So here the
> abstraction encapsulation came. Can anyone still alter the program on
> its idle stage, say private to public etc? Of course she can.

By the way, why do you used "she" word? I'm just interested from the
English language position. Why not "he"?

> Here
> digital signatures, hash codes and user agreements come into play. So
> I can alter or completely redo a 3rd party library but it eliminates
> my possibility to complain if anything goes wrong, it eliminates my
> rights for support and in most cases it violates the user agreement I
> had to accept. So the explicit manual change of a 3rd party program
> lies beyond any programming matters, in the legal domain.
>

Yes, true.

> The issue with the abstraction encapsulation - which is rightly
> criticized by you - is that at some moment some programmers wrongly
> took the possibility of the "back door" access as their
> responsibility.

Yes.

> Other words if method getXY() has internal _foo
> accessible from outside, and by setting _foo to something makes
> getXY() behave wrongly then it is by definition my own holly
> obligation to protect _foo from side access. It is not. I may do it,
> or I may let anyone to "shoot his leg" and screw them.
>

But please notice, I don't say a word that "strong encapsulation" --
i.e. without _any_ ability to affect the internal state is bad.
Vice-versa -- it's even better helper for a programmer, because can
faster catch errors. But, he will catch the same errors and in e.g.
Ruby's implementation -- where will be such errors with /direct/ using
of an internal state.

> So for the abstraction encapsulation we seem to have no points to
> argue.

Yeah, seems so. OK.

Just want again to notice, that if we sure that some internal state
won't be change in the future, then (IMO -- and logically) there is no
/any/ need to make it encapsulated providing hiding of /absolutely
non-abstract/ entities. This can be the same ridiculous as not to
understand the language (yep, e.g. as using === with `typeof' comparing
the result with strings).

I mean if you sure that in future `foo' datum won't be changed, then:

function getFoo() {
return foo;
}

is just /big misconception of an encapsulation/. Of course, if we
/predict/ such changes and in future `foo's getter will be more complex,
then we can _reserve_ such _non-abstract_ getter and this is completely OK.

However, it's just my meaning and regarding the particular
implementation, e.g. ECMAScript. Because again in Ruby, this is in the
_core ideology_ -- an internal datum could/should have a getter/setter
-- and in general case these getters/setters can be the same
non-abstract just returning the value of that internal state (in the
mentioned example on Ruby above for @a e.g. -- def a; return @a; end).
But at the same time (having such ideology) you saw the mechanism of
getting access to the internal data.

Or, another example where such absolutely non-abstract getters/setters
can make sense. This is Java. If I remember correctly, it recommends to
use always getter/setter for a "private" variables. But -- what's the
most funny -- it relates to the implementation of the Java: there a.foo
and a.getFoo() can (in some specific cases) return /different/ results
-- because methods are polymorphic, but properties not (if will be
needed a complete example of such ambiguity, let me know). So for the
/correct/ behavior they recomment always use getters for that. Although,
I've heard, and in Java community there are people which don't see a
sense in such non-abstract (read === "useless") encapsulation.

> I was arguing about the execution stage and the security
> encapsulation which is a whole different issue.

The term "security encapsulation" is odd, but at the same time
widespread in its misconception. I can imagine e.g. "security measures"
concept. Yes, software could/should be secure -- depending on our needs.
If we have a dynamic language with mutable objects which can be altered
at runtime, and at the same time we openly provide such ability -- using
e.g. "console" or "javascript:" pseudo-protocol, then it is not so
responsible not to check the data also on the server side (in this case,
the JavaScript is just an convenient addition).

But sure, a "private" isn't for security, but for programmers.

You put a "private" keyword? -- a hacker will alter the bytecode.

You have some compiled program? -- the hacker will alter it with
HEX-editor and won't even see on your "private" keyword.

You afraid that the hacker will change your private "_foo" which is used
in "setFoo" -- don't worry -- he will change completely "setFoo" instead
(the language is dynamic, forgot? -- or maybe you'll suggest to make JS
static? -- it won't help also).

You afraid that somebody will alter your JS object via console? -- the
hacker will sniff a traffic on the net level and don't even see your
JavaScript object with a "private" keyword.

So, I repeat, other measures are used for software security and safety,
but not the "private" keyword.

But, of course, encapsulation sugar in OOP such as "private",
"protected" and "public" is a good sugar (and "strong" version can be
even more convenient for someone) and a good helper for the _programmer_
-- therefore this sugar was invented. Thus, notice, "protected" is just
a consequence of some paradigm.

Dmitry.
From: VK on 16 Jun 2010 08:03
On Jun 16, 3:31 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com>
wrote:
> Now tell me. The author of Ruby -- Yukihiro Matsumoto <URL:http://en.wikipedia.org/wiki/Yukihiro_Matsumoto> -- could he /by his own
> hands/ just "kill" his language and provide such "insecure" methods?
> Could he just don't think about anything and create such "ugly" language
> which (oh-o-o..) has no /"private" keyword for "security"/? Or maybe, he
> just knew _what is_ encapsulation?

Yukihiro Matsumoto thoughts are his thoughts, I didn't participate in
Ruby design. He might know what encapsulation must be by CS
definition. He might not knowing what practical security issues can
be. You didn't answer my question about Java <=> JavaScript interop
over JSObject and the security/stability issue caused by missing
encapsulation for Applet generic methods. Would you mind to consider
this case
http://groups.google.com/group/comp.lang.java.help/browse_frm/thread/dc29f8c3c187b791
and comment on it: is it abstraction encapsulation issue as defined by
you, is it another type of encapsulation issues, is it not the
encapsulation issue at all?

> By the way, why do you used "she" word? I'm just interested from the
> English language position. Why not "he"?

Just the pc (political correctness) habit. In the US "he" as the
universal 3rd person was admitted as sexist, so switched to "he/she" -
"she/he", then to the shortcut "(s)he". Both rightly considered as
ugly so finally it was decided to use "she" everywhere just to be left
in peace by pc maniacs. So not be surprised by seeing "she" throughout
in many US originated manuals. Not to say I am in pc violation fear in
this NG, just a typing habit. If it irritates you I'll try to control
it and to use "he" instead.


> > Here
> > digital signatures, hash codes and user agreements come into play. So
> > I can alter or completely redo a 3rd party library but it eliminates
> > my possibility to complain if anything goes wrong, it eliminates my
> > rights for support and in most cases it violates the user agreement I
> > had to accept. So the explicit manual change of a 3rd party program
> > lies beyond any programming matters, in the legal domain.
>
> Yes, true.
>
> > The issue with the abstraction encapsulation - which is rightly
> > criticized by you - is that at some moment some programmers wrongly
> > took the possibility of the "back door" access as their
> > responsibility.
>
> Yes.
>
> > Other words if method getXY() has internal _foo
> > accessible from outside, and by setting _foo to something makes
> > getXY() behave wrongly then it is by definition my own holly
> > obligation to protect _foo from side access. It is not. I may do it,
> > or I may let anyone to "shoot his leg" and screw them.
>
> But please notice, I don't say a word that "strong encapsulation" --
> i.e. without _any_ ability to affect the internal state is bad.
> Vice-versa -- it's even better helper for a programmer, because can
> faster catch errors. But, he will catch the same errors and in e.g.
> Ruby's implementation -- where will be such errors with /direct/ using
> of an internal state.
>
> > So for the abstraction encapsulation we seem to have no points to
> > argue.
>
> Yeah, seems so. OK.
>
> Just want again to notice, that if we sure that some internal state
> won't be change in the future, then (IMO -- and logically) there is no
> /any/ need to make it encapsulated providing hiding of /absolutely
> non-abstract/ entities. This can be the same ridiculous as not to
> understand the language (yep, e.g. as using === with `typeof' comparing
> the result with strings).
>
> I mean if you sure that in future `foo' datum won't be changed, then:
>
> function getFoo() {
>    return foo;
>
> }
>
> is just /big misconception of an encapsulation/. Of course, if we
> /predict/ such changes and in future `foo's getter will be more complex,
> then we can _reserve_ such _non-abstract_ getter and this is completely OK.
>
> However, it's just my meaning and regarding the particular
> implementation, e.g. ECMAScript. Because again in Ruby, this is in the
> _core ideology_ -- an internal datum could/should have a getter/setter
> -- and in general case these getters/setters can be the same
> non-abstract just returning the value of that internal state (in the
> mentioned example on Ruby above for @a e.g. -- def a; return @a; end).
> But at the same time (having such ideology) you saw the mechanism of
> getting access to the internal data.
>
> Or, another example where such absolutely non-abstract getters/setters
> can make sense. This is Java. If I remember correctly, it recommends to
> use always getter/setter for a "private" variables. But -- what's the
> most funny -- it relates to the implementation of the Java: there a.foo
> and a.getFoo() can (in some specific cases) return /different/ results
> -- because methods are polymorphic, but properties not (if will be
> needed a complete example of such ambiguity, let me know). So for the
> /correct/ behavior they recomment always use getters for that. Although,
> I've heard, and in Java community there are people which don't see a
> sense in such non-abstract (read === "useless") encapsulation.
>
> > I was arguing about the execution stage and the security
> > encapsulation which is a whole different issue.
>
> The term "security encapsulation" is odd, but at the same time
> widespread in its misconception. I can imagine e.g. "security measures"
> concept. Yes, software could/should be secure -- depending on our needs.
> If we have a dynamic language with mutable objects which can be altered
> at runtime, and at the same time we openly provide such ability -- using
> e.g. "console" or "javascript:" pseudo-protocol, then it is not so
> responsible not to check the data also on the server side (in this case,
> the JavaScript is just an convenient addition).
>
> But sure, a "private" isn't for security, but for programmers.
>
> You put a "private" keyword? -- a hacker will alter the bytecode.
>
> You have some compiled program? -- the hacker will alter it with
> HEX-editor and won't even see on your "private" keyword.
>
> You afraid that the hacker will change your private "_foo" which is used
> in "setFoo" -- don't worry -- he will change completely "setFoo" instead
> (the language is dynamic, forgot? -- or maybe you'll suggest to make JS
> static? -- it won't help also).
>
> You afraid that somebody will alter your JS object via console? -- the
> hacker will sniff a traffic on the net level and don't even see your
> JavaScript object with a "private" keyword.
>
> So, I repeat, other measures are used for software security and safety,
> but not the "private" keyword.
>
> But, of course, encapsulation sugar in OOP such as "private",
> "protected" and "public" is a good sugar (and "strong" version can be
> even more convenient for someone) and a good helper for the _programmer_
> -- therefore this sugar was invented. Thus, notice, "protected" is just
> a consequence of some paradigm.
>
> Dmitry.

From: VK on 16 Jun 2010 10:01
On Jun 16, 3:31 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com>
wrote:
> But sure, a "private" isn't for security, but for programmers.

While you are analyzing the counterexample I gave to you...

> You put a "private" keyword? -- a hacker will alter the bytecode.
>
> You have some compiled program? -- the hacker will alter it with
> HEX-editor and won't even see on your "private" keyword.
>
> You afraid that the hacker will change your private "_foo" which is used
> in "setFoo" -- don't worry -- he will change completely "setFoo" instead
> (the language is dynamic, forgot? -- or maybe you'll suggest to make JS
> static? -- it won't help also).
>
> You afraid that somebody will alter your JS object via console? -- the
> hacker will sniff a traffic on the net level and don't even see your
> JavaScript object with a "private" keyword.

There is no use to extra prove the 1st Axiom of Programming ("Anything
made by one human being can be reverse engineered or altered by
another human being"). An axiom by definition is something to be taken
for granted as opposed to a theorem. Say the Super Hacker theorem is
based on the initial axiomatic set: the 1st axiom, the 2nd axiom of
the incremental security ("The human intentions are to continuously
increase the security rather than to decrease it"), the axiom of the
human integrity ("There cannot be a fraction of a human being"). Being
put together it leads to the Super Hacker theorem: the maximum
achievable security for any finite time span (from say one year to say
1,000,000 years) is an absolutely secure system and the only one human
being in the whole world able to hack it. If such person happens to be
a law obeyed one then the equation will be resolved to 0 by non-
mathematical means. btw the Super Hacker theorem was creatively used
in the famous "The Matrix" movie.

It is important though do not wall into another extreme by concluding
from the 1st axiom that any security measures are futile so useless.
The task is not to write a totally secured code as it is not possible.
The task is to make it enough secured for the pre-postulated usage
frame and target audience. With this realistic approach it has a
perfect sense to encapsulate an independent XHR (AJAX) module for 3rd
party data retrieval. Can be data stream intercepted by side tools?
Sure if someone has the necessary knowledge. Can it be first altered
and then used? Sure if someone has the necessary knowledge. Yet I will
encapsulate it at least for the casual AID (Anti-Idiot Defense) and
against the most obvious attacks. It is not more futile than writing
client-side scripts per se, with the ethernal possibility of at least
one UA where the most basic code may fail.

> So, I repeat, other measures are used for software security and safety,
> but not the "private" keyword.

While you are analyzing the counterexample I gave to you...
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Cornford-Crockford Scope Management - CC Scope Management - CC
Next: Alt text for equations